Amazon Bedrock Inference Endpoints and API Keys - What bedrock-runtime and bedrock-mantle Each Accept, Which IAM Action Each Call Checks, and What CloudTrail Records

First Published: 2026-09-30
Last Updated: 2026-09-30

Applications that call models in Amazon Bedrock send requests to one of two inference endpoints: bedrock-runtime.{region}.amazonaws.com and bedrock-mantle.{region}.api.aws. As of September 28, 2026, both endpoints accept OpenAI-compatible Responses API and Chat Completions API, as well as Anthropic's Messages API. The Amazon Bedrock User Guide states that the same Mantle inference engine powers both endpoints. However, the endpoint to which the request is sent determines the available APIs and features, the IAM actions that are checked, the actions required to disable Bedrock API key usage, and the type of information recorded in CloudTrail.

Four key questions are likely to be of interest to developers using the OpenAI SDK, Anthropic SDK, or AWS SDK to call Amazon Bedrock, as well as those responsible for controlling access to Amazon Bedrock through IAM, SCP, and CloudTrail: Which endpoint should new applications target? Do existing applications currently using bedrock-mantle need to be migrated? Which IAM actions should be denied to disable Bedrock API key usage within an organization? Are detection rules missing any requests to one of the endpoints?

The answers to these questions can all be found in AWS documentation. The central resource is the table and notes on the "Endpoints supported by Amazon Bedrock" page in the User Guide. The rest is spread across the User Guide's pages on the Responses API, API keys, and CloudTrail, and the AWS Security Blog. This article will outline the differences between the two endpoints, based on the information provided in these resources. This article does not compare which endpoint is newer or faster. It will not cover quotas, model availability, or the design of AWS PrivateLink (section 1.4).

Related articles on this site:

1. The Scope of This Article and the Date It Was Verified
2. One Inference Engine and Two Endpoints
3. Support by API
4. Support by Capability
5. Authentication — SigV4 and Bedrock API Keys
6. The Signal Table — What the Endpoint and the API Key Leave in IAM and CloudTrail
7. IAM — Which Action Each Call Checks
8. CloudTrail — What Is Recorded, and as Which Kind of Event
9. What to Do with Existing Applications
10. Frequently Asked Questions about Amazon Bedrock Inference Endpoints and API Keys
11. Summary
12. References

1. The Scope of This Article and the Date It Was Verified

This section will confirm which of the two endpoints the User Guide recommends, and document when that recommendation changed for each source. Furthermore, it will outline how Anthropic's documentation describes the endpoints, and specify what this article will not cover.

1.1 Two Endpoints, and a Recommendation from the User Guide

The Amazon Bedrock User Guide, specifically the "Endpoints supported by Amazon Bedrock" page, states as of September 28, 2026:

For most new applications, use the bedrock-runtime endpoint. Use bedrock-mantle when you specifically need capabilities that are currently available only there, such as server-side and pre-configured tools (including web search), background inference, Projects, or Workspaces.

The User Guide recommends using bedrock-runtime for most new applications, and using bedrock-mantle when you specifically need capabilities that are currently available only there. The endpoint table on the same page only lists (recommended) next to the entry for bedrock-runtime.{region}.amazonaws.com.

The same page's notes clarify the relationship between the two endpoints:

Both endpoints use the same underlying Mantle inference engine and benefit from Mantle's zero operator access (ZOA) design. The bedrock-mantle name identifies an endpoint surface, not a different inference engine.

bedrock-mantle is the name of an endpoint, not the name of a separate inference engine. This article refers to the inference engine as the Mantle inference engine, and writes bedrock-mantle to denote the endpoint, to keep the two apart.

Similar recommendations appear on other pages of the User Guide. The Responses API page, for example, goes further:

Use bedrock-runtime for new applications. Use bedrock-mantle only when a model or capability that you require isn't available on bedrock-runtime.

The Chat Completions API page, the Messages API page, the Projects page, the Workspaces page, and the "Scaling and throughput best practices" page also recommend using bedrock-runtime for new applications. This article verified its statements with AWS documentation on September 28, 2026.

1.2 The Point at Which the Recommendations Changed

The point at which the User Guide began recommending bedrock-runtime was August 2026. The versions archived by the Internet Archive on June 1, 2026, and August 4, 2026, recommended bedrock-mantle for new applications. The dates in the following table correspond to the dates listed in the User Guide's Document history, the publication date of the What's New post, and the dates when the Internet Archive recorded the User Guide pages.

Date	Source	Relevant Change
December 3, 2025	User Guide's Document history	Addition of OpenAI-compatible API endpoints (Responses API and Chat Completions API).
December 4, 2025	What's New	Introduction of the Responses API on the new OpenAI-compatible endpoints. Also announced Project Mantle as the new distributed inference engine.
August 4, 2026	"Endpoints supported by Amazon Bedrock" page (Internet Archive)	Version recommending `bedrock-mantle` for new applications.
August 15, 2026	User Guide's Document history	The User Guide was updated to recommend `bedrock-runtime` for new applications throughout.
August 17, 2026	What's New	OpenAI's GPT-5.6 models were made available on `bedrock-runtime`, enabling the use of the Responses API, Converse API, and Chat Completions API.
August 17, 2026	"Endpoints supported by Amazon Bedrock" page (Internet Archive)	Version recommending `bedrock-runtime` for new applications.
August 19, 2026	User Guide's Document history	Examples for the Messages API and examples from the OpenAI SDK (for 49 model cards) were updated to point to `bedrock-runtime`.
September 15, 2026	User Guide's Document history	Made `bedrock-runtime` the recommended path for new Responses API and Chat Completions API integrations.

The page archived by the Internet Archive on August 4, 2026, read:

For new applications, we recommend the bedrock-mantle endpoint.

The page archived on August 17, 2026, read:

For new applications, we recommend the bedrock-runtime endpoint.

The User Guide's Document history states the following regarding changes made on August 15, 2026:

Updated the endpoint and API guidance across the Amazon Bedrock User Guide to recommend the bedrock-runtime endpoint for new applications, including for OpenAI- and Anthropic-compatible workloads.

Some older materials and examples, written before August 15, 2026, recommend bedrock-mantle. When reviewing any material, it is important to verify the date it was written. As of September 28, 2026, the recommended phrasing has further evolved from the version dated August 17, 2026 (as seen in section 1.1).

The availability date for the Responses API differs by one day depending on the source. The What's New post was published on December 4, 2025 (UTC), while the User Guide's Document history indicates December 3, 2025. The What's New post published on December 4, 2025, introduces "Mantle" as the name for the inference engine from the outset.

Project Mantle, a new distributed inference engine for large-scale machine learning model serving on Amazon Bedrock

1.3 How Anthropic's Documentation Describes the Endpoints

As of September 28, 2026, Anthropic's Claude API documentation directs users to the Amazon Bedrock Messages API using the bedrock-mantle endpoint. The "Claude in Amazon Bedrock" page lists the endpoint as:

The endpoint follows the pattern https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages.

That same page also guides users to a separate page detailing the pathways for using InvokeModel and Converse, presenting it as the previous integration.

The previous Amazon Bedrock integration (the InvokeModel and Converse APIs with ARN-versioned model identifiers) remains available and is documented at Claude on Amazon Bedrock (Opus 4.6 and earlier).

In contrast, the Amazon Bedrock User Guide's Messages API page lists https://bedrock-runtime.{region}.amazonaws.com/anthropic on bedrock-runtime as the endpoint for new applications. Users of the Anthropic SDK will find that the endpoint information provided in Anthropic's documentation differs from that provided in AWS's documentation. This article will follow the descriptions in AWS's documentation regarding what is available on each endpoint, which IAM actions are checked, and what is logged. Anthropic's documentation briefly describes an IAM policy for blocking long-term keys, but unlike the User Guide's policy examples and the AWS Security Blog, it denies only bedrock:CallWithBearerToken (section 7.5).

1.4 Items Not Covered

This article does not address the following:

Quotas and Throughput. The two endpoints have different quota structures. Amazon Bedrock Inference Throughput and Latency Optimization covers this.
Model Availability. Which models are available on each endpoint can be found on the "Endpoint availability" page and each model's model card in the User Guide. This article does not provide a list of models.
AWS PrivateLink and Endpoint Policies. Section 6 of Amazon Bedrock Security and Governance covers this topic.
Cross-Region Inference Design. Amazon Bedrock Cross-Region Inference and Data Residency Design addresses this.
API Parameter Compatibility. LLM API Parameter Compatibility Reference details the compatibility of parameters across OpenAI, Anthropic, and Amazon Bedrock. This article only addresses the endpoint-specific notes provided in the User Guide.
GuardDuty Detection and Model Invocation Logging. Threat Detection for AI Workloads on AWS covers what Amazon GuardDuty detects. Amazon Bedrock Security and Governance covers configuring model invocation logging.
API Key Format. This article does not cover the format of the keys themselves.

2. One Inference Engine and Two Endpoints

This section lists the hostnames and paths for the two endpoints, and clarifies what it means to use the same inference engine. Figure 1 illustrates the path from the client, through the two endpoints, to the Mantle inference engine.

2.1 Hostnames and Paths

The two endpoints have different domain names. bedrock-runtime resides under amazonaws.com, while bedrock-mantle is under api.aws. OpenAI-compatible APIs and Anthropic's Messages API are both available under the paths of either endpoint. The following table lists the URLs referenced on the User Guide pages for the Responses API, Chat Completions API, and Messages API.

API	`bedrock-runtime`	`bedrock-mantle`
Responses API	`https://bedrock-runtime.{region}.amazonaws.com/openai/v1` (base URL for the OpenAI SDK)	`https://bedrock-mantle.{region}.api.aws/v1` (base URL for the OpenAI SDK; for some models, the model card shows `/openai/v1`)
Chat Completions API	`https://bedrock-runtime.{region}.amazonaws.com/openai/v1/chat/completions`	`https://bedrock-mantle.{region}.api.aws/v1/chat/completions`
Messages API	`https://bedrock-runtime.{region}.amazonaws.com/anthropic` (base URL for the Anthropic SDK)	`https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages`
InvokeModel, Converse	AWS SDK client for `bedrock-runtime`	Not provided

The "Endpoints supported by Amazon Bedrock" page states the following regarding the OpenAI-compatible APIs on bedrock-runtime:

The OpenAI-compatible APIs are called on the /openai/v1 paths of this endpoint rather than through the AWS SDKs.

The documented paths for the OpenAI-compatible APIs can differ by endpoint. On bedrock-runtime, the path is /openai/v1. On bedrock-mantle, the Responses API and Chat Completions API pages indicate /v1. However, as of September 28, 2026, the model card for the GPT-5.6 Sol model indicates https://bedrock-mantle.{region}.api.aws/openai/v1 as the base URL for bedrock-mantle. The model card for gpt-oss-120b indicates https://bedrock-mantle.{region}.api.aws/v1. It is necessary to verify the base URL for bedrock-mantle by checking the model card for the model you are using. When directing existing OpenAI SDK code to either endpoint, note that the hostname changes, and the path can change as well.

The Responses API page instructs users to configure the OPENAI_API_KEY environment variable with their Bedrock API key and set the OPENAI_BASE_URL to the endpoint, and explicitly states:

Do not use your OpenAI API key or the OpenAI base URL (https://api.openai.com/v1). Those connect to OpenAI directly, not to Amazon Bedrock.

When this article refers to "API key," it means the Amazon Bedrock API key (Bedrock API key). It does not refer to OpenAI API keys or Anthropic API keys.

2.2 The Significance of Using the Same Inference Engine

The User Guide states that the same Mantle inference engine powers both endpoints (section 1.1). A note on the same page continues, regarding existing OpenAI SDK code:

Existing applications that use bedrock-mantle continue to be fully supported and do not need to change. Both endpoints let you bring an existing OpenAI SDK codebase to Amazon Bedrock by changing only the base URL and API key, and both support the OpenAI-compatible Responses and Chat Completions APIs and the Anthropic Messages API.

However, using the same inference engine does not mean that both endpoints offer the same functionality. The same page then presents a table, detailing endpoint-specific support for each area: API, inference capabilities, authentication and IAM, and Amazon Bedrock features. Sections 3 and 4 read this table row by row.

The handling of quotas also differs. The "Scaling and throughput best practices" page explains that, while both endpoints use the same inference engine, the method of counting quotas and the available capacity options differ. Amazon Bedrock Inference Throughput and Latency Optimization addresses this distinction.

3. Support by API

This section involves reviewing the "API Support" table on the "Endpoints supported by Amazon Bedrock" page, and then compiling notes regarding the Messages API and Responses API, referencing both that same page and the Responses API page.

3.1 API Support Table

The API support table shows support for five APIs. The presence or absence of support is represented by icons, so this article opened the page in a browser on September 28, 2026 and read the alternative text for the icons (supported and not-supported).

API	`bedrock-runtime`	`bedrock-mantle`
InvokeModel	Yes	No
Converse / ConverseStream	Yes	No
Chat Completions (OpenAI-compatible)	Yes	Yes
Responses API (OpenAI-compatible)	Yes	Yes
Messages API (Anthropic-native)	Yes	Yes

The InvokeModel and Converse APIs are only available with bedrock-runtime. The two OpenAI-compatible APIs and the Anthropic Messages API are available on both endpoints. However, as detailed in the following sections, the functionality available for a given API may vary depending on the endpoint.

A version of the same table, archived by the Internet Archive on June 1, 2026, indicated that the Responses API was not supported on bedrock-runtime. A version archived on August 17, 2026, shows that it is now supported.

3.2 Messages API Notes

The "Endpoints supported by Amazon Bedrock" page lists the following note regarding the Messages API:

The Messages API is available on both endpoints, but the two surfaces do not have identical feature support. In particular, structured outputs (the output_config.format parameter) are not supported on bedrock-mantle — requests that include output_config.format are rejected with a 400 error. To use structured outputs with Anthropic Claude models, call the Converse or InvokeModel APIs on bedrock-runtime.

The bedrock-mantle Messages API rejects requests containing the structured output parameter output_config.format with a 400 error. The output_config.format parameter is used in the Anthropic Messages API to specify the format of the response. The User Guide suggests using either the bedrock-runtime Converse API or the InvokeModel API for using structured output with Anthropic Claude models. This note does not specify whether the output_config.format parameter is supported by the bedrock-runtime Messages API. In addition, the model card for Claude Opus 4.7 lists structured outputs among the features not supported on the bedrock-runtime endpoint, without separating APIs; for that model, the card does not match the note's advice. Check the model card for the model you use.

The Messages API page also states that the method for specifying the API version varies depending on the endpoint. When calling InvokeModel with bedrock-runtime, you must include "anthropic_version": "bedrock-2023-05-31" in the request body. For bedrock-mantle, you must include the HTTP header anthropic-version: 2023-06-01. For the /anthropic route on bedrock-runtime, the same page states that the Anthropic SDK adds the required header automatically, and its curl example sends the same anthropic-version: 2023-06-01 header.

3.3 Responses API Notes

The Responses API is available on both endpoints, but offers different functionality. The following table outlines the differences for the bedrock-runtime Responses API, as described in the User Guide. The first four rows are taken from the "Endpoints supported by Amazon Bedrock" page, and the subsequent four rows are from the Responses API page.

Item	Handling in `bedrock-runtime` Responses API
Synchronous and Asynchronous	Requests are always processed synchronously. The `background=true` parameter will be rejected with a 400 error. The `store` parameter is unaffected and remains at its default value of `true`, allowing multi-turn conversations using stored responses to function as expected.
Tools	Server-side tools and pre-configured tools (including web search) are not supported. Client-side tools are available on both endpoints.
Project	Only the default project is supported.
Stored Responses	Stored responses belong to the AWS Region that processed them. Retrieval, cancellation, deletion, and continuation of conversations using `previous_response_id` are handled within that Region. The Responses API page adds that a request that uses a global inference profile can store data in any commercial Region that the profile routes to.
`model` Parameter	This parameter is required for every request, even when using `previous_response_id`. The Responses API page notes that this differs from both the OpenAI Responses API and `bedrock-mantle`.
Inference Target	Requests specifying an application inference profile will be rejected with a 400 error. System-defined geographical inference profiles and global inference profiles are supported as usual.
Guardrails	Not applicable to the Responses API. The Responses API page recommends using the Converse API to apply guardrails to GPT models.
Model Listing	The OpenAI-compatible `GET /models` operation is not supported in `bedrock-runtime`.

The Responses API on bedrock-runtime does not have Amazon Bedrock Guardrails applied. As shown in the table in section 4, Guardrails are listed as available features for bedrock-runtime. Viewed per API, the table and the Responses API page appear to conflict, so applications relying on Guardrails need to verify which API they call. The Responses API page clarifies this point as follows:

Guardrails don't apply to the Responses API. To apply a guardrail to a GPT model on this endpoint, call the Converse API instead.

The same page also states that the bedrock-runtime Responses API uses the same request and response format as bedrock-mantle. The differences lie in the base URL, model ID, permissions, and the behavior outlined in the table mentioned earlier. Regarding model IDs, the same page notes that when calling OpenAI's GPT models within bedrock-runtime, you must specify a cross-Region inference profile rather than the foundation model ID. To determine which models support the Responses API on each endpoint, the same page says to check the endpoint-specific API table on the model cards. It also notes that the table on the "API compatibility" page does not imply that an API is available on every endpoint.

4. Support by Capability

This section reviews the "Inference Capabilities" table and the "Bedrock Feature Availability" table on the "Endpoints supported by Amazon Bedrock" page, and looks at Projects, Workspaces, and the choice between endpoints that the User Guide describes. As in section 3.1, the icons in the tables were viewed in a browser on September 28, 2026.

4.1 Inference Capabilities

Capability	`bedrock-runtime`	`bedrock-mantle`
Cross-region inference (geographic and global profiles)	Yes	No
Stateful conversation management	Yes	Yes
Asynchronous (long-running) inference	No	Yes
Client-side tool use	Yes	Yes
Server-side tool use	No	Yes
Pre-configured ready-to-use tools	No	Yes
Projects	Default project only	Yes
Workspaces	No	Yes

Cross-Region inference is only available with bedrock-runtime. Asynchronous inference, server-side tools, pre-configured tools, and Workspaces are only available with bedrock-mantle. This article reads the asynchronous inference in this table as the long-running inference that bedrock-mantle offers, such as Responses API requests with background=true (section 4.4). bedrock-runtime has separate asynchronous operations, such as StartAsyncInvoke (section 8.1).

Projects are limited to the default project only with bedrock-runtime (see section 4.3). Both support stateful conversation management and client-side tool use.

According to versions archived by the Internet Archive on June 1, 2026, and August 4, 2026, stateful conversation management and Projects were not supported on bedrock-runtime. The contents of this table changed around the same time as the recommendation.

4.2 Amazon Bedrock Features

Feature	`bedrock-runtime`	`bedrock-mantle`
Guardrails	Yes	No
Prompt caching	Yes	Yes
Intelligent prompt routing	Yes	No

Amazon Bedrock Guardrails and intelligent prompt routing are only available with bedrock-runtime. However, as seen in section 3.3, Guardrails are not applied to the Responses API even when using bedrock-runtime. Regarding prompt caching, the same page includes the following note:

Prompt caching support on bedrock-mantle depends on the specific model — see each model card under Models at a glance for details.

4.3 Projects and Workspaces

Projects are logical boundaries that isolate workloads in the OpenAI-compatible APIs, and they are subject to access control through IAM and to tagging. Workspaces play the same role for the Anthropic-compatible Messages API. The Projects page notes the differences based on endpoints, as follows:

On the bedrock-mantle endpoint, you can create and manage your own projects with the Projects API. On the bedrock-runtime endpoint, only the default project is available — you can't create projects there yet.

Requests to bedrock-runtime are associated with the account's default project. Its ARN is in the format arn:aws:bedrock:{region}:{account-id}:project/default. The ARN for projects within bedrock-mantle begins with arn:aws:bedrock-mantle:. Judging from the Projects page's examples, the ARN for the default project also varies depending on the endpoint, with differences in the service component. This distinction matters for the Resource element of the project-level permissions in section 7.1.

The Workspaces page states that Workspaces can only be used with models compatible with the bedrock-mantle Messages API. Both the Projects and Workspaces pages recommend using inference profiles with bedrock-runtime for isolation and tagging if Projects or Workspaces are not required.

The Usage attribution row in the Operational table indicates the units by which usage can be tracked. For bedrock-runtime, this is the IAM principal, per-request metadata tags, and application inference profiles. For bedrock-mantle, it is Projects and Workspaces. A note on the same page clarifies that for the bedrock-runtime Responses API, usage can only be tracked by the IAM principal.

4.4 Choosing Between Endpoints (As Outlined in the User Guide)

The "When to choose each endpoint" section on the "Endpoints supported by Amazon Bedrock" page provides the following guidance on selecting the appropriate endpoint:

Endpoint Scenarios Mentioned in the User Guide

Start with bedrock-runtime Calling OpenAI-compatible Responses API and Chat Completions API, or Anthropic's Messages API. Using Amazon Bedrock's native InvokeModel API and Converse API. Utilizing Amazon Bedrock features that are only available with this endpoint, such as Guardrails and intelligent prompt routing. Routing requests across a geography or globally with cross-Region inference.

Use bedrock-mantle Building agent workflows that use server-side tools and pre-configured tools (including web search). Performing asynchronous or long-running inference, including requests with background=true for the Responses API. Creating Projects (OpenAI-compatible) and Workspaces (Anthropic-compatible) to segment workloads at the application level and track usage. Using models that are exclusively available with bedrock-mantle.

Endpoint	Scenarios Mentioned in the User Guide
Start with `bedrock-runtime`	Calling OpenAI-compatible Responses API and Chat Completions API, or Anthropic's Messages API. Using Amazon Bedrock's native InvokeModel API and Converse API. Utilizing Amazon Bedrock features that are only available with this endpoint, such as Guardrails and intelligent prompt routing. Routing requests across a geography or globally with cross-Region inference.
Use `bedrock-mantle`	Building agent workflows that use server-side tools and pre-configured tools (including web search). Performing asynchronous or long-running inference, including requests with `background=true` for the Responses API. Creating Projects (OpenAI-compatible) and Workspaces (Anthropic-compatible) to segment workloads at the application level and track usage. Using models that are exclusively available with `bedrock-mantle`.

The same section concludes with the following statement:

Both endpoints can be used together from the same application — choose per use case.

It is permissible for a single application to use both endpoints. For example, calls that require Guardrails can be directed to the bedrock-runtime Converse API, while calls that use server-side tools can be sent to the bedrock-mantle Responses API. However, in such cases, you will need to manage both sets of IAM actions (as described in section 7) and the two types of CloudTrail logs (as described in section 8).

5. Authentication — SigV4 and Bedrock API Keys

This section outlines the authentication methods accepted by the two endpoints, and details the two types of Bedrock API keys, including how to create them, revoke them, and identify operations they cannot be used for.

5.1 Three Authentication Methods

The Operational table on the "Endpoints supported by Amazon Bedrock" page indicates that both endpoints support AWS SigV4 authentication and Bedrock API keys. Bedrock API keys come in two types: short-term and long-term. The following table summarizes information from the User Guide's "API keys" page and the "How Amazon Bedrock API keys work" page.

Method	Created From	Valid Duration	Permissions	How the User Guide Positions It
AWS SigV4	AWS credentials of the IAM principal	Determined by credentials	Permissions of the IAM principal	Supported by both endpoints
Short-Term Bedrock API Key	IAM principal's session (console or token generator)	Shorter of 12 hours or the length of the IAM principal's session	Inherits permissions of the IAM principal that created the key	`Recommended for production use.` (API keys page)
Long-Term Bedrock API Key	Create an IAM user and generate the key as that user's service-specific credential	Until the configured expiration date	Policies attached to the IAM user	`Recommended only for exploration.` (API keys page)

Short-term keys can only be used in the same AWS Region in which they were created. The "How Amazon Bedrock API keys work" page highlights this limitation as a characteristic of short-term keys.

Long-term keys are recommended only for exploring Amazon Bedrock. The "How Amazon Bedrock API keys work" page includes the following warning:

We strongly recommend restricting the use of Amazon Bedrock API keys for exploration of Amazon Bedrock. When you're ready to incorporate Amazon Bedrock into applications with greater security requirements, you should switch to short-term credentials.

The AWS Security Blog post, "Securing Amazon Bedrock API keys: Best practices for implementation and management" (published October 17, 2025, with additions regarding bedrock-mantle on July 1, 2026), outlines the recommended order of authentication methods as follows:

AWS strongly recommends using AWS STS credentials as the primary authentication method wherever possible. If AWS STS credentials cannot be used, consider short-term API keys with their built-in expiration mechanism. Long-term API keys should only be implemented when neither AWS STS credentials nor short-term credentials are viable options.

The AWS Security Blog prioritizes AWS STS temporary credentials, short-term keys, and then long-term keys.

5.2 Access Is Not Granted by Authentication Alone

The "Endpoints supported by Amazon Bedrock" page, following the "Inference capabilities" table, states the following:

Authentication does not grant access by itself. Whether you use SigV4 or a Bedrock API key, the associated IAM principal must have permission for the required action.

Simply possessing a Bedrock API key does not allow you to call models. Whether you authenticate using SigV4 or with a Bedrock API key, the IAM principal associated with the request must have the necessary permissions for the required actions. The required actions differ by endpoint (see section 7.1).

Short-term keys inherit the permissions of the IAM principal that created the key. The AWS Security Blog notes this point with the following caution.

they inherit the permissions of the signing principal, which can be more than Amazon Bedrock permissions

On the other hand, the "Use an Amazon Bedrock API key" page describes the scope of operations that can be accessed with a Bedrock API key as follows:

Amazon Bedrock API keys are limited to Amazon Bedrock and Amazon Bedrock Runtime actions.

This sentence does not mention bedrock-mantle, which also accepts API keys (section 7.2). For long-term keys, the policy associated with the IAM user to which the key is linked determines the permissions. The AWS Security Blog notes that when a long-term key is created in the console, the IAM user is assigned the AmazonBedrockLimitedAccess AWS managed policy. It recommends replacing this with a more restrictive policy if the user has excessive permissions.

5.3 Creating and Revoking Short-Term Keys

Short-term keys can be created either through the Amazon Bedrock console or using the token generator provided by AWS. The API keys page states that keys created in the console expire when the console session ends, and at the longest, within 12 hours. The token generator is available as packages for the following three languages:

Python: aws-bedrock-token-generator
JavaScript: @aws/bedrock-token-generator
Java: aws-bedrock-token-generator within Maven's software.amazon.bedrock.

The API keys page recommends that for long-running applications, the token generator should be called with each request. The token generator will return a valid token if one exists; otherwise, it will create a new token. The generated key should then be placed in the environment variable AWS_BEARER_TOKEN_BEDROCK or included in the HTTP Authorization header as a Bearer token. With the OpenAI Python SDK, pass the key in api_key, or set OPENAI_API_KEY as in section 2.1.

Short-term keys cannot be revoked individually. The "Handle compromised long-term and short-term Amazon Bedrock API keys" page states:

You can't deactivate, reset, or delete an individual short-term Amazon Bedrock API key.

The same page explains the reason as follows:

A short-term key is a pre-signed URL that inherits the credentials and expiration of the session that generated it.

To disable a short-term key before its expiration date, you can either invalidate the session that created the key or apply a policy to the IAM principal that created the key, denying it access to Bedrock API keys (see section 7.2). The same page clarifies that both methods affect not only a single key but also the associated session or IAM principal.

These controls affect the generating session or identity, not only one short-term key.

Long-term keys can be deactivated, reset, or deleted using the IAM operations UpdateServiceSpecificCredential, ResetServiceSpecificCredential, and DeleteServiceSpecificCredential. The same page notes that when performing these operations via API, you must authenticate using AWS credentials rather than the Bedrock API key.

5.4 Operations That Cannot Be Performed with an API Key

The "Use an Amazon Bedrock API key" page lists the following three operations as those that cannot use a Bedrock API key:

InvokeModelWithBidirectionalStream
Operations for Agents for Amazon Bedrock and Agents for Amazon Bedrock Runtime.
Operations for Data Automation for Amazon Bedrock and Runtime for Amazon Bedrock Data Automation.

When using bidirectional streaming for voice applications, authentication will be performed using SigV4. Real-Time Voice AI Agent Architecture with Amazon Nova Sonic covers this configuration.

6. The Signal Table — What the Endpoint and the API Key Leave in IAM and CloudTrail

This article calls the clues that a call carries to AWS signals. This section presents a table outlining the signals related to endpoint selection and Bedrock API keys. This website also uses the same five-column table in other articles that address what calls carry to AWS (see section 3 of Agent Toolkit for AWS and the AWS MCP Server and section 4 of What Fills an AWS STS Session Token).

6.1 Reading the Table

The table has five columns:

Signal: This represents either a condition key within a policy, or an item from a CloudTrail log entry.
Who sets it: This indicates who assigns the signal, either AWS or the caller.
Where a policy can test it: This specifies where the signal can be checked within an IAM policy. If a signal cannot be checked within a policy, it will state so.
When it is absent: This describes the scenario when the signal is not present. This is only included when documented in AWS documentation.
Where AWS says so: This references the AWS documentation that serves as the basis for the information in that row.

For any cell where AWS documentation does not provide information, the entry will state The source does not say. Before adding such an entry, this article searched the full text of the sources the row cites and the pages those sources link to for the terms not, only, when applicable, absent, except, bearer, and SigV4.

6.2 Signals Related to the Inference Endpoints and Bedrock API Keys

Signal	Who sets it	Where a policy can test it	When it is absent	Where AWS says so
`bedrock:bearerTokenType` (value is `SHORT_TERM` or `LONG_TERM`)	AWS. This value is determined when the caller uses a Bedrock API key to call the Amazon Bedrock endpoint, and corresponds to the key type.	In IAM policies and SCPs, in the `Condition` for `bedrock:CallWithBearerToken` (using string operators like `StringEquals`).	The source does not say.	User Guide's API key permissions page, Service Authorization Reference, What's New (September 4, 2025), AWS Security Blog (October 17, 2025, updated July 1, 2026).
`bedrock-mantle:bearerTokenType` (value is `SHORT_TERM` or `LONG_TERM`)	AWS. This value is determined when the caller uses a Bedrock API key to call `bedrock-mantle`, and corresponds to the key type.	In IAM policies and SCPs, in the `Condition` for `bedrock-mantle:CallWithBearerToken` (using string operators).	The source does not say.	User Guide's API key permissions page, Service Authorization Reference, AWS Security Blog (October 17, 2025, updated July 1, 2026).
`iam:ServiceSpecificCredentialServiceName`	Caller. When creating a long-term key, this specifies the service name (e.g., `bedrock.amazonaws.com`) passed to `CreateServiceSpecificCredential`.	In the `Condition` for `iam:CreateServiceSpecificCredential` (using string operators like `StringEquals`).	Short-term keys. The User Guide states that the creation of short-term keys cannot be prevented.	User Guide's API key permissions page, What's New (September 4, 2025).
`iam:ServiceSpecificCredentialAgeDays`	Caller. When creating a long-term key, this specifies the number of days for the key's validity.	In the `Condition` for `iam:CreateServiceSpecificCredential` (using numeric operators like `NumericLessThanEquals`).	Short-term keys. The User Guide states that the creation of short-term keys cannot be prevented.	User Guide's API key permissions page, What's New (September 4, 2025).
CloudTrail `bedrock-runtime` inference events (where `eventSource` is `bedrock.amazonaws.com`)	AWS. AWS records these inference operations as management events. The User Guide lists `InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, and `ConverseStream`.	Not a policy condition key. It is a field for searching records.	The User Guide states that management events are recorded in the CloudTrail Event history by default. It does not specify the event names for calls to `/openai/v1` and `/anthropic` paths.	User Guide's "Monitor Amazon Bedrock API calls using CloudTrail" page and "Monitor bedrock-mantle API calls using CloudTrail" page.
CloudTrail `bedrock-mantle` inference events (where `eventName` is `CreateInference` or another inference operation, and `eventSource` is `bedrock-mantle.amazonaws.com`)	AWS. AWS records these inference operations as data events.	Not a policy condition key.	When data event recording is not configured on the trail or event data store. The User Guide states that data events are not recorded by default.	User Guide's "Monitor bedrock-mantle API calls using CloudTrail" page.
CloudTrail `additionalEventData.callWithBearerToken` (for events from `bedrock.amazonaws.com`)	AWS. This field is set to `true` when using a Bedrock API key.	Not a policy condition key.	The source does not say.	AWS Security Blog (October 17, 2025, updated July 1, 2026), and the sample CloudFormation template that the post links to.
CloudTrail `requestParameters.callWithBearerToken` and `requestParameters.bearerTokenType` (for events from `bedrock-mantle.amazonaws.com`)	AWS. The User Guide states, in its management events section, that the service adds these to every event. They are also included in the example of data event recording.	Not a policy condition key.	Regarding `bearerTokenType`, the User Guide states that it is attached when applicable, but does not specify the circumstances.	User Guide's "Monitor bedrock-mantle API calls using CloudTrail" page.
CloudTrail `CreateServiceSpecificCredential` events (where `requestParameters.serviceName` is `bedrock.amazonaws.com`)	AWS. AWS records the creation of long-term keys. When created through the console, it also records the creation of an IAM user (`CreateUser` event).	Not a policy condition key.	Short-term keys. The AWS Security Blog states that because short-term keys are created on the client-side, their creation is not recorded in CloudTrail.	AWS Security Blog (October 17, 2025, updated July 1, 2026).

The reason the fourth column in the first and second rows indicates The source does not say. is because the User Guide describes how to combine each condition key with a specific action, but it does not explain how these condition keys are handled in requests authenticated with SigV4. The reason the fourth column in the seventh row indicates The source does not say. is because the only sources on this item are the AWS Security Blog and the sample CloudFormation template that the post links to, and both discuss only calls using Bedrock API keys. Regarding the fifth row, the page titled "Monitor bedrock-mantle API calls using CloudTrail" refers to inference on bedrock-runtime as a management event. However, the CloudTrail page for bedrock-runtime only lists four inference operations as management events, in the InvokeModel and Converse families. Neither page specifies the event names used to record calls to the paths of the OpenAI-compatible APIs and the Messages API.

6.3 What Can Be Gleaned from the Table

The top four rows list signals that can be tested in IAM policies. The bottom five rows list signals that are recorded in CloudTrail but cannot be tested in policies.

The condition keys and actions related to Bedrock API keys have different names for each endpoint. Those that begin with bedrock: refer to the Amazon Bedrock endpoint side, while those that begin with bedrock-mantle: refer to the bedrock-mantle side. A policy that only specifies one of these will not apply to calls passing through the other endpoint (see section 7.2).

The CloudTrail entries indicating the use of Bedrock API keys also have different locations depending on the endpoint. For events from the Amazon Bedrock endpoint, this information is found under additionalEventData; for bedrock-mantle events, it is located under requestParameters. The AWS Security Blog documents the former, while the User Guide describes the latter.

Short-term keys cannot be caught at creation, either by IAM or CloudTrail. The condition keys used to prevent creation apply only to long-term keys, and only the creation of long-term keys is recorded. Control over short-term keys must be implemented during their usage, by denying the two actions described in section 7.2 or by invalidating the session that created the key (section 5.3).

7. IAM — Which Action Each Call Checks

This section details the actions IAM checks, including those that allow inference on the two endpoints, those that stop the use of Bedrock API keys, and those that control key creation. Figure 2 illustrates the actions IAM checks and the types of CloudTrail logs generated, based on the combination of endpoints and authentication methods.

7.1 Inference Actions

The Operational table on the "Endpoints supported by Amazon Bedrock" page details the IAM permissions required for inference, per endpoint:

Endpoint	IAM Authorization for Inference
`bedrock-runtime`	`bedrock:InvokeModel` on the inference target. For the Responses API, `bedrock:InvokeModel` is also required for the default project. For streaming, `bedrock:InvokeModelWithResponseStream` is required.
`bedrock-mantle`	`bedrock-mantle:CreateInference`

Even when calling the same model, different endpoints require different IAM actions to be authorized. A policy that only allows bedrock:InvokeModel will not permit inference using bedrock-mantle. Conversely, even if bedrock:InvokeModel is denied, inference using bedrock-mantle will not be stopped.

The "Prerequisites for running model inference" page provides more details about bedrock-runtime.

bedrock:InvokeModel allows the InvokeModel and Converse operations.
bedrock:InvokeModelWithResponseStream allows the InvokeModelWithResponseStream and ConverseStream operations.
To handle responses stored by the Responses API with bedrock-runtime, you need bedrock:GetInvoke to retrieve them, bedrock:CancelInvoke to cancel ongoing responses, and bedrock:DeleteInvoke to delete them. All three apply to the project that the response belongs to, not the model itself.
To create responses, in addition to the inference target, you also need bedrock:InvokeModel for the project. The Converse, Invoke, and Chat Completions APIs do not store responses, so bedrock:GetInvoke, bedrock:CancelInvoke, and bedrock:DeleteInvoke are not required.

The Responses API page also states that authorization for the inference target carries the condition key bedrock:ProjectArn, while authorization for the project itself carries the condition key bedrock:ModelArn. With these keys, a policy on either resource can constrain the other.

Information regarding bedrock-mantle can be found on the "Amazon Bedrock Powered by AWS Mantle" page of the Service Authorization Reference. The resource type for bedrock-mantle:CreateInference is a project, and its condition keys include bedrock-mantle:Model and bedrock-mantle:ServiceTier. The "Endpoints supported by Amazon Bedrock" page directs users to the "Prerequisites for running model inference" page for complete policy requirements; however, as of September 28, 2026, that page does not list any bedrock-mantle actions. You can verify the bedrock-mantle actions in the Service Authorization Reference and on the "IAM policies for Amazon Bedrock Projects" page.

7.2 Stopping API Key Usage: Two Actions

Bedrock API key usage is checked through separate actions, distinct from inference actions. The "Control permissions for generating and using Amazon Bedrock API keys" page states:

Amazon Bedrock API keys can be used with two endpoints, each controlled by a separate IAM action. To fully prevent all API key-based access, you must deny both actions.

The two actions are as follows:

bedrock:CallWithBearerToken controls the use of API keys through the Amazon Bedrock endpoint.
bedrock-mantle:CallWithBearerToken controls the use of API keys through the Amazon Bedrock Mantle endpoint.

To completely disable Bedrock API key usage, you must deny both actions. The "Handle compromised long-term and short-term Amazon Bedrock API keys" page explains the consequences of denying only one of these actions:

Denying only bedrock:CallWithBearerToken does not prevent API key usage through the Mantle endpoint. You must also deny bedrock-mantle:CallWithBearerToken to completely block API key usage.

The policy shown on the same page is as follows:

{
  "Version":"2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": [
      "bedrock:CallWithBearerToken",
      "bedrock-mantle:CallWithBearerToken"
    ],
    "Resource": "*"
  }
}

The location where this policy should be applied depends on the type of key. For long-term keys, apply it to the IAM user associated with the key. For short-term keys, apply it to the IAM principal that created the key.

The Amazon Bedrock page in the Service Authorization Reference lists bedrock:CallWithBearerToken as a required action not only for inference operations, but also for operations such as model customization. Denying bedrock:CallWithBearerToken will block all operations that use API keys through the Amazon Bedrock endpoint.

7.3 Differentiating Key Types with bearerTokenType

Each of the two actions has its own bearerTokenType condition key. bedrock:bearerTokenType is used with bedrock:CallWithBearerToken, and bedrock-mantle:bearerTokenType is used with bedrock-mantle:CallWithBearerToken. The values are SHORT_TERM, representing short-term keys, and LONG_TERM, representing long-term keys.

The API key permissions page provides an example of how to disable short-term key usage, using the following policy:

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "bedrock:CallWithBearerToken",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "bedrock:bearerTokenType": "SHORT_TERM"
                }
            }
        },
        {
            "Effect": "Deny",
            "Action": "bedrock-mantle:CallWithBearerToken",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "bedrock-mantle:bearerTokenType": "SHORT_TERM"
                }
            }
        }
    ]
}

The User Guide's examples demonstrate that when disabling keys based on type, a separate statement is written for each endpoint. The same page also provides examples of how to deny LONG_TERM keys, as well as examples of denying one key type while allowing the two actions.

The naming convention for the condition key varies across different documentation. The User Guide uses bedrock:bearerTokenType, while the Service Authorization Reference and the What's New post of September 4, 2025 use bedrock:BearerTokenType. The IAM User Guide, specifically the "IAM JSON policy elements: Condition" page, describes the naming of the condition key as follows:

Context key names are not case-sensitive.

7.4 Controlling Key Creation

The IAM iam:CreateServiceSpecificCredential action controls long-term key creation. The API key permissions page describes how to restrict this action to specific IAM users and lists the condition keys iam:ServiceSpecificCredentialAgeDays (number of days until expiration) and iam:ServiceSpecificCredentialServiceName (service name). The same page provides an example for Amazon Bedrock, demonstrating how to allow the creation of only long-term keys with an expiration period of 90 days or less.

{
   "Version":"2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Action": "iam:CreateServiceSpecificCredential",
           "Resource": "arn:aws:iam::123456789012:user/username",
           "Condition": {
               "StringEquals": {
                   "iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com"
               },
               "NumericLessThanEquals": {
                   "iam:ServiceSpecificCredentialAgeDays": "90"
               }
           }
       }
   ]
}

Short-term key creation cannot be prevented. The API key permissions page outlines methods for stopping key creation and usage, indicating N/A for the section on preventing short-term key creation. A warning in the policy examples on the same page states:

You can't prevent the generation of short-term keys.

The same warning also clarifies that the policy it accompanies on that page, which denies the iam:CreateServiceSpecificCredential action, prevents the creation of service-specific credentials not only for Amazon Bedrock, but also for all other AWS services that support the creation of such credentials. To limit the restriction to Amazon Bedrock, specify the service using the condition key iam:ServiceSpecificCredentialServiceName. An SCP example in the AWS Machine Learning Blog's "Accelerate AI development with Amazon Bedrock API keys" also uses this condition key, specifying bedrock.amazonaws.com to deny the iam:CreateServiceSpecificCredential action for keys valid for 30 days or more.

The AWS Security Blog suggests that organizations that do not need Bedrock API keys consider denying key creation and usage through SCPs. In such cases, the relevant actions are three: iam:CreateServiceSpecificCredential, bedrock:CallWithBearerToken, and bedrock-mantle:CallWithBearerToken.

7.5 Differences in Deny Examples for Each Document

IAM policies that prevent the use of Bedrock API keys vary depending on the document, with different actions being denied.

Document	Date	Actions Denied
User Guide – API key permissions page and revocation page	Verified on September 28, 2026	`bedrock:CallWithBearerToken` and `bedrock-mantle:CallWithBearerToken`
AWS Security Blog – Securing Amazon Bedrock API keys	Published on October 17, 2025, updated on July 1, 2026	`bedrock:CallWithBearerToken` and `bedrock-mantle:CallWithBearerToken`
AWS Machine Learning Blog – Accelerate AI development with Amazon Bedrock API keys	Published on July 8, 2025	`bedrock:CallWithBearerToken` only
Anthropic – Claude in Amazon Bedrock page	Verified on September 28, 2026	`bedrock:CallWithBearerToken` only (denies all keys except for short-term keys using `bedrock:BearerTokenType`)
User Guide – API key permissions page – warning	Verified on September 28, 2026	States that short-term keys can be prevented from use by denying `bedrock:CallWithBearerToken`.

The AWS Machine Learning Blog article was written before the bedrock-mantle endpoint was available (prior to December 2025). Anthropic's Claude in Amazon Bedrock page describes the bedrock-mantle endpoint (section 1.3). That page describes how to prevent the use of long-term keys as follows:

Block long-term keys by attaching a policy that denies bedrock:CallWithBearerToken unless the bedrock:BearerTokenType condition matches a short-term token.

The API key permissions page of the User Guide shows the denial of two actions in the table on the same page, but in the warning section following the table, it only mentions bedrock:CallWithBearerToken.

Because a short-term Amazon Bedrock API key uses existing credentials from a session, you can prevent its usage by denying the bedrock:CallWithBearerToken action on the identity that generated the key. However, you can't prevent generation of a short-term key.

This article follows two passages from the User Guide, as referenced in section 7.2, regarding IAM actions. Those two passages clearly state that both actions must be denied and that denying only bedrock:CallWithBearerToken will not prevent usage through bedrock-mantle. If a policy was created based on an example that denies only one of the actions, it will be necessary to add a Deny for bedrock-mantle:CallWithBearerToken.

8. CloudTrail — What Is Recorded, and as Which Kind of Event

This section will examine how inference on the two endpoints is recorded in CloudTrail, covering the settings for data events, the recording of Bedrock API key usage and key creation, and the impact on existing detection rules. This section does not cover general information about CloudTrail's management events and data events.

8.1 Management Events and Data Events

The "Monitor bedrock-mantle API calls using CloudTrail" page in the User Guide describes the first difference between the two endpoints as follows:

Inference is a data event on bedrock-mantle, a management event on bedrock-runtime.

According to that page, inference on bedrock-runtime is logged as a management event, while inference on bedrock-mantle is logged as a data event. Management events are logged to the CloudTrail Event history by default. Data events are not logged by default. The same page notes that if you require audit trails for inference on bedrock-mantle, you must explicitly configure data event logging on a trail or an event data store.

Regarding bedrock-runtime, the "Monitor Amazon Bedrock API calls using CloudTrail" page states that InvokeModel, InvokeModelWithResponseStream, Converse, and ConverseStream are logged as management events. In the logging examples provided on the same page, the eventSource is bedrock.amazonaws.com, and the tlsDetails.clientProvidedHostHeader includes bedrock-runtime.us-west-2.amazonaws.com. However, the same page also indicates that other bedrock-runtime operations, such as InvokeModelWithBidirectionalStream, GetAsyncInvoke, and StartAsyncInvoke, are logged as data events. Not all calls to bedrock-runtime are recorded as management events. Furthermore, the same page does not specify which event names are used to record calls to the /openai/v1 and /anthropic paths (see section 6.2).

For bedrock-mantle, all events have an eventSource of bedrock-mantle.amazonaws.com. The User Guide differentiates between management and data events as follows:

Type	Event Name
Management Events	Listing and getting models (`ListModels`, `GetModel`), fine-tuning jobs (`ListFineTuningJobs`, `CreateFineTuningJob`, `GetFineTuningJob`, `CancelFineTuningJob`), projects (`ListProjects`, `CreateProject`, `GetProject`, `UpdateProject`, `ArchiveProject`)
Data Events	Inference (`CreateInference`, `GetInference`, `CancelInference`, `DeleteInference`, `CountTokens`), files (`ListFiles`, `CreateFile`, `GetFile`, `DeleteFile`)

POST requests to the following routes share the CreateInference event name: /v1/responses, /v1/responses/compact, /v1/chat/completions, /v1/embeddings, and /anthropic/v1/messages. Which API was called cannot be determined from the event name alone. The User Guide lists the additional request parameters recorded for each route, but it does not name a field that records the route itself. The /openai/v1 route that some model cards give as the base URL for bedrock-mantle is also not among the routes that the User Guide lists (section 2.1).

8.2 Configuring Data Event Logging

The User Guide provides an example AWS CLI command for configuring the logging of bedrock-mantle inference and file data events.

aws cloudtrail put-event-selectors \
    --trail-name <trailName> \
    --advanced-event-selectors '[
      {
        "Name": "Log Bedrock Mantle inference and file events",
        "FieldSelectors": [
          { "Field": "eventCategory", "Equals": ["Data"] },
          { "Field": "resources.type", "Equals": [
            "AWS::BedrockMantle::Project",
            "AWS::BedrockMantle::CustomizedModel",
            "AWS::BedrockMantle::Reservation"
          ]}
        ]
      }
    ]'

The put-event-selectors command is used to reconfigure the event selectors for a trail. The AWS CloudTrail API Reference, on the PutEventSelectors page, states:

If you apply AdvancedEventSelectors to a trail, any existing EventSelectors are overwritten.

The same page also notes that a trail will not record events that do not match any of its configured selectors.

If the event doesn't match any event selector, the trail doesn't log the event.

The selectors in the example above are designed to match only bedrock-mantle data events. If you apply this command directly to an existing trail that is currently logging management events, that trail may stop recording those management events. When adding selectors to an existing trail, ensure you include all existing selectors you wish to retain in the same command.

The User Guide mentions that you can also filter by eventName and resources.ARN, and lists six resource types associated with bedrock-mantle events: AWS::BedrockMantle::Project, AWS::BedrockMantle::Reservation, AWS::BedrockMantle::CustomizedModel, AWS::BedrockMantle::Environment, AWS::BedrockMantle::Runtime, and AWS::BedrockMantle::Skill.

Regarding considerations when logging data events, the "Monitor bedrock-mantle API calls using CloudTrail" page states:

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.

8.3 Tracking API Key Usage

The "API keys" page of the User Guide states:

All API calls are logged in AWS CloudTrail. API keys are passed as authorization headers and are not logged.

CloudTrail records only the fact that an API key was used, not the key itself. The field where that fact is recorded varies depending on the endpoint (see section 6.3).

Regarding events for the Amazon Bedrock endpoint, the AWS Security Blog lists two indicators that signify API key usage:

additionalEventData.callWithBearerToken = true
eventSource = bedrock.amazonaws.com

For bedrock-mantle events, the User Guide's "Monitor bedrock-mantle API calls using CloudTrail" page states the following in its management events section:

The requestParameters field of each event also contains callWithBearerToken (and bearerTokenType when applicable), which are added by the service for every event.

Even in the example of data event (CreateInference) logging, requestParameters includes callWithBearerToken. The AWS Security Blog also provides an example of an Amazon EventBridge rule that indicates API key usage. This rule does not specify an eventSource, and it matches events where the additionalEventData field has a value of true for callWithBearerToken. In contrast, the rule in the sample CloudFormation template that the same post links to matches callWithBearerToken under both additionalEventData and requestParameters. According to the User Guide, for bedrock-mantle events, this field is located under requestParameters. When searching for or creating rules to detect API key usage, you should check additionalEventData for events from bedrock.amazonaws.com and requestParameters for events from bedrock-mantle.amazonaws.com. Furthermore, because bedrock-mantle inference is a data event, if data events are not being logged, there will be no record of inference made using an API key.

8.4 Key Creation Logging

Long-term key creation is logged as an IAM CreateServiceSpecificCredential event. The AWS Security Blog recommends tracking events where requestParameters.serviceName is bedrock.amazonaws.com, and notes that when a long-term key is created through the console, a CreateUser event within IAM is also logged.

Short-term key creation is not logged. As stated in the AWS Security Blog:

Short-term API keys are generated locally on the client side, therefore their creation of these short-term keys won’t be recorded in CloudTrail

CloudTrail only tracks the usage of short-term keys, not their creation.

8.5 Existing Detection Rules Do Not Capture bedrock-mantle

The "Monitor bedrock-mantle API calls using CloudTrail" page describes the second difference between the two endpoints as follows:

Different event source and resource types. bedrock-mantle events use an eventSource of bedrock-mantle.amazonaws.com and reference AWS::BedrockMantle::* resource types. CloudTrail Lake queries, Athena views, and detective controls that filter on bedrock.amazonaws.com or bedrock-runtime.amazonaws.com will not capture bedrock-mantle activity.

Detection rules and searches that filter by eventSource as bedrock.amazonaws.com will not capture activity on bedrock-mantle. In environments with applications that use both endpoints, or in environments with applications that use bedrock-mantle following the recommendation from before August 15, 2026, it is necessary to verify that the detection rules include bedrock-mantle.amazonaws.com. Furthermore, because inference on bedrock-mantle is a data event, even if rules are updated, if data events are not being logged, no relevant events will be detected (see section 8.1).

Threat Detection for AI Workloads on AWS details what Amazon GuardDuty detects from Amazon Bedrock activity.

9. What to Do with Existing Applications

This section outlines what the User Guide says about existing applications that currently use bedrock-mantle, and lists the items that change along with the endpoint when an application moves.

9.1 Items That Do Not Need to Be Changed

The "Endpoints supported by Amazon Bedrock" page states the following regarding existing applications (section 2.2).

Existing applications that use bedrock-mantle continue to be fully supported and do not need to change.

Existing applications that use bedrock-mantle do not need to be migrated due to a change in recommendations. The Document history in the User Guide also states the same, explaining the change made on August 15, 2026.

The bedrock-mantle endpoint continues to be fully supported and existing applications that use it do not need to change.

However, this article reads this statement to mean that you do not need to change your application's code or endpoint selection. As shown in section 8, the inference performed by bedrock-mantle is recorded as a data event, and the eventSource is different. It is necessary to independently verify that, even though your application does not need to be changed, your control and monitoring configurations cover bedrock-mantle. Policies that deny only one action (as described in section 7.5) or detection rules that only monitor bedrock.amazonaws.com (as described in section 8.5) will leave gaps as long as your application continues to use bedrock-mantle.

9.2 Items That Change When Moving Endpoints

When migrating from bedrock-mantle to bedrock-runtime, changes occur not only to the URL but also to IAM actions, API key usage actions, and CloudTrail logging. The following table lists the items that change along with the endpoint, based on the User Guide.

Item	`bedrock-mantle`	`bedrock-runtime`
Base URL for OpenAI-compatible APIs	`https://bedrock-mantle.{region}.api.aws/v1` (for some models, the model card shows `/openai/v1`)	`https://bedrock-runtime.{region}.amazonaws.com/openai/v1`
IAM actions for inference	`bedrock-mantle:CreateInference`	`bedrock:InvokeModel`, `bedrock:InvokeModelWithResponseStream` (for the Responses API, also on the default project)
IAM actions for API key usage	`bedrock-mantle:CallWithBearerToken`	`bedrock:CallWithBearerToken`
CloudTrail logging for inference	Data events. `eventSource` is `bedrock-mantle.amazonaws.com`.	Management events. `eventSource` is `bedrock.amazonaws.com`. The event names for calls to the paths for the OpenAI-compatible APIs and the Messages API are not documented on the User Guide's CloudTrail pages.
Projects	Creation and management are supported.	Only the default project. Inference profiles are used for isolation and tagging.
Asynchronous inference and server-side tools for the Responses API	Supported.	Not supported.
Guardrails	Not supported.	Supported, but not applicable to the Responses API.
Cross-Region inference	Not supported.	Supported.

When migrating, you must update your IAM policies, SCPs, and detection rules to align with the new endpoint's actions and events. For example, a role that only permits bedrock-mantle:CreateInference will not allow inference with bedrock-runtime.

The User Guide's CloudTrail pages do not specify which event names are used to log API calls to the paths for the OpenAI-compatible APIs and the Messages API within bedrock-runtime. If you intend to use these logs for auditing, you will need to verify which event names are recorded in the migrated logs. The method for specifying model IDs may also change. For OpenAI's GPT models, you need to specify a cross-Region inference profile when using the Responses API within bedrock-runtime (see section 3.3). The way quotas are counted also changes, a topic covered in Amazon Bedrock Inference Throughput and Latency Optimization.

Conversely, when applications using bedrock-runtime begin using bedrock-mantle for asynchronous (long-running) inference or server-side tools, you need to read the same table from right to left. Specifically, you will need to manage bedrock-mantle:CreateInference and bedrock-mantle:CallWithBearerToken within your policies. If you use Web Search, the User Guide also lists separate actions with the bedrock-websearch prefix. If you require inference logging, ensure that data event logging is also configured.

10. Frequently Asked Questions about Amazon Bedrock Inference Endpoints and API Keys

This section summarizes the content presented earlier in the form of questions and answers. The basis for each answer can be found in the corresponding sections (indicated in parentheses).

Q1. To which endpoint should a new application be directed?

The User Guide, as of September 28, 2026, recommends bedrock-runtime for most new applications. bedrock-mantle should be used when you need features only available in bedrock-mantle, such as server-side tools, asynchronous (long-running) inference, Projects, and Workspaces, or when you require models that are exclusively provided through bedrock-mantle (see sections 1.1 and 4.4).

Q2. Do existing applications that currently use bedrock-mantle need to be migrated to bedrock-runtime?

No, they do not. The User Guide states that existing applications using bedrock-mantle will continue to be fully supported and do not need to be changed. However, it is necessary to verify whether your IAM policies and detection rules cover the actions and events of bedrock-mantle (see section 9.1).

Q3. If you deny bedrock:CallWithBearerToken, do Bedrock API keys stop working?

Usage through bedrock-mantle will not be stopped. The User Guide states that denying bedrock:CallWithBearerToken alone does not prevent API key usage through the Mantle endpoint. To completely disable your Bedrock API key, you must also deny bedrock-mantle:CallWithBearerToken (see sections 7.2 and 7.5).

Q4. If you have a Bedrock API key, can you call the models even without IAM permissions?

You cannot. The User Guide states that access is not granted through authentication alone; whether using SigV4 or a Bedrock API key, an IAM principal with the necessary permissions for specific actions is required. These actions include bedrock:InvokeModel for bedrock-runtime and bedrock-mantle:CreateInference for bedrock-mantle (see sections 5.2 and 7.1).

Q5. Can the creation of short-term Bedrock API keys be stopped?

No, it cannot. The User Guide states that the creation of short-term keys cannot be stopped. Short-term keys are stopped at the point of use, by attaching Denies for the two CallWithBearerToken actions to the IAM principal that created them or by invalidating the session that created them. The creation itself is not recorded in CloudTrail (see sections 5.3, 7.4, and 8.4).

Q6. Does inference on bedrock-mantle get recorded with CloudTrail's default settings?

No, it does not. Inference within bedrock-mantle is recorded as a data event, and data events are not recorded by default. If you need to record inference, you must configure data event recording on a trail or an event data store. When adding settings to an existing trail, be sure not to delete any existing selectors (see sections 8.1 and 8.2).

Q7. Since both endpoints use the same inference engine, can the same capabilities be used on both?

The functionality available differs. While the User Guide states that both endpoints use the same Mantle inference engine, it clearly delineates endpoint-specific support for each aspect – API, inference capabilities, and Amazon Bedrock features. For example, Guardrails are only supported by the bedrock-runtime endpoint, while the asynchronous (long-running) inference in the endpoint table is available only through the bedrock-mantle endpoint (see sections 2.2, 3, and 4).

Q8. Is it acceptable to change only the base URL while keeping the OpenAI API key configured in the OpenAI SDK?

No. The User Guide specifies that both the OpenAI API key and the OpenAI base URL are directly connected to OpenAI and should not be used. Configure OPENAI_API_KEY with your Bedrock API key and set the OPENAI_BASE_URL to the Amazon Bedrock endpoint. For bedrock-runtime, the path is /openai/v1. For bedrock-mantle, verify the base URL using the model card for the model you are using (see section 2.1).

11. Summary

The User Guide, as of September 28, 2026, recommends bedrock-runtime for most new applications. bedrock-mantle should be used when specific features or models are required that are only available through that endpoint. The User Guide's Document history indicates that this recommendation changed on August 15, 2026. Prior versions of the User Guide recommended bedrock-mantle (sections 1.1 and 1.2).
The two endpoints use the same Mantle inference engine, but offer different APIs and functionalities. InvokeModel, Converse, cross-Region inference, and Guardrails are exclusively available through bedrock-runtime, while asynchronous (long-running) inference in the endpoint table's sense, server-side tools, and Workspaces are only accessible through bedrock-mantle (sections 2 through 4).
The bedrock-runtime Responses API has specific limitations. It operates synchronously, only supports the default project, and does not apply Guardrails (section 3.3).
Simply possessing a Bedrock API key is not sufficient to call models. The associated IAM principal must have the necessary permissions to perform inference actions for each endpoint (sections 5.2 and 7.1).
The inference actions are bedrock:InvokeModel and related actions for bedrock-runtime, and bedrock-mantle:CreateInference for bedrock-mantle. Permissions or denials for one endpoint's inference action do not apply to inference on the other endpoint (section 7.1).
To completely disable Bedrock API key usage, you must deny both bedrock:CallWithBearerToken and bedrock-mantle:CallWithBearerToken. Examples of denying only one of these are found in other documentation (sections 7.2 and 7.5).
The creation of short-term Bedrock API keys cannot be prevented, and it cannot be tracked in CloudTrail. Control is implemented at the point of usage (sections 7.4 and 8.4).
Inference performed through bedrock-mantle is a data event and is not logged by default. The eventSource is bedrock-mantle.amazonaws.com, so detection rules that filter for bedrock.amazonaws.com will not capture these events. When adding data event logging, ensure you do not overwrite existing selectors (sections 8.1, 8.2, and 8.5).
Existing applications using bedrock-mantle do not require modification. However, it is necessary to independently verify whether the IAM policies and detection rules cover bedrock-mantle (section 9.1).

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi