Governed Bedrock applications: tracing a request from identity to evidence

Governance needs an observable request

A diagram with a private subnet, an IAM role, and a model endpoint does not explain what an AI application is allowed to do. I want to follow one request through the system: who initiated it, which records were eligible for retrieval, which model received the selected material, which tool was proposed, and why that tool was permitted. Governance becomes concrete when those decisions can be inspected and tested.

This is a proposed AWS architecture for a document assistant that may prepare an operational change but cannot execute it merely because a model suggests doing so. Amazon Bedrock provides the model interface. Application services own business authorization, retrieval scope, tool execution, and evidence retention. The discussion is a design study, not a claim that a deployment has passed an audit or achieved compliance with a particular contractual requirement.

Carry identity without confusing it with authority

The application authenticates the caller and resolves a trusted identity context before constructing a model request. The context should contain the tenant, relevant roles or attributes, and an authorization decision version. These values must come from trusted server-side verification. A tenant identifier inside a prompt, uploaded document, or model-produced tool argument is untrusted input and cannot establish access.

AWS IAM controls access to AWS resources and Bedrock operations. The application still needs to decide whether this particular user may read this particular business record or request this particular action. I would make that decision explicit at the retrieval and tool boundaries. A shared service role with broad data access does not automatically transfer the caller’s restrictions to every operation the service performs.

The model should receive only the context needed for its task. Avoid placing secrets, reusable credentials, or broad authorization claims into the prompt. If a tool needs delegated access, the server should obtain and scope it through the application’s authorization mechanism. The model can propose an operation and its parameters; it should not manufacture the identity under which that operation runs.

Check the network path and the data path separately

Amazon Bedrock supports interface VPC endpoints through AWS PrivateLink. This gives a private connectivity option for supported service access; it does not make every source, destination, or downstream tool private by association. I would enumerate actual request paths: application to Bedrock, application to the retrieval store, retrieval ingestion to object storage, tool service to its target, and logs to their destinations.

For each path, identify the principal, endpoint, relevant policy, encryption requirement, and expected egress behavior. A tool that fetches an arbitrary URL can introduce a separate outbound channel even when model invocation uses a private endpoint. Uploaded documents can also contain links or instructions intended to influence later actions. Network controls and application-level validation need to be tested against the same threat model.

Region and model selection belong in this review as well. Service availability, routing options, and model capabilities change over time. I would record the exact permitted configuration and verify its documented behavior for the deployment region rather than assuming that a diagram applies to every Bedrock option. The release artifact should identify the reviewed configuration, so a later infrastructure change has a clear scope for reassessment.

Authorize retrieved evidence and proposed tools

Retrieval is a data access operation. The application should restrict eligible sources using trusted caller context, then verify that returned passages satisfy the required policy before they enter the model context. Permission changes, stale index metadata, and cross-tenant cache keys are useful negative tests. The objective is not simply to hide unauthorized links in the final answer; the restricted content should not have been supplied to the generation step.

A proposed tool invocation should pass schema validation, business authorization, and an action-specific risk rule. For a consequential change, the approved proposal should bind the action, target, parameters, actor, and expiration. Reusing approval after a model changes the target would break the meaning of approval. The tool service should verify that binding immediately before execution and record its result with a durable operation identifier.

The illustrative policy record below describes the evidence to retain for a denied action. It is not an IAM policy or a complete authorization implementation. I would prefer a structured denial like this over a free-text log saying that the agent was blocked: the structured form allows a reviewer to ask which policy version was applied and whether a downstream side effect occurred.

1{
2  "request_id": "example-request-017",
3  "actor_ref": "pseudonymous-actor-ref",
4  "tenant_ref": "example-tenant",
5  "action": "asset.update_status",
6  "resource_ref": "asset-104",
7  "policy_version": "application-policy-v3",
8  "decision": "deny",
9  "reason_code": "approval_required",
10  "tool_executed": false,
11  "evidence_refs": [
12    "authorization-decision-ref",
13    "proposed-action-hash"
14  ]
15}

Log enough to investigate, not everything by default

Bedrock model invocation logging can send invocation information to configured destinations such as CloudWatch Logs and Amazon S3. AWS documents the configuration and supported data capture. Enabling it requires a data-handling decision: prompts and outputs may themselves contain sensitive information. I would define which payloads may be retained, who can inspect them, how long they remain, and how a deletion or incident request is handled.

Application evidence should connect the request identifier to authorization decisions, source versions, model configuration, tool proposals, actual executions, and response status. Where full content is unnecessary, retain structured metadata or references to a separately controlled artifact. Hashes can help associate an artifact with a record, but a hash alone does not establish who produced it or whether it was truthful. Access and integrity controls remain necessary.

A useful investigation asks whether an observed failure came from retrieval scope, source quality, model behavior, policy evaluation, or tool execution. One undifferentiated agent-success metric cannot answer that question. I would preserve stage outcomes and reason codes, while making sure the observability system cannot become an easier route to restricted data than the application itself.

Map controls to evidence with honest scope

NIST’s AI Risk Management Framework provides a framework for managing AI risks, with governance and context alongside measurement and management. I would use it to organize questions about intended use, affected parties, known limitations, evaluation, and response procedures. The resulting evidence map should point to owned artifacts and review intervals rather than placing a framework name beside an architecture diagram.

SOC reporting is a separate assurance context described by AICPA. An application can be designed to produce evidence useful to an examination, but that does not make the application SOC certified or make a cloud provider’s report a substitute for reviewing the customer-operated controls. The applicable scope, criteria, and assurance work must be established for the actual organization and service.

A practical mapping row would state a risk, the control intended to address it, the responsible owner, the test procedure, and the evidence retained. For cross-tenant retrieval, that could mean a trusted tenant boundary, adversarial access tests, and a record of denied requests. The control’s effectiveness should be evaluated from those tests. The existence of a written policy is only evidence that a policy exists.

Release with negative tests and a recovery path

I would rehearse at least an unauthorized source request, a permission revoked after indexing, a malformed tool payload, an approved proposal modified before execution, and a timeout after an external side effect. Each case needs an expected outcome and a way to determine whether any action occurred. A timeout must not be interpreted automatically as a failed operation that is safe to repeat.

The release package would include the request contract, permitted infrastructure configuration, policy tests, source-access tests, logging and retention decisions, and an incident procedure. Operational owners should be able to disable a tool or a source connector without disabling all reading capability if the design supports that separation. A governed system earns confidence through explicit decisions and recoverable failures. The model remains one component inside that system, not the authority that defines its boundaries.