Observability, Usage & Analytics

Enabling CloudTrail Audit Coverage for bedrock-mantle Inference Calls

On the legacy Bedrock surface, every inference call landed in CloudTrail automatically. On the current Claude in Amazon Bedrock surface, it does not — and teams that assume otherwise have an audit gap they haven't noticed yet.

Claude 3P 101 · Updated July 2026 · Unofficial guide

AWS CloudTrail is the service that records "who called which API, when, from where" across an AWS account — the backbone of most cloud audit programs. CloudTrail distinguishes two event classes, and the distinction is exactly where the trap sits. Management events are control-plane operations; they are logged by default at no extra charge. Data events are high-volume data-plane operations; they are off by default, must be enabled explicitly, and incur CloudTrail data-event charges.

On the legacy bedrock-runtime surface, the inference operations — InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream — are logged as management events: on by default, free, present in every trail. On the current bedrock-mantle surface (the endpoint behind the AnthropicBedrockMantle client and Anthropic's Messages API on Bedrock), inference is a data event. AWS's documentation is explicit: if you require an audit trail of inference calls on bedrock-mantle, you must explicitly enable data event capture.

The double miss: even if your organization already captures some Bedrock data events, filters written against bedrock.amazonaws.com or bedrock-runtime.amazonaws.com still miss the new surface. bedrock-mantle events carry eventSource: bedrock-mantle.amazonaws.com and AWS::BedrockMantle::* resource types — a different event source and different resource types from everything the legacy surface emits.

What the mantle events look like

The inference data event is CreateInference. It covers all three API shapes the mantle endpoint serves: the OpenAI Responses API (/v1/responses), OpenAI Chat Completions (/v1/chat/completions), and Anthropic's Messages API (/anthropic/v1/messages). Token counting has its own data event, CountTokens, for /anthropic/v1/messages/count_tokens.

A CreateInference record captures request parameters such as model, stream, and (on the Messages route) max_tokens, plus service-added fields like callWithBearerToken and bearerTokenType that tell you how the caller authenticated. It does not capture prompt or completion bodies — CloudTrail answers "who called what," not "what was said." (Neither does CloudTrail on the legacy surface; and note that prompt/completion invocation logging is not available for bedrock-mantle calls at all — see the invocation log schema guide.)

Management events on the mantle surface still arrive by default: model listing, fine-tuning operations, and project create/read/update/delete are all covered without extra configuration. It is only the inference path that needs opting in.

Enabling capture

Data events are enabled on a trail (or CloudTrail Lake event data store) using advanced event selectors — CloudTrail's filter language for choosing which data events to record. The essentials for this surface:

One sharp edge: metadata is logged verbatim

AWS documents a warning worth quoting to your developers: customer-supplied metadata on CreateInference calls is logged verbatim in CloudTrail. Do not include secrets, credentials, or other sensitive values in metadata if you are capturing data events. Request metadata is great for attribution — see requestMetadata tags on the legacy surface for the parallel pattern — but once data events are on, anything you put there becomes part of your audit record, visible to everyone with CloudTrail access.

Fitting this into an audit posture

Anthropic's Bedrock page says Claude in Amazon Bedrock emits logs to both CloudWatch and CloudTrail — which is true, but on the current surface that means CloudWatch metrics (in the AWS/BedrockMantle namespace — see the namespace guide) and CloudTrail events you must opt into. If your compliance program expects a record of every inference call, treat enabling these data events as part of initial setup, not an afterthought, and confirm coverage by querying for CreateInference events after your first test traffic. On the legacy surface, GuardDuty additionally analyzes Bedrock CloudTrail activity for suspicious behavior; the audit story you build should account for both surfaces during any migration period.

Where to go next

Bedrock CloudTrail API events covers the legacy surface in detail, and the audit logging overview compares audit trails across all four platforms.

Sources