# Amazon Bedrock AgentCore generated observability data
<a name="observability-service-provided"></a>

For agents running in the AgentCore runtime, AgentCore automatically generates a set of session metrics which you can view in the Amazon CloudWatch Logs generative AI observability page. You can also use AgentCore observability to monitor the performance of memory, gateway, and built-in tool resources, even if you’re not using the AgentCore runtime to host your agents. For memory, gateway, and built-in tool resources, AgentCore outputs a default set of data to CloudWatch.

The following table summarizes the default data provided for each resource type, and where the data is available.


| Resource type | Service-provided data | Available in CloudWatch gen AI observability | Available in CloudWatch (Logs or metrics) | 
| --- | --- | --- | --- | 
|  Agent  |  Metrics  |  Yes  |  Yes  | 
|  Memory  |  Metrics, Spans\$1, Logs\$1  |  No  |  Yes  | 
|  Gateway  |  Metrics  |  No  |  Yes  | 
|  Tools  |  Metrics  |  No  |  Yes  | 
|  Policy  |  Metrics, Spans\$1\$1  |  Yes  |  Yes  | 
+ memory spans and logs require enablement. See [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) to learn more.
  + Policy related observability is displayed under the AgentCore Gateway tab in CloudWatch gen AI observability.

**Note**  
To view metrics, spans, and traces for AgentCore, you need to perform a one-time setup process to enable CloudWatch Transaction Search. To learn more see [Enabling AgentCore observability](observability-configure.md#observability-configure-builtin).

Refer to the following topics to learn about the default service-provided observability metrics for AgentCore runtime, memory, and gateway resources.

By instrumenting your agent code, you can also gather more detailed trace and span data as well as custom metrics. See [Enabling observability in agent code for AgentCore-hosted agents](observability-configure.md#observability-configure-custom) to learn more.

**Topics**
+ [

# AgentCore generated runtime observability data
](observability-runtime-metrics.md)
+ [

# AgentCore generate memory observability data
](observability-memory-metrics.md)
+ [

# AgentCore generated gateway observability data
](observability-gateway-metrics.md)
+ [

# AgentCore generated built-in tools observability data
](observability-tool-metrics.md)
+ [

# AgentCore generated identity observability data
](observability-identity-metrics.md)
+ [

# AgentCore generated Policy in AgentCore observability data
](observability-policy-metrics.md)

# AgentCore generated runtime observability data
<a name="observability-runtime-metrics"></a>

The runtime metrics provided by AgentCore give you visibility into your agent execution activity levels, processing latency, resource utilization, and error rates. AgentCore also provides aggregated metrics for total invocations and sessions.

**Topics**
+ [

## Observability runtime metrics
](#observability-runtime-metrics-one)
+ [

## Resource usage metrics and logs
](#observability-runtime-resource-usage-metrics-logs)
+ [

## Provided span data
](#observability-runtime-span-data)
+ [

## Application log data
](#observability-runtime-application-log-data)
+ [

## Error types
](#observability-runtime-metrics-errors)

## Observability runtime metrics
<a name="observability-runtime-metrics-one"></a>

The following list describes the runtime metrics provided by AgentCore. Runtime metrics are batched at one minute intervals. To learn more about viewing runtime metrics, see [View observability data for your Amazon Bedrock AgentCore agents](observability-view.md).

Invocations  
Shows the total number of requests made to the Data Plane API. Each API call counts as one invocation, regardless of the request payload size or response status.

Invocations (aggregated)  
Shows the total number of invocations across all resources

Throttles  
Displays the number of requests throttled by the service due to exceeding allowed TPS (Transactions Per Second) or quota limits. These requests return ThrottlingException with HTTP status code 429. Monitor this metric to determine if you need to review your service quotas or optimize request patterns.

System Errors  
Shows the number of server-side errors encountered by AgentCore during request processing. High levels of server-side errors can indicate potential infrastructure or service issues that require investigation. See [Error types](#observability-runtime-metrics-errors) for a list of possible error codes.

User Errors  
Represents the number of client-side errors resulting from invalid requests. These require user action to resolve. High levels of client-side errors can indicate issues with request formatting or permissions that need to be addressed. See [Error types](#observability-runtime-metrics-errors) for a list of possible error codes.

Latency  
The total time elapsed between receiving the request and sending the final response token. Represents complete end-to-end processing time of the request.

Total Errors  
The total number of system and user errors. In the Amazon Bedrock AgentCore console, this metric displays the number of errors as a percentage of the total number of invocations.

Session Count  
Shows the total number of agent sessions. Useful for monitoring overall platform usage, capacity planning, and understanding user engagement patterns.

Sessions (aggregated)  
Shows the total number of sessions across all resources.

ActiveStreamingConnections  
 **(WebSocket only)** Shows the current number of active WebSocket connections per agent. Monitor this metric to understand connection usage and detect connection drops or spikes for capacity planning. The only meaningful statistic is a 1-minute sum.

InboundStreamingBytesProcessed  
 **(WebSocket only)** Displays the total number of bytes successfully processed in WebSocket frames received from clients to agent containers. Use this metric to monitor data throughput and identify usage patterns.

OutboundStreamingBytesProcessed  
 **(WebSocket only)** Shows the total number of bytes successfully processed in WebSocket frames sent from agent containers to clients. Monitor this metric to understand agent response patterns and ensure successful data transmission.

## Resource usage metrics and logs
<a name="observability-runtime-resource-usage-metrics-logs"></a>

Amazon Bedrock AgentCore runtime provides comprehensive resource usage telemetry, including CPU and memory consumption metrics for your runtime resources.

**Note**  
Resource usage data may be delayed by up to 60 minutes and precision might differ across metrics.

 **Vended metrics** 

Amazon Bedrock AgentCore runtime automatically provides resource usage metrics at account, agent runtime, and agent endpoint levels. These metrics are published at 1-minute resolution. Amazon CloudWatch aggregation and metric data retention will follow standard Amazon CloudWatch data retention polices. For more information, see [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch\$1concepts.html\$1Metric](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Metric).

Here are the dimension sets and metrics available for monitoring your resources:


| Name | Dimensions | Description | 
| --- | --- | --- | 
|  CPUUsed-vCPUHours  |  Service; Service, Resource; Service, Resource, Name  |  The total amount of virtual CPU consumed in vCPU-Hours unit, available at the resource and account levels. Useful for resource tracking and estimated billing visibility.  | 
|  MemoryUsed-GBHours  |  Service; Service, Resource; Service, Resource, Name  |  The total amount of memory consumed in GB-Hours unit, available at the resource and account levels. Useful for resource tracking and estimated billing visibility.  | 

Dimension explanation
+  **Service** - AgentCore.Runtime
+  **Resource** - Agent Arn
+  **Name** - Agent Endpoint name, in the format of AgentName::EndpointName

Account level metrics are available in Amazon CloudWatch Bedrock AgentCore Observability Console under the **Runtime** tab. The dashboard displays Memory and CPU usage graphs generated from these metrics, representing total resource usage across all agents in your account within the region.

Agent Endpoint level metrics are available in AgentEndpoint page of Amazon CloudWatch Bedrock AgentCore Observability Console. The dashboard displays Memory and CPU usage graphs generated from these metrics, representing total resource usage across all sessions invoked by the specified Agent Endpoint.

**Note**  
Telemetry data is provided for monitoring purposes. Actual billing is calculated based on metered usage data and may differ from telemetry values due to aggregation timing, reconciliation processes, and measurement precision. Refer to your AWS billing statement for authoritative charges.

 **Vended logs** 

Bedrock AgentCore Runtime provides vended logs for session-level usage metrics at 1-second granularity. Each log record contains resource consumption data including CPU usage (agent.runtime.vcpu.hours.used) and memory consumption (agent.runtime.memory.gb\$1hours.used).

Each log record will have following schema:


| Log type | Log fields | Description | 
| --- | --- | --- | 
|  USAGE\$1LOGS  |  event\$1timestamp, resource\$1arn, service.name, cloud.provider, cloud.region, account.id, region, resource.id, session.id, agent.name, elapsed\$1time\$1seconds, agent.runtime.vcpu.hours.used, agent.runtime.memory.gb\$1hours.used  |  Resource Usage Logs for session-level resource tracking.  | 

To enable USAGE\$1LOG log type for your agents, see [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) . The logs are then displayed in the configured destination (AWS LogGroup, Amazon S3 or Amazon Kinesis Firehose) as configured.

In the Agent Session page of the Amazon CloudWatch Bedrock AgentCore Observability Console, you can see resource usage metrics generated from these logs. To optimize your metric viewing experience, select your desired time range using the selector in the top right to focus on specific CPU and Memory Usage data.

**Note**  
Telemetry data is provided for monitoring purposes. Actual billing is calculated based on metered usage data and may differ from telemetry values due to aggregation timing, reconciliation processes, and measurement precision. Refer to your AWS billing statement for authoritative charges.

## Provided span data
<a name="observability-runtime-span-data"></a>

To enhance observability, AgentCore provides structured spans that provide visibility into agent runtime invocations. To enable this span data, you need to enable observability on your agent resource. See [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) for steps and details. This span data is available in AWS CloudWatch Logs aws/spans log group. The following table defines the operation for which spans are created and the attributes for each captured span.


| Operation name | Span attributes | Description | 
| --- | --- | --- | 
|  InvokeAgentRuntime  |  aws.operation.name, aws.resource.arn, aws.request\$1id, aws.agent.id, aws.endpoint.name, aws.account.id, session.id, latency\$1ms, error\$1type, aws.resource.type, aws.xray.origin, aws.region  |  Invokes the agent runtime.  | 
+ aws.operation.name - the operation name (InvokeAgentRuntime)
+ aws.resource.arn - the Amazon resource name for the agent runtime
+ aws.request\$1id - request ID for the invocation
+ aws.agent.id - the unique identifier for the agent runtime
+ aws.endpoint.name - the name of the endpoint used to invoke the agent runtime
+ aws.account.id - customer’s account id
+ session.id - the session ID for the invocation
+ latency\$1ms - the latency of the request in milliseconds
+ error\$1type - either throttle, system, or user (only present if error)
+ aws.resource.type - the CFN resource type
+ aws.xray.origin - the CFN resource type used by x-ray to identify the service
+ aws.region - the region the customer resource exists in

## Application log data
<a name="observability-runtime-application-log-data"></a>

AgentCore provides structured Application logs that help you gain visibility into your agent runtime invocations and session-level resource consumption. This log data is provided when enabling observability on your agent resource. See [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) for steps and details. AgentCore can output logs to CloudWatch Logs, Amazon S3, or Firehose stream. If you use a CloudWatch Logs destination, these logs are stored under your agent’s application logs or under your own custom log group.


| Log type | Log fields | Description | 
| --- | --- | --- | 
|  APPLICATION\$1LOGS  |  timestamp, resource\$1arn, event\$1timestamp, account\$1id, request\$1id, session\$1id, trace\$1id, span\$1id, service\$1name, operation, request\$1payload, response\$1payload  |  Application logs for InvokeRuntimeOperation with tracing fields, request, and response payloads  | 
+ request\$1payload - the request payload of the agent invocation
+ response\$1payload - the response from the agent invocation

## Error types
<a name="observability-runtime-metrics-errors"></a>

The following list defines the possible error types for user, system, and throttling errors.

 **User error codes** 
+  `InvocationError.Validation` - Client provided invalid input (400)
+  `InvocationError.ResourceNotFound` - Requested resource doesn’t exist (404)
+  `InvocationError.AccessDenied` - Client lacks permissions (403)
+  `InvocationError.Conflict` - Resource conflict (409)

 **System error codes** 
+  `InvocationError.Internal` - Internal server error (500)

 **Throttling error codes** 
+  `InvocationError.Throttling` - Rate limiting (429)
+  `InvocationError.ServiceQuota` - Service-side quota/limit reached (402)

# AgentCore generate memory observability data
<a name="observability-memory-metrics"></a>

For the AgentCore memory resource type, AgentCore outputs metrics to Amazon CloudWatch by default. AgentCore also outputs a default set of spans and logs, if you enable these. See [Enabling observability for AgentCore runtime, memory, gateway, built-in tools, and identity resources](observability-configure.md#observability-configure-cloudwatch) to learn more about enabling spans and logs.

Refer to the following sections to learn more about the provided observability data for your agent memory stores.

## Provided memory metrics
<a name="memory_metrics_summary"></a>

The AgentCore memory resource type provides the following metrics by default.

Latency  
The total time elapsed between receiving the request and sending the final response token. Represents complete end-to-end processing of the request.

Invocations  
The total number of API requests made to the data plane and control plane. This metric also tracks the number of memory ingestion events.

System Errors  
Number of invocations that result in AWS server-side errors.

User Errors  
Number of invocations that result in client-side errors.

Errors  
Total number of errors that occur while processing API requests in the data plane and control plane. This metric also tracks the total errors that occur during memory ingestion.

Throttles  
Number of invocations that the system throttled. Throttled requests count as invocations, errors, and user errors.

Creation Count  
Counts the number of created memory events and memory records.

## Provided span data
<a name="memory_span_summary"></a>

To enhance observability, AgentCore provides structured spans that trace the relationship between events and the memories they generate or access. To enable this span data, you need to instrument your agent code. See [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) to learn more.

This span data is available in full in CloudWatch Logs and CloudWatch Application Signals. To learn more about viewing observability data, see [View observability data for your Amazon Bedrock AgentCore agents](observability-view.md).

The following table defines the operations for which spans are created and the attributes for each captured span.


| Operation name | Span attributes | Description | 
| --- | --- | --- | 
|   `CreateEvent`   |   `memory.id` , `session.id` , `event.id` , `actor.id` , `throttled` , `error` , `fault`   |  Creates a new event within a memory session  | 
|   `GetEvent`   |   `memory.id` , `session.id` , `event.id` , `actor.id` , `throttled` , `error` , `fault`   |  Retrieves an existing memory event  | 
|   `ListEvents`   |   `memory.id` , `session.id` , `event.id` , `actor.id` , `throttled` , `error` , `fault`   |  Lists events within a session  | 
|  DeleteEvent  |   `memory.id` , `session.id` , `event.id` , `actor.id` , `throttled` , `error` , `fault`   |  Deletes an event from memory  | 
|  RetrieveMemoryRecords  |   `memory.id` , `namespace` , `throttled` , `error` , `fault`   |  Retrieves memory records for a given namespace  | 
|  ListMemoryRecords  |   `memory.id` , `namespace` , `throttled` , `error` , `fault`   |  Lists available memory records  | 

## Provided log data
<a name="memory_logs_summary"></a>

AgentCore provides structured logs that help you monitor and troubleshoot key AgentCore Memory resource processes. To enable this log data, you need to instrument your agent code. See [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) to learn more.

AgentCore can output logs to CloudWatch Logs, Amazon S3, or Firehose stream. If you use a CloudWatch Logs destination, these logs are stored under the default log group `/aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{memory_id}` or under a custom log group starting with `/aws/vendedlogs/` . See [Enabling observability for AgentCore runtime, memory, gateway, built-in tools, and identity resources](observability-configure.md#observability-configure-cloudwatch) to learn more.

When the `DeleteMemory` operation is called, logs are generated for the start and completion of the deletion process. Any corresponding deletion error logs will be provided with insights into why the call failed.

We also provide logs for various stages in the long-term memory creation process, namely extraction and consolidation. When new short term memory events are provided, AgentCore extracts key concepts from responses to begin the formation of new long-term memory records. Once these have been created, they are integrated with existing memory records to create a unified store of distinct memories.

See the following breakdown to learn how each workflow helps you monitor the formation of new memories:

 **Extraction logs** 
+ Start and completion of extraction processing
+ Number of memories successfully extracted
+ Any errors in deserializing or processing input events

 **Consolidation logs:** 
+ Start and completion of consolidation processing
+ Number of memories requiring consolidation
+ Success/failure of memory additions and updates
+ Related memory retrieval status

The following table provides a more detailed breakdown of how different memory resource workflows use log fields alongside the log body itself to provide request-specific information.


| Workflow name | Log fields | Description | 
| --- | --- | --- | 
|  Extraction  |  resource\$1arn, event\$1timestamp, memory\$1strategy\$1id, namespace, actor\$1id, session\$1id, event\$1id, requestId, isError  |  Analyzes incoming conversations to generate new memories  | 
|  Consolidation  |  resource\$1arn, event\$1timestamp, memory\$1strategy\$1id, namespace, session\$1id, requestId, isError  |  Combines extracted memories with existing memories  | 

# AgentCore generated gateway observability data
<a name="observability-gateway-metrics"></a>

The following sections describe the gateway metrics, logs, and spans output by AgentCore to Amazon CloudWatch. These metrics aren’t available on the CloudWatch generative AI observability page. Gateway metrics are batched at one minute intervals. To learn more about viewing gateway metrics, see [View observability data for your Amazon Bedrock AgentCore agents](observability-view.md).

**Note**  
To enable service-provided logs for AgentCore gateways, you need to configure the necessary CloudWatch resources. See [Enabling observability for AgentCore runtime, memory, gateway, built-in tools, and identity resources](observability-configure.md#observability-configure-cloudwatch) to learn more.

**Topics**
+ [

## Provided metrics
](#observability-gateway-metrics-provided)
+ [

## Provided log data
](#observability-gateway-logs-provided)
+ [

## Provided spans
](#observability-gateway-vended-spans)

## Provided metrics
<a name="observability-gateway-metrics-provided"></a>

Gateway publishes invocation and usage metrics to CloudWatch. You can view these metrics and also set up alarms to alert you when certain metrics exceed thresholds. To learn more, select a topic:

**Topics**
+ [

### Invocation metrics
](#gateway-metrics-invocation)
+ [

### Usage metrics
](#gateway-metrics-usage)
+ [

### View gateway CloudWatch metrics
](#gateway-metrics-view-console)
+ [

### Setting up CloudWatch alarms
](#gateway-advanced-observability-alarms)

### Invocation metrics
<a name="gateway-metrics-invocation"></a>

These metrics provide information about API invocations, performance, and errors.

For these metrics, the following dimensions are used:
+  **Operation** – The name of the API operation (ex. InvokeGateway).
+  **Protocol** – The name of the protocol (ex. MCP).
+  **Method** – Represents the MCP operation being invoked (ex. tools/list).
+  **Resource** – Represents the identifier of the resource (ex. gateway ARN).
+  **Name** – Represents the name of the tool.


| Metric | Description | Statistics | Units | 
| --- | --- | --- | --- | 
|  Invocations  |  The total number of requests made to each Data Plane API. Each API call counts as one invocation regardless of the response status.  |  Sum  |  Count  | 
|  Throttles  |  The number of requests throttled (status code 429) by the service.  |  Sum  |  Count  | 
|  SystemErrors  |  The number of requests which failed with 5xx status code.  |  Sum  |  Count  | 
|  UserErrors  |  The number of requests which failed with 4xx status code except 429.  |  Sum  |  Count  | 
|  Latency  |  The time elapsed between when the service receives the request and when it begins sending the first response token. In other words, initial response time.  |  Average, Minimum, Maximum, p50, p90, p99  |  Milliseconds  | 
|  Duration  |  The total time elapsed between receiving the request and sending the final response token. Represents complete end-to-end processing time of the request.  |  Average, Minimum, Maximum, p50, p90, p99  |  Milliseconds  | 
|  TargetExecutionTime  |  The total time taken to execute the target over Lambda / OpenAPI / etc. This helps determine the contribution of the target to the total Latency.  |  Average, Minimum, Maximum, p50, p90, p99  |  Milliseconds  | 

### Usage metrics
<a name="gateway-metrics-usage"></a>

These metrics provide information about how your gateway is being used.


| Metric | Description | Statistics | Units | 
| --- | --- | --- | --- | 
|  TargetType  |  The total number of requests served by each type of target (MCP, Lambda, OpenAPI).  |  Sum  |  Count  | 

### View gateway CloudWatch metrics
<a name="gateway-metrics-view-console"></a>

For more information about viewing CloudWatch metrics, see [View available metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) in the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/) . The following procedure shows you how to view metrics for your gateways:

 **To view gateway metrics in the console** 

1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. In the left navigation pane, choose **All metrics** under the **Metrics** section.

1. Under **Browse** , from the dropdown menu that displays the current AWS Region, select the Region for which you want metrics.

1. Choose the **Bedrock-AgentCore** namespace.

1. Choose a dimension (ex. **Operation** ) or combination of dimensions (ex. **Method, Operation, Protocol** ) to view the metrics for it.

1. To add a metric to the CloudWatch graph, select the checkbox next to it.

### Setting up CloudWatch alarms
<a name="gateway-advanced-observability-alarms"></a>

You can use the [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) API operation to set up CloudWatch alarms to alert you when certain metrics exceed thresholds. For example, you might want to be notified when the error rate exceeds 5% or when the latency exceeds 1 second.

The following example shows you how to create an alarm for high error rates using the AWS CLI:

```
aws cloudwatch put-metric-alarm \
  --alarm-name "HighErrorRate" \
  --alarm-description "Alarm when error rate exceeds 5%" \
  --metric-name "SystemErrors" \
  --namespace "Bedrock-AgentCore" \
  --statistic "Sum" \
  --dimensions "Name=Resource,Value=my-gateway-arn" \
  --period 300 \
  --evaluation-periods 1 \
  --threshold 5 \
  --comparison-operator "GreaterThanThreshold" \
  --alarm-actions "arn:aws:sns:us-west-2:123456789012:my-topic"
```

This alarm will trigger when the number of system errors exceeds 5 in a 5-minute period. When the alarm triggers, it will send a notification to the specified SNS topic.

## Provided log data
<a name="observability-gateway-logs-provided"></a>

AgentCore provides logs that help you monitor and troubleshoot key AgentCore gateway resource processes. To enable this log data, you need to create a log destination.

AgentCore can output logs to CloudWatch Logs, Amazon S3, or Firehose stream. If you use a CloudWatch Logs destination, these logs are stored under the default log group `/aws/vendedlogs/bedrock-agentcore/gateway/APPLICATION_LOGS/{gateway_id}` or under a custom log group starting with `/aws/vendedlogs/` . See [Enabling observability for AgentCore runtime, memory, gateway, built-in tools, and identity resources](observability-configure.md#observability-configure-cloudwatch) to learn more.

AgentCore logs the following information for gateway resources:
+ Start and completion of gateway requests processing
+ Error messages for Target configurations
+ MCP Requests with missing or incorrect authorization headers
+ MCP Requests with incorrect request parameters (tools, method)

You can also see request and response bodies as part of your Vended Logs integration when any of the MCP Operations are performed on the Gateway. They can do further analysis on these logs, using the `span_id` and `trace_id` fields to connect the vended spans and logs being emitted. For more information about encrypting your gateways with customer-managed KMS keys, see [Advanced features and topics for Amazon Bedrock AgentCore Gateway](gateway-advanced.md).

Sample log:

```
{
    "resource_arn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/<gatewayid>",
    "event_timestamp": 1759370851622,
    "body": {
        "isError": false,
        "log": "Started processing request with requestId: 1",
        "requestBody": "{id=1, jsonrpc=2.0, method=tools/call, params={name=target-quick-start-f9scus___LocationTool, arguments={location=seattle}}}",
        "id": "1"
    },
    "account_id": "123456789012",
    "request_id": "12345678-1234-1234-1234-123456789012",
    "trace_id": "160fc209c3befef4857ab1007d041db0",
    "span_id": "81346de89c725310"
}
```

Sample log with response body:

```
{
    "resource_arn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/<gatewayid>",
    "event_timestamp": 1759370853807,
    "body": {
        "isError": false,
        "responseBody": "{jsonrpc=2.0, id=1, result={isError=false, content=[{type=text, text=\"good\"}]}}",
        "log": "Successfully processed request with requestId: 2",
        "id": "1"
    },
    "account_id": "123456789012",
    "request_id": "12345678-1234-1234-1234-123456789012",
    "trace_id": "160fc209c3befef4857ab1007d041db0",
    "span_id": "81346de89c725310"
}
```

## Provided spans
<a name="observability-gateway-vended-spans"></a>

AgentCore supports OTEL compliant vended spans that you can use to track invocations across different primitives that are being used.

Sample vended Spans for Tool Invocation:
+  `kind:SERVER` - tracks the overall execution details, tool invoked, gateway details, AWS request ID, trace and span ID.
+  `kind:CLIENT` - covers the specific target that was invoked and details around it like target type, target execution time, target execution start and end times, etc.

For other MCP method invocations, only the `kind:SERVER` span is emitted.

While these spans emit metrics, to investigate why a failure occurred for a specific span, a Gateway user must check the logs that are vended. Various fields, for example, `spanId` or `aws.request.id` can help in stitching these spans and logs together.


| Operation | Span attributes | Description | 
| --- | --- | --- | 
|  List Tools  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, gateway.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type, jsonrpc.error.code, http.method, http.response.status\$1code, gateway.name, url.path, overhead\$1latency\$1ms  |  List tools attached to a gateway  | 
|  Call Tool  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, gateway.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type, jsonrpc.error.code, http.method, http.response.status\$1code, gateway.name, url.path, overhead\$1latency\$1ms, tool.name  |  Call a specific tool. Two spans are emmited: 1. `kind:SERVER` which tracks the overall execution details (success / not) , tool invoked, gateway details, AWS request ID, trace and span ID. 2. `kind:CLIENT` which covers the specific target that was invoked and details around it like target type, target execution time, target execution start and end times, etc.  | 
|  Search Tools  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, gateway.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type, jsonrpc.error.code, http.method, http.response.status\$1code, gateway.name, url.path, overhead\$1latency\$1ms, tool.name  |  Search for ten most relevant tools given an input query  | 

# AgentCore generated built-in tools observability data
<a name="observability-tool-metrics"></a>

**Topics**
+ [

## Observability tools metrics
](#observability-tools-metrics-one)
+ [

## Resource usage metrics and logs
](#observability-tools-resource-usage-metrics-logs)
+ [

## Provided span data
](#observability-tools-span-data)
+ [

## Application log data
](#observability-tools-application-log-data)

## Observability tools metrics
<a name="observability-tools-metrics-one"></a>

AgentCore provides the following built-in metrics for the code interpreter and browser tools. Built-in tool metrics are batched at one minute intervals. To learn more about AgentCore tools, see [Execute code and analyze data using Amazon Bedrock AgentCore Code Interpreter](code-interpreter-tool.md) and [Interact with web applications using Amazon Bedrock AgentCore Browser](browser-tool.md).

 **Invoke tool:** 

Invocations  
The total number of requests made to the Data Plane API. Each API call counts as one invocation, regardless of the request payload size or response status.

Throttles  
The number of requests throttled by the service due to exceeding allowed TPS (Transactions Per Second) or quota limits. These requests return ThrottlingException with HTTP status code 429.

SystemErrors  
The number of server-side errors encountered during request processing.

UserErrors  
The number of client-side errors resulting from invalid requests. This require user action in order to resolve.

Latency  
The time elapsed between when the service receives the request and when it begins sending the first response token. Important for measuring initial response time.

 **Create tool session:** 

Invocations  
The total number of requests made to the Data Plane API. Each API call counts as one invocation, regardless of the request payload size or response status.

Throttles  
The number of requests throttled by the service due to exceeding allowed TPS (Transactions Per Second) or quota limits. These requests return ThrottlingException with HTTP status code 429.

SystemErrors  
The number of server-side errors encountered during request processing.

UserErrors  
The number of client-side errors resulting from invalid requests. This require user action in order to resolve.

Latency  
The time elapsed between when the service receives the request and when it begins sending the first response token. Important for measuring initial response time.

Duration  
The duration of tool session (Operation becomes CodeInterpreterSession/BrowserSession).

 **Browser user takeover:** 

TakerOverCount  
The total number of user taking over

TakerOverReleaseCount  
The total number of user releasing control

TakerOverDuration  
The duration of user taking over

## Resource usage metrics and logs
<a name="observability-tools-resource-usage-metrics-logs"></a>

Amazon Bedrock AgentCore Built-in Tools provides comprehensive resource usage telemetry, including CPU and memory consumption metrics for your runtime resources.

**Note**  
Resource usage data may be delayed by up to 60 minutes and precision might differ across metrics.

 **Vended metrics** 

By default, Bedrock AgentCore Built-in Tools vends metrics for Account level and Tool level at 1-minute resolution. Amazon CloudWatch aggregation and metric data retention follow standard Amazon CloudWatch data retention polices. For more information, see [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch\$1concepts.html\$1Metric](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Metric).


| Name | Dimensions | Description | 
| --- | --- | --- | 
|  CPUUsed-vCPUHours  |  Service; Service, Resource  |  The total amount of virtual CPU consumed in vCPU-Hours unit, available at the resource and account level. Useful for resource tracking and estimated billing visibility.  | 
|  MemoryUsed-GBHours  |  Service; Service, Resource  |  The total amount of memory consumed in GB-Hours unit, available at the resource and account levels. Useful for resource tracking and estimated billing visibility.  | 

Dimension explanation
+  **Service** - AgentCore.CodeInterpreter or AgentCore.Browser
+  **Resource** - Built-in tool Id

Account level metrics are available in the Amazon CloudWatch Bedrock AgentCore Observability Console under **Built-in Tools** tab. The dashboard on the console will contain a Memory usage graph and a CPU usage graph generated from the usage metrics. These graphs represent the total resource usage across all tools of the selected tool type in the account in the region.

Tool level metrics are available in **Tools** page of the Amazon CloudWatch Bedrock AgentCore Observability Console. The dashboard on the console will contain a Memory usage graph and a CPU usage graph generated from the usage metrics. The graphs represent the total resource usage across all sessions of the selected tool.

**Note**  
Telemetry data is provided for monitoring purposes. Actual billing is calculated based on metered usage data and may differ from telemetry values due to aggregation timing, reconciliation processes, and measurement precision. Refer to your AWS billing statement for authoritative charges.

 **Vended Logs** 

Amazon Bedrock AgentCore Built-in Tools provides the ability to enabled vended logs for session level usage telemetry at 1-second granularity. Each log record contains 1 second Resource Usage datum. Currently supported metrics include:
+ Code Interprefer codeInterpreter.vcpu.hours.used and codeInterpreter.memory.gb\$1hours.used
+ Browser browser.vcpu.hours.used and browser.memory.gb\$1hours.used

Each resource usage datum will use the following schema in the log record.

 **Code Interpreter** 


| Log type | Log fields | Description | 
| --- | --- | --- | 
|  USAGE\$1LOGS  |  event\$1timestamp, resource\$1arn, service.name, cloud.provider, cloud.region, account.id, region, resource.id, session.id, elapsed\$1time\$1seconds, codeInterpreter.vcpu.hours.used, codeInterpreter.memory.gb\$1hours.used  |  Resource Usage Logs for session-level resource tracking.  | 

 **Browser** 


| Log type | Log fields | Description | 
| --- | --- | --- | 
|  USAGE\$1LOGS  |  event\$1timestamp, resource\$1arn, service.name, cloud.provider, cloud.region, account.id, region, resource.id, session.id, elapsed\$1time\$1seconds, browser.vcpu.hours.used, browser.memory.gb\$1hours.used  |  Resource Usage Logs for session-level resource tracking.  | 

For more information about enabling logs, see [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) . These logs are theyn displayed in the destination as configured (AWS LogGroup, Amazon S3, or Amazon Kinesis Firehose.

In the Built-in Tools Session page of the Amazon CloudWatch Bedrock AgentCore Observability Console, you can see resource usage metrics generated from these logs. To optimize your metric viewing experience, select your desired time range using the selector in the top right to focus on specific CPU and Memory Usage data.

**Note**  
Telemetry data is provided for monitoring purposes. Actual billing is calculated based on metered usage data and may differ from telemetry values due to aggregation timing, reconciliation processes, and measurement precision. Refer to your AWS billing statement for authoritative charges.

## Provided span data
<a name="observability-tools-span-data"></a>

To enhance observability, AgentCore provides structured spans that provide visibility into built-in tools APIs. To enable this span data, you need to enable observability on your built-in tool resource. See [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) for steps and details. This span data is available in full in AWS CloudWatch Logs in the aws/spans log group. The following table defines the operation for which spans are created and the attributes for each captured span.

 **Code interpreter** 


| Operation name | Span attributes | Description | 
| --- | --- | --- | 
|  StartCodeInterpreterSession  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type  |  Starts a code interpreter session.  | 
|  StopCodeInterpreterSession  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type, session\$1duration\$1s  |  Stops a code interpreter session.  | 
|  InvokeCodeInterpreter  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type  |  Invokes a code interpreter with input code.  | 
|  CodeInterpreterSessionExpire  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type, session\$1duration\$1s  |  Expires a code interpreter session if StopCodeInterpreterSession is not called and the session times out.  | 
+ toolsession.id - the id of the tool session
+ session\$1duration\$1s - the duration of the session in seconds before it ended

 **Browser** 


| Operation name | Span attributes | Description | 
| --- | --- | --- | 
|  StartBrowserSession  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type  |  Starts a browser session.  | 
|  StopBrowserSession  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type, session\$1duration\$1s  |  Stops a browsersession.  | 
|  ConnectBrowserAutomationStream  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type  |  Connect to a browser automation stream.  | 
|  BrowserSessionExpire  |  aws.operation.name, aws.resource.arn, aws.request.id, aws.account.id, toolsession.id, aws.xray.origin, aws.resource.type, aws.region, latency\$1ms, error\$1type, session\$1duration\$1s  |  Expires a code interpreter session if StopBrowserSession is not called and the session times out.  | 

## Application log data
<a name="observability-tools-application-log-data"></a>

AgentCore provides structured Application logs that help you gain visibility into your agent runtime invocations and session-level resource consumption. This log data is provided when enabling observability on your agent resource. See [Add observability to your Amazon Bedrock AgentCore resources](observability-configure.md) for steps and details. AgentCore can output logs to CloudWatch Logs, Amazon S3, or Firehose stream. If you use a CloudWatch Logs destination, these logs are stored under your agent’s application logs or under your own custom log group.


| Log type | Log fields | Description | 
| --- | --- | --- | 
|  APPLICATION\$1LOGS  |  timestamp, resource\$1arn, event\$1timestamp, account\$1id, request\$1id, session\$1id, trace\$1id, span\$1id, service\$1name, operation, request\$1payload, response\$1payload  |  Application logs for InvokeCodeInterpreter with tracing fields, request, and response payloads  | 

# AgentCore generated identity observability data
<a name="observability-identity-metrics"></a>

This document described observability data emitted by the Bedrock AgentCore Identity Service. This data provides visibility into the performance, usage, and operational health of the service, allowing your to monitor authorization activities for your AI agents and workloads.

You can use the identity observability data described in this section in the following ways:
+ Monitor usage: track API call volume and throttling events across workload identities and credential providers
+ Track inbound authorization: monitor success/failure rates for workload access token operations
+ Analyze Resource Access Patterns: gain insights into OAuth2 providers and API key usage patterns by provider type and flow
+ Troubleshoot issues: identify and diagnose errors by type, operation, and resource
+ Capacity planning: use metrics to understand usage patterns and plan for scaling

These metrics can be viewed in the Amazon CloudWatch console, retrieved via the Amazon CloudWatch API, or incorporated into Amazon CloudWatch dashboards and alarms for proactive monitoring.

**Topics**
+ [

## Usage, authorization, and resource access metrics
](#observability-identity-usage-auth-ra-metrics)
+ [

## Provided span data
](#observability-identity-span-data)
+ [

## Provided log data
](#observability-identity-log-data)

## Usage, authorization, and resource access metrics
<a name="observability-identity-usage-auth-ra-metrics"></a>

The following dimensions reference applies to the metrics described in this section:
+ WorkloadIdentity: the workload identity name making the request.
+ WorkloadIdentityDirectory: the directory containing the workload identity (typically `default` ).
+ TokenVault: the token vault being accessed (typically `default` ).
+ ProviderName: the name of the credential provider (for example, `MyGoogleProvider` , `MySlackProvider` ).
+ FlowType: the OAuth2 flow type (USER\$1FEDERATION, M2M).
+ ExceptionType: the specific error type (ValidationException, ThrottlingException, etc.)

### Usage metrics
<a name="observability-identity-metrics-usage"></a>

These metrics are emitted in the AWS/Usage namespace and track service usage at the AWS account level.


| Metric name | Dimensions | Description | 
| --- | --- | --- | 
|  CallCount  |  Service, Type, Class, Resource  |  Tracks the number of calls made to Identity Service operations. This can be used for service quotas.  | 
|  ThrottleCount  |  Service, Type, Class, Resource  |  Tracks the number of throttled calls for Identity Service operations.  | 

### Authorization metrics
<a name="observability-identity-metrics-authorization"></a>

These metrics are emitted in the AWS/Bedrock-AgentCore namespace and provide insights into authentication and authorization operations.


| Metric name | Dimensions | Description | 
| --- | --- | --- | 
|  WorkloadAccessTokenFetchSuccess  |  WorkloadIdentity, WorkloadIdentityDirectory, Operation  |  Tracks successful workload access token fetch operations.  | 
|  WorkloadAccessTokenFetchFailures  |  WorkloadIdentity, WorkloadIdentityDirectory, Operation, ExceptionType  |  Tracks failed workload access token fetch operations by exception type.  | 
|  WorkloadAccessTokenFetchThrottles  |  WorkloadIdentity, WorkloadIdentityDirectory, Operation  |  Tracks throttled workload access token fetch operations.  | 

### Resource access metrics
<a name="observability-identity-resource-access-metrics"></a>

These metrics track credential provider operations for accessing external resources.


| Metric name | Dimensions | Description | 
| --- | --- | --- | 
|  ResourceAccessTokenFetchSuccess  |  WorkloadIdentity, WorkloadIdentityDirectory, TokenVault, ProviderName, Type  |  Tracks successful OAuth2 token fetch operations from credential providers.  | 
|  ResourceAccessTokenFetchFailures  |  WorkloadIdentity, WorkloadIdentityDirectory, TokenVault, ProviderName, Type, ExceptionType  |  Tracks failed OAuth2 token fetch operations by exception type.  | 
|  ResourceAccessTokenFetchThrottles  |  WorkloadIdentity, WorkloadIdentityDirectory, TokenVault, ProviderName, Type  |  Tracks throttled OAuth2 token fetch operations.  | 
|  ApiKeyFetchSuccess  |  WorkloadIdentity, WorkloadIdentityDirectory, TokenVault, ProviderName  |  Tracks successful API key fetch operations.  | 
|  ApiKeyFetchFailures  |  WorkloadIdentity, WorkloadIdentityDirectory, TokenVault, ProviderName, ExceptionType  |  Tracks failed API key fetch operations by exception type.  | 
|  ApiKeyFetchThrottles  |  WorkloadIdentity, WorkloadIdentityDirectory, TokenVault, ProviderName  |  Tracks throttled API key fetch operations.  | 

## Provided span data
<a name="observability-identity-span-data"></a>

To enhance observability, AgentCore Identity provides structured spans that give visibility into identity service operations. To enable span data, you need to enable observability on your workload identity or credential provider resource.

This span data is available in Amazon CloudWatch Logs aws/spans log group. The following table defines operations for which spans are created and their attributes.

The following attribute explanations apply to the information in the tables below:
+ aws.operation.name - the operation name being performed
+ aws.resource.arn - the Amazon Resource Name for the identity resource
+ aws.request\$1id - unique request ID for the operation
+ aws.account.id - user’s AWS account ID
+ workload.identity.id - the workload identity name
+ workload.identity.directory - the workload identity directory
+ credential.provider.name - name of the credential provider
+ credential.provider.type - type of credential provider (OAuth2, API Key)
+ token.vault.name - token vault name
+ oauth2.flow - OAuth2 flow type (USER\$1FEDERATION, M2M)
+ latency\$1ms - operation latency in milliseconds
+ error\$1type - error classification (throttle, system, user, null if successful)
+ aws.region - AWS region where the operation occurred

 **Workload Identity Operations** 


| Operation | Span attributes | Description | 
| --- | --- | --- | 
|  GetWorkloadAccessToken  |  aws.operation.name, aws.resource.arn, aws.request\$1id, aws.account.id, workload.identity.id, workload.identity.directory, aws.region, latency\$1ms, error\$1type  |  Fetches workload access token for machine-to-machine authentication  | 
|  GetWorkloadAccessTokenForJWT  |  aws.operation.name, aws.resource.arn, aws.request\$1id, aws.account.id, workload.identity.id, workload.identity.directory, issuer, user\$1sub, aws.region, latency\$1ms, error\$1type  |  Fetches workload access token using JWT user token  | 
|  GetWorkloadAccessTokenForUserId  |  aws.operation.name, aws.resource.arn, aws.request\$1id, aws.account.id, workload.identity.id, workload.identity.directory, aws.region, latency\$1ms, error\$1type  |  Fetches workload access token for specific user ID  | 

 **Credential Provider Operations** 


| Operation | Span attributes | Description | 
| --- | --- | --- | 
|  GetResourceOAuth2Token  |  aws.operation.name, aws.resource.arn, aws.request\$1id, aws.account.id, workload.identity.id, credential.provider.name, credential.provider.type, token.vault.name, oauth2.flow, aws.region, latency\$1ms, error\$1type  |  Fetches OAuth2 access token from credential provider  | 
|  GetResourceAPIKey  |  aws.operation.name, aws.resource.arn, aws.request\$1id, aws.account.id, workload.identity.id, credential.provider.name, token.vault.name, aws.region, latency\$1ms, error\$1type  |  Fetches API key from credential provider  | 

## Provided log data
<a name="observability-identity-log-data"></a>

AgentCore Identity provides structured application logs that help you gain visibility into identity service operations. This log data is provided when enabling observability on your identity resources.

AgentCore can output logs to Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Firehose stream. If you use a CloudWatch Logs destination, these logs are stored under your resource’s application logs or under your own custom log group.


| Log type | Log fields | Description | 
| --- | --- | --- | 
|  Application Logs  |  timestamp, resource\$1arn, event\$1timestamp, account\$1id, request\$1id, trace\$1id, span\$1id, service\$1name, operation, request\$1payload, response\$1payload  |  Application logs for Identity Service operations with tracing fields, request, and response payloads  | 

Log field explanations:
+ timestamp - Unix timestamp of the log event
+ resource\$1arn - ARN of the identity resource
+ event\$1timestamp - ISO 8601 timestamp string
+ account\$1id - AWS account ID
+ request\$1id - unique request identifier
+ trace\$1id - distributed tracing ID
+ span\$1id - span identifier for the operation
+ service\$1name - service name (BedrockAgentCore.Identity)
+ operation - pperation name (GetWorkloadAccessToken, etc.)
+ request\$1payload - request payload
+ response\$1payload - response payload

# AgentCore generated Policy in AgentCore observability data
<a name="observability-policy-metrics"></a>

For policy and policy engine resource types, Amazon Bedrock AgentCore publishes invocation metrics to CloudWatch by default. Additional span data is available when traces are enabled for the attached AgentCore Gateway resource, which will emit spans for Policy in AgentCore related operations. See [Enabling observability for AgentCore runtime, memory, gateway, built-in tools, and identity resources](observability-configure.md#observability-configure-cloudwatch) to learn more about enablement.

**Topics**
+ [

## Provided metric data
](#observability-policy-metrics-provided)
+ [

## Provided span data
](#observability-policy-spans)

## Provided metric data
<a name="observability-policy-metrics-provided"></a>

Amazon Bedrock AgentCore publishes the following invocation metrics by default to the `Bedrock-Agentcore` CloudWatch namespace. These metrics can be used to observe and monitor policy evaluations and overall performance.


| Metric | Description | Unit | 
| --- | --- | --- | 
|  Invocations  |  Number of requests made to the service  |  Count  | 
|  SystemErrors  |  Number of server-side errors (5xx)  |  Count  | 
|  UserErrors  |  Number of client-side errors (4xx)  |  Count  | 
|  Latency  |  Total time elapsed from sending a request to receiving a response  |  Milliseconds  | 
|  AllowDecisions  |  Number of decisions that resulted in ALLOW  |  Count  | 
|  DenyDecisions  |  Number of decisions that resulted in DENY  |  Count  | 
|  TotalMismatchedPolicies  |  Number of failed policies for a given request due to either missing attribute or type mismatch  |  Count  | 
|  PolicyMismatch  |  Number of failures for a specific policy caused by missing attribute or type mismatch  |  Count  | 
|  MismatchErrors  |  Number of requests that failed due to at least one mismatched policy  |  Count  | 
|  DeterminingPolicies  |  Number of determining policies for a request  |  Count  | 
|  NoDeterminingPolicies  |  Number of requests denied due to no determining policies  |  Count  | 

### Metric Dimensions
<a name="observability-policy-metrics-dimensions"></a>

The following dimensions are available for the above metrics. These dimensions allow you to filter and analyze metric data at finer levels of detail.


| Dimension | Description | 
| --- | --- | 
|  OperationName  |  The name of the API operation, valid values are `AuthorizeAction` and `PartiallyAuthorizeActions`   | 
|  PolicyEngine  |  The Policy Engine identifier associated with the metric  | 
|  Policy  |  The Policy identifier associated with the metric  | 
|  TargetResource  |  The AgentCore Gateway resource identifier associated with the request  | 
|  ToolName  |  The name of the tool the metric applies to  | 
|  Mode  |  The enforcement mode configured on the AgentCore Gateway, valid values are `LOG_ONLY` and `ENFORCE`   | 

## Provided span data
<a name="observability-policy-spans"></a>

Amazon Bedrock AgentCore provides additional structured span data through AgentCore Gateway observability, offering deeper insights into API invocations. Policy in AgentCore span data is available after enabling traces for your AgentCore Gateway resource and can be found in CloudWatch `aws/spans` log group.


| Operation | Span Attribute | Description | 
| --- | --- | --- | 
|  AuthorizeAction  |  aws.agentcore.policy.authorization\$1decision  |  The authorization decision after evaluating policies, valid values are `ALLOW` and `DENY`   | 
|  |  aws.agentcore.policy.authorization\$1reason  |  Reason for the authorization decision  | 
|  |  aws.agentcore.policy.determining\$1policies  |  List of Policy identifiers that determined the decision outcome  | 
|  |  aws.agentcore.policy.mismatched\$1policies  |  List of Policy identifiers that failed due to missing attributes or type mismatches  | 
|  |  aws.agentcore.policy.target\$1resource.id  |  AgentCore Gateway resource identifier the request applies to  | 
|  |  aws.agentcore.gateway.policy.arn  |  Policy Engine Amazon Resource Name (ARN) configured on the AgentCore Gateway  | 
|  |  aws.agentcore.gateway.policy.mode  |  Policy Engine enforcement mode configured on the AgentCore Gateway, valid values are `LOG_ONLY` and `ENFORCE`   | 
|  PartiallyAuthorizeActions  |  aws.agentcore.policy.allowed\$1tools  |  List of tool names that evaluated to an `ALLOW` decision  | 
|  |  aws.agentcore.policy.denied\$1tools  |  List of tool names that evaluated to a `DENY` decision  | 
|  |  aws.agentcore.policy.target\$1resource.id  |  AgentCore Gateway resource identifier the request applies to  | 
|  |  aws.agentcore.gateway.policy.arn  |  Policy Engine Amazon Resource Name (ARN) configured on the AgentCore Gateway  | 
|  |  aws.agentcore.gateway.policy.mode  |  Policy Engine enforcement mode configured on the AgentCore Gateway, valid values are `LOG_ONLY` and `ENFORCE`   |