AgentCore Identity: Patterns, Security, and Lessons from the Field

This is Part 3 of a three-part series on agent identity. Part 1 covered the problem space. Part 2 covered how AgentCore Identity works under the hood. This post covers the patterns you'll actually use, the security properties you get, and lessons from the field.

Three Scenarios: Choosing the Right Pattern

The AgentCore team frames the common deployment patterns as three scenarios that build on each other progressively. Start with Scenario 1, add Scenario 2 when you need user-delegated access, evolve to Scenario 3 when downstream tools need user context.

A single agent often uses multiple scenarios simultaneously. For example, Client Credential flow for Jira (system-level) and Authorization Code flow for Google Drive (user-delegated) in the same agent.

Scenario 1: Autonomous Agent (Client Credential Flow)

No human user in the loop. Agent acts autonomously with its own credentials.

Backend App -> Runtime (IAM auth) -> Identity (WAT) 
  -> Cred Provider (Client Creds) -> External API (Jira, Slack)

The agent uses @requires_access_token(auth_flow="M2M"). No user consent needed. Token scoped to agent's own identity. Ideal for background jobs, scheduled syncs, system integrations, admin APIs.

Scenario 2: User-Initiated Agent (Authorization Code Flow)

Human user in the loop. Agent acts on behalf of the authenticated user.

User (Sign in) -> App (JWT) -> Runtime (JWT auth) -> Identity (WAT) 
  -> Cred Provider (Auth Code) -> Google Drive (User files)

Setup involves configuring your IdP, creating an OAuth2 Credential Provider for the target (e.g., Google), setting up Runtime with Custom JWT inbound auth, implementing the Session Binding URL, and using @requires_access_token(auth_flow="USER_FEDERATION") in your agent code.

The resource token in Token Vault is keyed to agent_id + user_id. Different user, separate token.

Scenario 3: On-Behalf-Of with Gateway Lambda Interceptor

This extends Scenario 2 and solves a problem that's easy to miss until you hit it.

In Scenario 2, when your agent calls Google Drive, Google enforces access control. Google looks at Alice's token and shows Alice's files. But what about your own internal tools? A multi-tenant Jira instance, a shared analytics service, an internal knowledge base?

These services don't have Alice's OAuth token. They don't know who Alice is. All they see is an incoming request from "some agent." Without user context, they can't do per-user access control, can't create per-user audit trails, and can't enforce tenant isolation.

The Gateway Lambda interceptor solves this. It sits between the agent and the downstream tool, extracts user identity from the WAT or JWT claims, performs fine-grained authorization, optionally does token exchange (RFC 8693 / RFC 7523), and injects identity headers (x-user-id, x-tenant-id) for the target.

User+App (JWT) -> Runtime -> Identity (WAT) -> Gateway 
  -> Lambda Interceptor (Extract + inject) -> Tool Target (Agent + User context)

Scenario Comparison

Decision Guide

• Does the agent need to access user-specific data? Scenario 2 or 3
• Does the downstream tool need to know which user? Scenario 3
• Is it a system-level integration with no user context? Scenario 1
• Do you need per-user audit trails at the tool level? Scenario 3

Progressive adoption: start with Scenario 1 for system integrations. Add Scenario 2 when you need user-delegated access. Evolve to Scenario 3 when downstream tools need user context. Each scenario builds on the previous one.

End-User Identity Propagation: The Hard Problem

Say you have: User (Alice) -> Agent A -> Agent B -> Google Drive API. Alice asks Agent A to find a document. Agent A delegates to Agent B. Agent B needs to call Google Drive. But it should only see Alice's files. How does Alice's identity survive this entire chain?

What AgentCore does today. The WAT contains both the agent identity and the user identity. The Token Vault stores tokens per user-agent pair. When Agent A delegates to Agent B, if Agent B runs on Runtime and receives the request with Alice's JWT or user ID, Runtime generates a new WAT for "Agent B acting for Alice." Agent B can then access Alice's credentials from the vault.

The gap: there's no built-in mechanism that captures the full delegation chain in a single token. Each agent independently proves "I am this agent + this is Alice."

Practical approaches today:

Pass the User ID Through the Chain (simplest). Every agent receives the user's identity and generates its own WAT. The user's identity propagates, even though there's no single token capturing the full delegation chain.

Gateway Lambda Interceptor (recommended). The interceptor performs token exchange at the gateway layer. Token exchange (defined in RFC 8693) is a standard OAuth mechanism where you present one token and get back a different, more constrained token for the next hop. The interceptor can use this to create scoped downstream tokens with the full delegation context.

External IdP with RFC 8693 (most robust). Put an IdP that supports token exchange (Keycloak, PingFederate, Okta) in front of your agent chain. Each hop does a token exchange, and the actor claim nests, creating a complete audit trail.

The Complete Flow

Let's trace through a complete scenario. Alice uses a web app with an AI agent and says "Find the Q3 planning doc in my Google Drive and add the meeting notes from last Tuesday's calendar event."

1. Alice logs into web app via Okta, gets Human Access Token (JWT)
2. Web app sends request + JWT to AgentCore Runtime
3. Runtime validates JWT (signature, expiry, claims), generates WAT bound to calendar-agent + alice
4. Agent needs Google Drive: calls GetResourceOauth2Token with WAT. First time? Consent flow with session binding. Already consented? Token returned directly from vault (auto-refreshes if expired).
5. Agent needs Google Calendar: same flow, separate consent, separate token
6. Agent calls Google Drive API with Alice's resource token, gets only Alice's files. Calls Calendar API, gets only Alice's events.
7. Agent returns combined results to Alice through the web app

At every step, the identity chain is clear. Alice authenticated with Okta, the web app forwarded her identity to AgentCore, AgentCore bound her identity to the agent's identity via the WAT, the agent accessed only Alice's credentials from the vault, and Google enforced access control based on Alice's tokens.

Security Properties

Here's what AgentCore Identity gives you out of the box:

No Credentials in Code. Everything lives in the Token Vault, retrieved at runtime via the SDK.

Encryption at Rest. Token Vault encrypts all stored credentials using AWS KMS. You can bring your own customer-managed key via SetTokenVaultCMK.

Short-Lived Tokens Everywhere. User JWTs: typically 15 min to 1 hour. WATs: short-lived. OAuth access tokens: typically 1 hour. Authorization URLs and session IDs: 10 minutes.

Per-User-Agent Credential Isolation. Alice's Google token stored by calendar-agent is only accessible when the WAT proves both "I am calendar-agent" AND "I am acting for Alice."

Confused Deputy Prevention. The separation of workload identity and IAM role prevents confused deputy attacks. Both must be valid.

Session Binding. Prevents authorization URL hijacking. Requires your web app to implement the callback verification.

Audit Logging via CloudTrail. All AgentCore Identity API calls are logged. "Agent X accessed Resource Y on behalf of User Z."

What's your responsibility: Fine-grained authorization (your agent code or a policy engine), input validation (prompt injection, jailbreaking), network security (VPC configuration), and data classification.

Lessons from the Field

These are practical lessons from real-world AgentCore Identity deployments.

Start simple, build incrementally. The most common mistake is trying to implement Scenario 3 (OBO with interceptors and token exchange) on day one. Don't. Get Scenario 1 working. Then add user-delegated access. Then add interceptors. Each layer builds on the previous one.

Gateway as a quick fix for legacy APIs. Say you have a legacy internal API that uses basic auth or a static API key. You don't want your agent code handling raw secrets. Put a Gateway in front of the legacy API. The Gateway handles credential injection (pulling the API key from the Token Vault), and your agent code never touches the raw secret.

Separate authenticate, propagate, authorize. Don't mix identity and access into the models. Think of it as three distinct phases: Authenticate (who is this?), Propagate (pass that identity to the next hop), Authorize (should this identity be allowed to do this?). When you blur the lines, you end up with confused deputy problems and audit gaps.

Zero Trust applies to agents too. Just because an agent is running inside your VPC doesn't mean you should trust it implicitly. Verify identity at every hop. Fine-grained access control per-user, per-tool, per-operation. Network isolation via VPC endpoints and VPC Lattice.

Credential strength hierarchy. Not all credentials are created equal. From weakest to strongest: static API keys (no expiry, no user binding), OAuth tokens (short-lived, scoped, user-bound), and mutual TLS with certificate-based identity (both sides prove identity cryptographically, no shared secrets). Use the strongest credential type your target service supports.

Agents are first-class principals. An agent isn't "Alice's script." It's a separate entity with its own identity, its own permissions, and its own audit trail. When Alice leaves the company, the agent should still work (with appropriate re-authorization), not break because it was tied to Alice's personal credentials.

Concepts Are Universal

While this series focused on AWS Bedrock AgentCore, the concepts apply broadly. MuleSoft Agent Fabric uses RFC 8693 token exchange at the Flex Gateway layer. Ping Identity implements nested actor claims for delegation chains. Azure Entra ID has its own On-Behalf-Of flow. Auth0, Okta, and Keycloak all support token exchange in various forms.

The underlying patterns, workload identity, user-delegated access, token exchange, credential vaults, gateway interceptors, are the same regardless of the platform. If you understand how AgentCore does it, you understand the pattern everywhere.

If you want to go deeper, I cover OAuth 2.0, OIDC, JWTs, and agent security from scratch in my book OAuth and OIDC From First Principles.

This is Part 3 of a three-part series. Read Part 1: The Identity Problem for AI Agents and Part 2: How AgentCore Identity Actually Works.

← Back to all posts