AWS Bedrock Audit Logs: What Model Invocation Logging Actually Captures

Amazon Bedrock's model invocation logging is disabled by default. Once an account admin turns it on, Bedrock will capture the full request body, the full response body up to 100 KB, token counts, and the ARN of the IAM principal that made the call, for every Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream request in that account and region. That is a genuinely detailed record. It is also a record built around an IAM role, not the human or agent the role was acting for.

I want to walk through exactly what ships in a Bedrock invocation log, how that differs from what CloudTrail captures for the same API calls, and where the gap sits once you try to hand this to a regulator.

TL;DR

• Bedrock model invocation logging is off by default and must be enabled per AWS account and region.
• A log entry contains the full input and output JSON body (up to 100 KB inline, larger payloads land in S3) plus identity.arn, the IAM role or user ARN that made the call.
• CloudTrail logs InvokeModel and Converse as management events by default, at no extra cost, but without the prompt or completion content that invocation logging captures.
• identity.arn identifies the assumed role and session name, not the natural person or end user the application was acting for, unless the caller manually attaches that context via requestMetadata.

Two separate logs, two separate jobs

Bedrock produces two categories of evidence for the same API call, and conflating them leads to a bad audit-readiness conversation. CloudTrail logs InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream as management events automatically, with no configuration and no extra CloudTrail charge. That gives you who called the API, when, from which account, and which model ID, without the prompt or the response.

Model invocation logging is the separate, opt-in feature that captures content. An admin has to create an S3 bucket or CloudWatch log group, attach the correct resource policy so the bedrock.amazonaws.com service principal can write to it, then enable logging through the console or the PutModelInvocationLoggingConfiguration API. Until that setup exists, the prompt and completion for every Bedrock call in that account are gone the moment the response returns.

What a log entry actually contains

Every invocation log record follows a fixed JSON schema: a request ID, the operation name, the model ID, an identity block, an optional requestMetadata object, and the input and output bodies with token counts. AWS's own documentation is specific that every field is populated automatically by Bedrock except one: requestMetadata, the only field the calling application supplies itself. That single detail matters more than it looks. Everything the record knows about who was behind the call, beyond the IAM ARN, depends entirely on the calling application choosing to attach it.

The identity field is a role, not a person

identity.arn captures the AWS STS or IAM ARN of the principal that made the request, for example an assumed role like arn:aws:sts::123456789012:assumed-role/MyRole/session-name. In a typical enterprise deployment, one application or one Lambda function assumes one role for every Bedrock call it makes on behalf of every end user it serves. The log tells you the role. It does not tell you which of the application's thousands of users triggered any specific call, unless the application developer thought to pass that identity through requestMetadata and nobody downstream can verify that the value passed is accurate.

Querying the log doesn't close the gap

AWS documents a CloudWatch Logs Insights query that groups token usage by principal using identity.arn, which is a genuinely useful cost and usage view for a platform team. It is also the clearest illustration of the ceiling on what this log can answer. Group by principal and you get the shared role's aggregate token spend. You do not get the natural person identity that Article 12 of the EU AI Act requires for the deployer of a high-risk system, because the role assumed to call Bedrock is not, and was never designed to be, that person's identity.

There is also a data-boundary detail worth knowing before an audit: invocation logging is scoped to bedrock-runtime. Calls through other endpoints, including bedrock-mantle, are not captured by this feature and require a separate CloudTrail data-event configuration to log at all.

The shape of this gap is not unique to Bedrock. Claude's connector audit trail has the same split between what the platform logs automatically and what requires the calling application to supply identity context, and the post-authentication gap describes the underlying pattern: authentication of the calling credential is solved, authorization of the specific request on behalf of a specific person is not.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect sits inline on the HTTP path in front of Bedrock (or any other model endpoint the same application calls), and it receives the identity context the application is required to supply for every request, not just the shared IAM role behind it. Each request is evaluated against per-role and per-route policy before it reaches Bedrock, and the resulting decision, permit, redact, or deny, is written to a signed, tamper-evident audit record independent of both the calling application and the AWS account's own logging configuration.

That independence is the part Bedrock's own logging cannot provide on its own. An account admin who can enable model invocation logging can also disable it, change the destination, or delete the S3 bucket policy. A record produced outside that account's control, tied to the actual authenticated caller rather than the assumed role, is what closes the gap between "we can see the IAM ARN" and "we can prove who was behind this specific request."

Book a demo today.