Bedrock AgentCore Audit Logs: Build a Four-Record Evidence Map

Amazon Bedrock AgentCore produces several useful evidence streams. OpenTelemetry-compatible traces describe an agent workflow. CloudWatch stores metrics and logs, including spans. CloudTrail records supported service API activity, including AgentCore Gateway management events and an optional data event for InvokeGateway. IAM policies define which AWS principals may take actions on AgentCore resources. I want to put those records on separate sheets because the phrase "AgentCore audit log" can hide four different questions.

TL;DR

• AgentCore telemetry records workflow execution and operational metrics, with spans and logs in CloudWatch.
• CloudTrail records supported service actions. Gateway InvokeGateway data events require explicit enablement.
• IAM evidence explains an AWS principal's permissions on AgentCore resources at a given time.
• A separate model-route decision record is needed when an enterprise must prove why one authenticated HTTP model call was allowed or denied, including any redaction.

AgentCore telemetry reconstructs workflow execution

AWS describes AgentCore Observability across tracing, telemetry, metrics and monitoring, plus audit logging. AgentCore emits telemetry in an OpenTelemetry-compatible format. Its CloudWatch-backed dashboards can show session count and latency alongside duration, token usage, and error rates. Runtime visualizations expose execution paths and intermediate outputs, including bottlenecks and failures.

That data is the first sheet in the evidence map. Record the AgentCore resource and session or trace identifier, then add the UTC window, relevant spans, and the CloudWatch log group used for collection. Preserve the query and export time beside the raw result. A screenshot of a trace waterfall is useful during triage, while the underlying spans make the result repeatable.

Telemetry answers what the agent runtime did and where execution slowed or failed. Instrumentation choices determine the detail available. AWS says AgentCore emits built-in metrics for agents and for both Gateway and memory resources. Memory spans and logs require enablement, and custom agent telemetry requires code instrumentation. An evidence package should state those settings instead of treating an empty span field as proof that no step occurred.

CloudTrail separates management activity from Gateway invocation

AgentCore's current observability page says CloudTrail coverage is available for certain capabilities, specifically AgentCore Gateway and Agent Registry. The Gateway CloudTrail guide says CloudTrail captures Gateway API calls from the console and code, recording the request and caller along with the time and additional details.

Management events cover gateway or target operations, including creating and updating as well as listing and deleting. Event history provides the previous 90 days of recorded management events in a Region. A trail or CloudTrail Lake event data store is required for an ongoing record beyond that window.

Gateway invocation belongs to the data-event path. AWS lists InvokeGateway for the AWS::BedrockAgentCore::Gateway resource type and says Gateway data events require explicit enablement. Event history excludes data events, and additional CloudTrail charges apply. A deployment can therefore have complete gateway-administration history while its invocation evidence remains absent.

I would test both paths with a bright orange card on the review desk. Create or update a non-production target, invoke the test Gateway once, then retrieve the management event separately from the data event. Preserve the event selector with the exports. One successful management event proves very little about data-event configuration.

Gateway data events carry a JWT subject

AgentCore Gateway data events use a different identity shape from standard AWS data events. The Gateway Data API follows MCP and uses JWT authentication instead of SigV4. AWS says CloudTrail logs specific JWT claims such as sub, and routes the data event only to the resource owner's account. AWS also recommends a GUID or pairwise identifier in sub instead of an email address or other PII.

That subject is valuable attribution evidence when the issuer and audience are preserved alongside the token-validation settings and subject mapping. Add those facts to the evidence map. An investigator should be able to resolve the pairwise identifier through a controlled identity record without copying a person's email into every CloudTrail event.

Error handling has its own collection detail. AgentCore Gateway places error information inside responseElements, rather than top-level errorCode and errorMessage fields. Searches for access denials need to parse that nested object. A SIEM rule built around the usual CloudTrail error fields can miss the denial even though AWS recorded it.

The AWS AI Gateway comparison separates AgentCore from the API Gateway reference pattern. It also covers Bedrock Guardrails and AWS multi-provider guidance. For this audit, keep the target narrow: prove the exact AgentCore capability and event type, then record the identity field and collection setting used.

IAM evidence explains AWS resource authority

The AgentCore IAM documentation separates authentication from authorization. A principal can be a root user or IAM user, an assumed role or federated identity, or an AWS service. Policies specify the principal and permitted actions, together with the resources and conditions. By default, users and roles have no permissions.

IAM is the third sheet. For one test principal, retain the role ARN and session context. Add the attached identity policies, relevant resource policies, permissions boundary, organization controls, session policy, and policy version or retrieval timestamp. Then preserve the allowed or denied AgentCore API request in CloudTrail. That package explains why AWS accepted the service action under the policy state you collected.

Human users should use federation and temporary credentials, according to AWS guidance. A role session can connect an AWS action to a federated identity when the session evidence survives. Agent workflows also use service identities, so the principal in a record may identify the runtime rather than the person who started a business task. The post-authentication gap explains why the originating user and agent identity need separate fields, as does the task identifier when authority crosses system boundaries.

Model-route authorization is a separate evidence decision

The fourth sheet applies to an authenticated HTTP call deliberately routed from an application to an LLM endpoint. Its question is specific: which enterprise rule allowed this principal to send this data class to this model destination at that moment?

AgentCore telemetry can show workflow steps. CloudTrail can show a supported API action and its subject or AWS principal. IAM can show authority to call an AWS API on a resource. The cited schemas and service descriptions do not establish a required record that binds the authenticated application principal and prompt classification to the model destination and enterprise policy version, including the decision reason and an allow or deny outcome with any redaction.

Build the correlation before production. Give the application request a stable identifier and carry it into the model-route decision record as well as the telemetry attributes that the deployment controls. Preserve provider request identifiers where available. The AI audit log schema guide gives the route-level field set, while AWS Bedrock audit logs covers Bedrock model invocation logging and its separate relationship to CloudTrail.

This split also prevents an inflated product claim. AgentCore Runtime execution and MCP tool calls keep their own controls and evidence, as do browser actions, code execution, memory operations, and downstream business API effects. A model-route record covers only the routed model request and response that crossed that inspection point.

DeepInspect

DeepInspect applies only when an application deliberately routes an authenticated HTTP model call through its proxy. It evaluates the supplied identity context and prompt classification against the model destination and versioned policy before forwarding the request. The resulting per-decision audit record carries the route decision and correlation identifier needed to join that call to AWS evidence across AgentCore telemetry and CloudTrail, with IAM policy evidence alongside it.

DeepInspect does not inspect AgentCore Runtime internals or MCP tool execution. It also does not inspect browser sessions, code interpreter activity, memory operations, or downstream API effects. Those remain with AgentCore and CloudTrail, with further evidence held by IAM, application logs, and the target systems. The useful composition is narrow: AWS records the platform activity it owns, while DeepInspect records the authorization decision for routed model traffic it sees.

Book a demo today.