Amazon Bedrock AgentCore Identity is the credential layer for AI agents built on AgentCore. It gives each agent a workload identity, controls who may call the agent through an inbound authorizer, and keeps the OAuth tokens and API keys the agent uses for outside tools in a token vault.
That solves a real problem: it takes third-party secrets out of agent code. It also adds new objects to your AWS account, and those need to be inventoried, reviewed and logged like any other identity. This guide is written for the security reviewer rather than the builder. It covers what AgentCore Identity manages, how many identities one agent really has, and what to check.
The three things AgentCore Identity manages
AWS’s AgentCore Identity developer guide is the authority on configuration. The summary below uses its terms, as documented in September 2026.
Workload identity
In AgentCore, an agent identity is implemented as a workload identity with agent-specific attributes. AWS’s terminology page describes a workload identity as a logical application or workload, independent of the infrastructure it runs on. Agent identities live in an agent identity directory, which AWS compares to a Cognito user pool: a registry and a unit of governance within an account and region.
The workload identity is not the same thing as the agent’s IAM execution role. The execution role decides what AWS APIs the agent can call. The workload identity is what AgentCore uses to decide which credentials in the token vault the agent may retrieve, and on whose behalf.
Inbound authorizer
The inbound side decides who may invoke the agent. AgentCore supports AWS IAM (SigV4) callers and a JWT authorizer that accepts tokens from an OAuth or OpenID Connect identity provider you configure. For a security review, the questions are which issuer is trusted, and whether the authorizer checks the audience and client so that a token issued for another application is not accepted.
Outbound credential providers and the token vault
The outbound side is where AgentCore Identity does most of its work. A resource credential provider manages the connection to an outside service: it holds the OAuth client configuration or API key and handles the OAuth flow. The token vault stores the resulting OAuth tokens and API keys. AWS states that vault credentials can only be accessed by the specific agent and user combination that originally obtained them.
When AgentCore Runtime invokes an agent it hosts, it supplies a workload access token that carries both the agent’s identity and the end user’s. The agent presents that token to retrieve the user’s credential for, say, a calendar or code-hosting API. Agents hosted elsewhere retrieve the token through the AgentCore SDK.
The security benefit is real. An agent that uses the vault never has a long-lived third-party secret in its code or environment, and one user’s tokens cannot be used for another user’s request.
How many identities does one Bedrock agent actually have?
This is the question most AgentCore content skips, and it is the first one a security reviewer should answer. What the business calls “one agent” is several identities in IAM and AgentCore.
| Identity | Where it comes from | What it can do | Applies to |
| Bedrock Agents service role | An IAM role whose trust policy names bedrock.amazonaws.com | Invoke the chosen model and act for the agent | Agents built with Bedrock Agents |
| Action-group Lambda execution role | One IAM role per Lambda function behind an action group | Whatever the function’s code touches: S3, DynamoDB, internal APIs | Agents built with Bedrock Agents |
| AgentCore Runtime execution role | The IAM role the hosted agent runs as | Every AWS API call the agent’s code makes | Agents hosted on AgentCore Runtime |
| AgentCore workload identity | The agent identity directory in AgentCore Identity | Retrieve its own credentials from the token vault | Agents using AgentCore Identity |
| Credential providers and vault entries | OAuth clients and API keys configured for outside tools | Act in third-party systems, often for many users | Agents using AgentCore Identity |
| Tool execution roles | Roles for AgentCore Gateway targets, custom Code Interpreters and custom browsers | Whatever those tools are allowed to do | Agents using those tools |
| Bedrock API key | A short-term key, or a long-term key backed by an IAM user AWS creates | Invoke models with the caller’s or the user’s permissions | Often left from pilots |
Not every agent has every row. A Bedrock Agents agent typically has a service role and one execution role per action group. An agent hosted on AgentCore Runtime has an execution role and a workload identity, plus a credential provider for each outside service. But in both cases the count is three or more.
The last-but-one row deserves attention. Security researchers at Sonrai documented in 2025 that a custom Code Interpreter runs with its own execution role, and that an identity allowed to start and invoke that interpreter can direct it to act with that role’s permissions. A tool’s execution role is part of the agent’s blast radius, and part of the inventory.
An inventory that lists “one agent” is therefore wrong by a factor of three or four. Worse, the identity with the widest access is often not the one with “agent” in its name. It is usually an action-group Lambda role or a tool role that was granted broad access so the demo would work.
Bedrock API keys, and why pilots end up with the risky kind
Agents are often prototyped before anyone sets up AgentCore Identity, and prototypes commonly use Bedrock API keys.
Short-term keys last up to 12 hours or the length of the session that generated them, whichever is shorter. They inherit the permissions of the principal that created them and work only in one region. Long-term keys are different: AWS creates an IAM user behind the scenes, attaches the policies you select and associates the key with that user, which lasts until the expiry you set. AWS recommends long-term keys only for exploring Bedrock.
The pattern is easy to predict. Exploration credentials are the ones that reach production, because nothing forces them out. A pilot built with a long-term key becomes a demo, then a service, and the key and its IAM user remain. Check for them with ListServiceSpecificCredentials on your IAM users. If one leaks, it can be used to run models at your expense. Our guide to LLMjacking covers what that looks like in the logs.
How AgentCore Identity compares to Azure and GCP
Each major cloud now has a purpose-built identity for agents. They differ most in where credentials live.
| AWS | Azure | GCP | |
| Service | AgentCore Identity | Entra Agent ID [/blog/entra-agent-id/] | Agent Identity |
| Status (September 2026) | Generally available as part of AgentCore | Generally available | Preview for most services |
| Agent’s own identity object | Workload identity in an agent identity directory | Agent identity, created from an agent identity blueprint | A SPIFFE-based principal per agent |
| AWS or cloud API permissions come from | The agent’s IAM execution role | Permissions granted to the agent identity | IAM roles granted to the agent’s principal |
| Third-party credentials | Token vault, scoped to agent and user | Tokens obtained through the blueprint | Outside Agent Identity’s scope; it covers the agent’s own access to Google Cloud and other services with bound tokens |
| Long-lived secrets | Possible in credential providers and API keys | On the blueprint (secrets, certificates or federated credentials) | None; certificates rotate automatically |
| Agents that do not use it | Ordinary IAM roles and users | Ordinary service principals | Ordinary service accounts |
The design choice on AWS is worth understanding. AgentCore Identity does not replace IAM for AWS access. The execution role still decides what the agent can do inside your account, and the workload identity decides which outside credentials it can use. Reviewing one without the other misses half the agent’s reach. The Microsoft equivalent takes a different route, putting credentials on a blueprint that many agent identities share, which is covered in our Entra Agent ID guide.
What a security reviewer should check
- Which IAM roles trust bedrock.amazonaws.com or bedrock-agentcore.amazonaws.com, and what each can reach beyond Bedrock.
- Every execution role in the table above, including action-group Lambdas and tool roles, with its permissions reviewed against what the agent actually uses.
- Which workload identities exist in the agent identity directory, and whether each maps to a known, owned agent.
- Which credential providers are configured, which outside services they reach, and what scopes their OAuth clients request.
- Whether credential provider access is scoped down by workload identity, so one agent cannot retrieve another’s credentials.
- Whether the inbound JWT authorizer restricts the issuer, audience and allowed clients.
- Whether any Bedrock long-term API key exists, who created it, and when it expires.
- Whether CloudTrail data events are enabled for agent invocation and for AgentCore Identity resources.
- Whether Bedrock model invocation logging is on, and who can read its destination.
Point 8 needs emphasis. The CloudTrail data events reference lists AgentCore resource types including AWS::BedrockAgentCore::Runtime, AWS::BedrockAgentCore::WorkloadIdentity, AWS::BedrockAgentCore::TokenVault, AWS::BedrockAgentCore::OAuth2CredentialProvider and AWS::BedrockAgentCore::APIKeyCredentialProvider. Data events are off by default. Classic Bedrock agent invocations, InvokeAgent and InvokeInlineAgent, are data events too. Without them, there is no record that an agent ran or retrieved a credential. Our guide to CloudTrail data events explains how to enable them selectively.
Common questions about Bedrock AgentCore Identity
It is AgentCore’s identity and credential service for AI agents. It gives each agent a workload identity, authorises inbound callers with IAM or JWT, and stores the OAuth tokens and API keys agents use for outside services in a token vault.
No. The agent’s IAM execution role still controls what it can do in AWS. AgentCore Identity adds a workload identity for retrieving outside credentials, so a full review covers both.
It is AgentCore Identity’s secure store for OAuth tokens, API keys and other credentials. AWS states that a stored credential can only be accessed by the agent and user combination that originally obtained it.
No. AgentCore Runtime and Identity resources are CloudTrail data event resource types, and data events are off by default. You have to enable them, and they are charged separately.
AWS recommends against long-term keys outside exploration and advises short-term credentials for anything with real security requirements. For workloads running in AWS, an IAM role is better than either kind of key.
Where a platform fits
A new object type means a new thing to inventory. Workload identities, credential providers and the execution roles around them need to sit in the same inventory as every other identity in the account, with their permissions and relationships.
Cy5’s ion platform records identities, workloads and data stores across AWS, Azure and GCP in its entity graph, together with what each identity can reach, and its CIEM view compares granted with used permissions on execution and tool roles. It does not rely on labelling which identities belong to agents: every agent runs on an identity, and ion governs identities. See the ion platform overview and our guide to AWS Bedrock security.
Limitations and when this was checked
AgentCore is changing quickly; AWS released a new version of AgentCore Runtime in September 2026. This page reflects the AgentCore Identity developer guide and CloudTrail documentation as read in September 2026, and it carries a last-updated date for that reason. Treat AWS’s guide as the authority on configuration. And remember what identity cannot show: which prompt led an agent to use a credential. That needs model invocation logging or agent tracing.
