AgentCore Identity Overview

A demo agent answers questions. A production agent acts on real systems on a user's behalf — it reads someone's Google Drive, opens a GitHub PR, posts to a Slack channel, hits an internal billing API. The instant an agent does real work, two security questions become unavoidable:

1. Who is allowed to invoke this agent? A random caller should not be able to trigger an agent that can spend money or read private data.
2. How does the agent reach downstream resources — without secrets in code or in the model's context? You cannot paste a long-lived API key into a prompt or bake it into the container image and call that production.

The naive answer is a shared secret: hand the agent one powerful credential and let it impersonate everyone. That is exactly the anti-pattern AgentCore Identity exists to kill. Identity makes agentic auth delegated, not impersonated-with-a-shared-secret: the agent gets a scoped, user-specific token for each downstream call, and credentials never touch your business logic or the LLM context.

Concretely, AgentCore Identity gives every agent/workload two things:

• A first-class, centrally-managed identity — a unit of governance you can reason about, audit, and scope.
• A secure credential store (the token vault) — where OAuth tokens, OAuth client credentials, and API keys live, encrypted, never in code.

With those two pieces in place, agents are invoked securely and call downstream APIs on a user's behalf with no secrets leaking into prompts, logs, or images.

AgentCore Identity solves exactly two problems. Keeping them separate in your head is the single most useful mental model for everything that follows.

Inbound Auth — authenticates and authorizes the caller invoking an agent, tool, Runtime, or Gateway. This is the gate at the front door: is this request from someone allowed to trigger this agent at all?

Outbound Auth — lets the agent reach downstream resources (Google Drive, GitHub, Slack, internal APIs, other MCP servers). The agent can act either on behalf of the user who invoked it (the 3-legged / user-delegated flow) or as itself (the 2-legged / machine-to-machine flow). You will go deep on 2LO vs 3LO in a later lesson; for now, the key idea is that outbound is about the agent's onward calls, fetching the right token for each one.

The two are independent: an agent can be invoked over JWT inbound while making 3LO outbound calls to Google, or invoked over SigV4 while making 2LO calls to an internal service. Identity governs both ends; this lesson frames them, and the rest of the module drills into each.

Two pictures make this stick.

Inbound = the bouncer at the door. Someone shows up wanting to invoke your agent. The bouncer checks credentials before letting them in. In AgentCore those credentials are either an AWS SigV4 signature (the caller proves they're an allowed AWS principal) or a JWT bearer token (the caller proves they hold a valid OAuth/OIDC token from your identity provider). No valid credential, no entry.

Outbound = the valet who fetches the user's keys from a locked vault. Once inside, the agent needs to drive the user's car — call Google Drive, GitHub, an internal API. It does not carry the user's keys around in its pocket (no secret in code, no token in the prompt). Instead it asks the valet (Identity), who walks to the locked vault (the token vault), retrieves the right key for this specific user and this specific resource, and hands it over just long enough to make the call. The keys stay in the vault; the valet does the fetching.

That is why the system is delegated, not impersonated. The agent never holds a master key. Each outbound call is backed by a token that is:

• scoped to a specific downstream resource and set of scopes, and
• isolated per (agent identity + user) — so one user's tokens are never visible to another's session.

Keep the pair in mind as you read AWS's docs: every Identity feature is either hardening the bouncer (inbound) or improving the valet-and-vault (outbound).

Every agent/workload gets a first-class managed identity, and a Workload Identity is auto-created with each runtime. You do not have to stand one up by hand for the common case — deploy a runtime and its workload identity comes with it.

Each agent identity functions like a Cognito User Pool: it is a unit of governance you can scope, audit, and reason about independently. It has a stable ARN of the shape:

arn:aws:bedrock-agentcore:<region>:<account>:workload-identity/directory/default/workload-identity/<agent-name>

Note the directory/default segment: workload identities live in a per-account workload directory, and default is the directory they land in. This directory is the registry of agent identities for your account — the thing that makes "this agent" a first-class entity rather than just a container.

Under the hood, three control APIs back the workload-identity machinery: CreateWorkloadIdentity, GetWorkloadAccessToken, and GetResourceOauth2Token. You rarely call these directly — the SDK decorators wrap them — but knowing the names helps you read IAM policies and CloudTrail. A later lesson walks the full Workload Access Token exchange end to end; here, just anchor on: one managed identity per agent, auto-created, addressable by ARN, living in the workload directory.

# The decorators that exercise the workload identity + vault live here.
# (Detailed usage is covered in the credential-providers lesson.)
from bedrock_agentcore.identity.auth import requires_access_token, requires_api_key

AgentCore Identity is framework- and model-agnostic. It is not coupled to a particular agent framework (Strands, LangGraph, CrewAI, and friends) or to a particular model provider — the identity, the token vault, and the inbound/outbound flows are the same regardless of what's running inside your agent.

It is also not tied to AgentCore Runtime. Identity works in Runtime, in ECS/EKS/Lambda, or in a hybrid deployment. You get the managed identity and the token vault whether your agent runs on the AgentCore-managed serverless Runtime or on your own compute. That matters in practice: teams migrating an existing containerized agent onto AWS can adopt Identity for secure credential handling without first rewriting everything to run on Runtime.

A concrete example of Identity doing outbound work, framework-agnostic, is how API keys are handled. You do not bake keys into the image. Instead a decorator injects the credential at call time from the vault:

from bedrock_agentcore.identity.auth import requires_api_key

@requires_api_key(provider_name="openai-provider", into="api_key")
async def call_openai(*, api_key: str):
    # `api_key` was fetched from the token vault at call time,
    # never stored in code, the image, or the LLM context.
    ...

The same pattern — credential fetched from the vault, injected as a kwarg, never exposed to the model — holds no matter which framework orchestrates the agent or which model it talks to.

A frequent point of confusion: IAM and AgentCore Identity are not the same layer.

• IAM governs AWS-level access — the control- and data-plane APIs, creating credential providers, KMS, and the agent's execution role. SigV4 inbound auth is one of the things IAM governs. Key IAM actions you'll see include InvokeAgentRuntime, InvokeAgentRuntimeForUser, the GetWorkloadAccessToken* family, and GetResourceOauth2Token.
• AgentCore Identity governs agent-level / workload identity — the workload directory, the token vault, and OAuth 2LO/3LO to non-AWS services (Google, GitHub, Slack, internal OIDC APIs).

A clean way to remember it: IAM is how AWS decides what your AWS principals and roles can do; Identity is how your agent proves who it is and fetches third-party credentials on a user's behalf. They interlock — the execution role (IAM) is what's allowed to mint workload access tokens (Identity) — but they answer different questions.

This lesson is the map. The rest of Module 5 walks each region of it:

• Inbound auth — SigV4 vs JWT/OIDC (mutually exclusive per runtime version), customJWTAuthorizer, and invoking OAuth-protected agents.
• Outbound auth & the token vault — the Workload Access Token flow, 2LO vs 3LO, per-provider refresh-token config, and KMS-backed vault isolation.
• Credential providers & the SDK decorators — built-in OAuth vendors, API keys, @requires_access_token / @requires_api_key, and the callback-URL gotcha.
• Governance — how Identity sits alongside IAM, Guardrails, and policy.

Hold onto the two problems and the two analogies; everything else hangs off them.