Amazon Bedrock AgentCore Identity gives AI agents a durable identity and a managed way to obtain credentials for AWS resources and external services. It is designed for workloads that may need to act as themselves, act on behalf of a user, or obtain machine-to-machine credentials for a tool without embedding secrets directly in agent code.
Within Generative AI on AWS, Identity is the layer that answers “who is this agent, who is the user, and which credential should be presented to the next service?” Those questions should be answered independently of the model’s natural-language reasoning.
Agent identity is not the same thing as user identity. A production workflow may need both at the same time: the agent must be identifiable as a workload, while the downstream service must also know whose data the agent is authorized to access.
Workload identities give agents a stable security principal
AgentCore implements agent identities as workload identities that persist across deployment environments and authentication schemes. Runtime and Gateway can create workload identities automatically, and the resulting identity ARN can be referenced in IAM policies and access controls.
This creates a stable anchor for the agent even when the underlying runtime changes. The agent may use IAM roles for AWS access, OAuth tokens for a SaaS tool, and API keys for another service, yet those credentials can still be associated with one workload identity.
That separation is useful for audit because the organization can distinguish “which agent requested the credential?” from “which user authorized the action?”
Inbound authentication controls who may invoke the agent
AgentCore Runtime can validate inbound requests using AWS IAM or OAuth-based authentication. An OAuth configuration can validate tokens from an identity provider using its discovery endpoint and expected audiences before a request reaches the agent.
Inbound authentication is the first trust boundary. If a service accepts an arbitrary user identifier from the request body while authenticating only one shared backend identity, later memory and tool controls cannot reliably know which human initiated the interaction.
The existing authentication and user identity architecture article provides the broader principle: identity should be established by a trusted authentication mechanism, not inferred from application content.
User-delegated OAuth preserves consent and user-specific access
When an agent needs to access a user’s external account, the OAuth authorization-code pattern lets the user grant consent for specific scopes. AgentCore Identity orchestrates the token flow and stores the resulting access token in its credential vault so the agent does not handle the user’s password or long-lived secret directly.
This is appropriate for use cases such as reading a user’s Google Drive files, acting in a CRM on the user’s behalf, or accessing another user-specific resource. The agent should request only the scopes needed for the task, and the product should make the consent boundary visible to the user.
A delegated token should not quietly become a general application credential. Its meaning is “this agent may perform these actions on behalf of this user under this consent.”
Machine-to-machine OAuth is for workload-owned access
Some tools are not user-owned. A background agent may need to call a service account, internal API, or SaaS integration where the organization—not an individual user—owns the access. OAuth client credentials provide that machine-to-machine pattern.
The security review should confirm that the client credential is associated with the correct agent workload and that downstream scopes are narrow enough. A client credential with organization-wide access can create a much larger blast radius than a delegated user token.
AgentCore Gateway can use these credential providers when it invokes tool targets.
On-behalf-of token exchange keeps both agent and user context
AgentCore Gateway supports token exchange for scenarios where a downstream service should see a scoped token representing the original user in the context of the agent. This is stronger than replacing every caller with one generic gateway identity because the resource server can enforce fine-grained authorization using user and workload context.
On-behalf-of designs should be deliberate. The downstream API needs to understand and validate the exchanged token, and the organization should define which scopes can be delegated through the agent. It is not simply a convenience mechanism for avoiding reauthentication.
This pattern is particularly valuable when an agent mediates access to sensitive internal systems where user-level authorization must survive multiple hops.
API keys should be vaulted, not embedded in agent prompts or code
AgentCore Identity can store API keys directly or reference keys held in AWS Secrets Manager. Agents can use the credential provider without exposing the key value in application source or configuration that developers routinely inspect.
API-key access should still be treated as the weaker identity pattern when a target supports stronger OAuth or IAM mechanisms. Many API keys identify an application but not a user, and some lack fine-grained scopes or short expiration periods.
The existing AWS KMS and Secrets Manager article provides broader credential-storage context. The planned Secrets Management for AI Apps article goes deeper into GenAI-specific secret boundaries.
Identity should follow the action into the tool layer
It is not enough to authenticate the user at the chat front end and then lose that context when the agent invokes a tool. The tool layer must receive the identity information required to enforce its own authorization policy.
This can mean delegated OAuth, token exchange, caller IAM credentials, or a deliberately scoped service identity. The correct pattern depends on whether the action is user-owned, application-owned, or shared. A downstream tool should never rely on the model saying “the user is allowed” as proof of authorization.
The existing IAM design for generative AI workloads is directly relevant because agent autonomy increases the importance of deterministic least privilege.
Credential lifecycle should be observable and revocable
Production identity architecture needs to answer how credentials are created, refreshed, revoked, rotated, and audited. OAuth access tokens expire, refresh tokens can be invalidated, user consent can change, and API keys can be rotated. The agent should fail in a controlled way when a credential is no longer valid instead of repeatedly retrying with the same rejected secret.
Observability should identify the credential provider and authorization stage without logging token values. Operators need enough context to distinguish “tool is down” from “user consent expired” or “agent lacks the requested scope.”
Credential lifecycle events should also be part of offboarding. Removing a user or retiring an agent should revoke access rather than leaving token material available indefinitely.
Identity architecture is successful when agents cannot invent authority
The most important property of AgentCore Identity is that authority is external to the model. The model can choose a tool or propose an action, but it cannot mint a valid user consent, expand an OAuth scope, or create an IAM permission simply by asserting that the action is necessary.
That boundary makes agents easier to trust. Workload identity, inbound authentication, delegated access, machine credentials, token exchange, and secret storage all exist so the generative part of the system can remain powerful without becoming the source of truth for authorization.
Inbound and outbound identity should also be kept conceptually separate. Inbound authentication proves who may invoke the agent. Outbound authorization determines how that agent reaches a tool or external resource. Reusing one token mechanically for both can create audience, scope, and privilege problems. A user token intended for the agent endpoint may not be valid or appropriate for a downstream API.
Token exchange is useful precisely because it creates a new token for the downstream audience while preserving delegation context. The downstream service can evaluate a token meant for it instead of receiving the original access token that was minted for another resource. That reduces token replay risk and makes scopes easier to reason about across hops.
Credential providers should be inventoried like other production dependencies. A GitHub OAuth client, Salesforce client, or API-key provider can be shared by several agents, which means rotating or deleting it can affect more workloads than the team making the change expects. Tags, ownership metadata, and dependency records help prevent credential maintenance from becoming an outage.
User consent also needs product design. If an agent requires access to a calendar, CRM, or document system, the interface should explain why the permission is needed and what the agent will do with it. Consent that is technically valid but poorly explained creates security and trust problems when users later discover actions they did not expect.
For regulated workloads, identity telemetry should be sufficient to reconstruct the authorization chain: authenticated caller, agent workload identity, credential provider, scopes, target, and outcome. That evidence should exclude raw secrets while remaining detailed enough to answer who acted on whose behalf and under which authority.
Environment separation should be explicit as well. Development, staging, and production agents may use different workload identities, OAuth clients, and downstream scopes even when they run the same code. Reusing one credential provider everywhere can let a development agent reach production data or make production rotation dependent on a test environment. Identity configuration belongs in the deployment model, with environment-specific resources where the trust boundaries differ.
