AWS Bedrock Compliance: Building Evidence Around Model Invocation Logging

Amazon Bedrock model invocation logging is disabled by default. That single sentence from the AWS documentation determines the shape of most Bedrock compliance files I have read, because an auditor asking "show me the prompt that produced this output" gets nothing at all until someone turns the feature on and points it at a destination.

The rest of the review follows from what the feature does and does not capture once enabled.

TL;DR

• Amazon Bedrock model invocation logging is off by default until an administrator configures an S3 or CloudWatch Logs destination in the same account and Region.
• Logging covers only calls made through the bedrock-runtime endpoint, so calls on other endpoints such as bedrock-mantle are absent from the record.
• Each log entry carries identity.arn for the calling principal, populated automatically, alongside model ID, operation, token counts, and bodies up to 100 KB.
• AWS places compliance responsibility on the customer according to data sensitivity and applicable law, and publishes service scope through AWS Artifact.
• The customer still owns the per-request decision about whether this identity may send this content to this model.

What the service scope statement actually gives you

The Bedrock compliance validation page points to two places rather than making a claim in itself. Service scope by compliance program lives on the AWS services-in-scope page, and third-party audit reports download through AWS Artifact. AWS then states that compliance responsibility is determined by the sensitivity of the data, the organisation's own compliance objectives, and applicable laws.

That is a due-diligence artefact for the procurement boundary. It establishes that the platform carries an attestation, and it establishes nothing about how a particular team is using the service on a particular Tuesday.

AWS also notes that its newer sign-up experience is not designed for regulated workloads, and directs those customers to the advanced sign-up path or to activate advanced features. Worth confirming which path the account took before writing anything about the control environment, because the answer changes what is available.

Invocation logging is the evidence layer, once enabled

The model invocation logging documentation is precise about the default state and about coverage. Logging is off until configured. It applies to Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream. It captures calls through the bedrock-runtime endpoint, including the OpenAI-compatible Responses and Chat Completions APIs on that endpoint, and AWS states plainly that the same APIs on other endpoints such as bedrock-mantle are not currently captured.

A single log entry carries a fixed set of fields, and it is worth knowing them by name before writing a control description:

• schemaType, always ModelInvocationLog, plus schemaVersion.
• timestamp in ISO 8601 format, with accountId, region and requestId.
• operation, naming the API called, and modelId for the model or inference profile used.
• identity.arn, the AWS STS or IAM ARN of the principal that made the request, including the role name and the session or user name.
• input.inputBodyJson and output.outputBodyJson, the request and response bodies up to 100 KB, with inputTokenCount and outputTokenCount alongside them.
• requestMetadata, an optional set of caller-supplied key-value tags, present only when the caller provides them.

The identity.arn field is the one that matters for an access review, and AWS confirms it is populated automatically for every record. Every other field is automatic too, with requestMetadata as the single exception supplied by the caller. Grouping a CloudWatch Logs Insights query on identity.arn breaks usage down by principal without any caller cooperation at all.

The three limits worth writing into the control description

Request and response bodies are inline up to 100 KB. Beyond that, and for binary data such as images, the content is stored as separate objects in the S3 bucket under the data prefix, and the log entry carries a reference. A retention policy written against the log group alone leaves those objects governed by something else.

Modality selection is account-wide rather than per-model. Choosing image logging means invocation is logged for every model supporting image input or output. Teams that assume a narrow selection are often logging far more than they planned.

Destination constraints are strict. The S3 bucket or CloudWatch log group must sit in the same AWS account and Region as the logging configuration, and the bucket ACL must be disabled for the bucket policy to take effect. Centralised logging across accounts needs an explicit downstream path, and that path belongs in the evidence file with an owner.

Where a compliance review and a security review diverge

A security review of Bedrock asks whether IAM policies are scoped correctly, whether the logging destination is encrypted, and whether guardrails are applied. Our AWS Bedrock security material covers that ground, and the audit log piece covers the retrieval mechanics.

A compliance review asks a different set of questions. Who approved this configuration, on what date, against which policy version. When was it last tested. Which artefact proves the result for a named sampled request. Which processing purpose and data classification were approved for this workload.

Those questions need a change record and a test record, not a screenshot of the settings page. I would fail a control description that reads "logging is enabled" without a date, an owner, and an export showing the state at that date.

The decision layer above the log

Invocation logging records what happened. It runs after the request has been accepted, and it is a forensic artefact rather than a control. At the tempo automated attacks now run, the distinction matters: a log entry written at the moment of a policy violation documents the violation without preventing it, which is the argument set out in why AI security must be inline.

The decision that no Bedrock setting makes for you is whether this identity, holding this role, may send this specific content to this specific model right now. IAM answers whether the principal may call the API. The content of the prompt sits outside that evaluation entirely.

For a regulated workload, an evidence package for one sampled request should carry the originating identity, timestamp, model ID, the content classification assigned to the prompt, the policy version in force, the outcome, and a matching denied test. The AI governance audit framework gives the wider structure for holding those artefacts together, and the vendor risk assessment template covers the procurement side.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For Bedrock traffic deliberately routed through it, DeepInspect evaluates the supplied identity and role against organisational policy for the content classification and model authorisation before the request reaches the model.

Each decision produces a signed, tamper-evident record held outside the calling application's write path. That record joins the invocation log, the configuration snapshot, and the approval history into evidence for a single sampled request, covering non-AWS model endpoints in the same deployment under the same policy.

Book a technical deep dive at deepinspect.ai.