# Provider support access belongs in the boundary review

Review who can inspect service data during normal operations and support incidents. Network isolation does not answer that question by itself.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Distinguish technical access from permitted access

An architecture may restrict application traffic to a private endpoint while provider or internal support processes operate through separate control paths. Establish the applicable service terms, access controls and operational procedures for the configuration in use.

Avoid generalising from another product or service tier. Providers can offer different settings and commitments for different deployments. Use current primary documentation and the organisation's agreement to resolve the requirement.

Record what remains unknown and who can clarify it. An unanswered support-access question should not be replaced with a broad assurance that the system is private.

## Review your own support tooling first

Internal staff may already have access to full prompts through logs, traces or database consoles. Map those roles and determine whether the content is needed for their work.

Provide a minimal diagnostic path using request identifiers, configuration versions and failure categories. Where content inspection is necessary, use controlled access and an appropriate record of the reason.

Check downloaded support bundles and screenshots. These can move data from a restricted operational system into a less controlled collaboration tool.

## Define the incident evidence package

Decide what information can be shared with a provider when investigating a failure. Synthetic reproductions or reduced payloads may be sufficient. Do not attach complete customer documents merely because the support form accepts files.

Have the responsible data owner approve the intended sharing process where the organisation requires it. Engineering should make the proposed evidence concrete and minimise it before that decision.

Keep credentials, access tokens and unrelated records out of the package. Review automated diagnostic exports as carefully as manually prepared attachments.

## Verify configuration and keep the review current

Inspect deployed logging, identity and retention settings against the reviewed record. A contractual statement and a technical setting address different parts of the requirement, and both may matter.

Revisit the review when adding a model provider, changing service tier or enabling new diagnostics. Record the evidence date and the responsible owner. A useful access review explains who can see which data under which process, rather than treating a private network route as a complete answer.

## Sources

- [AWS: Bedrock data protection](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html)
- [OWASP: logging guidance](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)