Identity and access: three different questions, three different mechanisms

Lesson 2 of 5 in AWS Agents in Practice: Deploy, Authorize, Guard, Observe, Pay.

"Can the agent do this?" is not one question. It is three, and teams that blur them end up with one over-powered IAM role standing in for all of it — the shared-service-account pattern, reinvented for agents.

Inbound: who is allowed to invoke this agent? Platform: what AWS resources may the agent itself touch? Outbound on behalf of a user: when the agent calls a third-party service — a user’s calendar, a user’s repository — whose authority does that call carry?

AWS answers them with three different mechanisms, and the interesting part is that only one of them is IAM.

Three questions, three mechanisms
Question	Mechanism	What it looks like	Failure mode if you use the wrong one
Who may invoke this agent?	IAM SigV4 for callers inside AWS security boundaries, or an OAuth JWT bearer-token authorizer configured at `CreateAgentRuntime` with an IdP discovery URL plus allowed clients.	A service calls with AWS credentials; or a browser app presents a user’s JWT from Cognito, Okta or Microsoft Entra ID.	Handing external users IAM credentials so they can call the agent — the anti-pattern that JWT inbound auth exists to remove.
What AWS resources may the agent touch?	The AgentCore Runtime execution role — ordinary IAM, ordinary least privilege review.	A role with the specific S3 prefixes, tables and model invocations this agent needs.	One fat role shared by every agent: the blast radius of any single injection becomes the union of everything all your agents can do.
Whose authority does an outbound third-party call carry?	AgentCore Identity — resource credential providers plus the resource token vault holding users’ OAuth tokens for delegated access.	The agent fetches this user’s Google or GitHub token to act on their behalf, and only theirs.	A single shared API key for all users: every user gets everyone’s access, and your audit trail cannot say who asked.

AgentCore Identity — Developer Guide and AWS Security Blog

AgentCore Identity is an identity and credential management service for AI agents and automated workloads. Agent identities are implemented as workload identities with specialized attributes, and each gets a distinct ARN in a central directory.

Its components: an agent identity directory (single source of truth for agent identities), an agent authorizer (validates whether a caller may invoke an agent), resource credential providers (how to obtain credentials for downstream resource servers such as Google or GitHub), and a resource token vault (users’ OAuth access tokens for delegated, on-behalf-of access).

The vault stores OAuth 2.0 access and refresh tokens, API keys and OAuth client secrets, encrypted with AWS KMS keys — customer-managed keys supported — with native integration to AWS Secrets Manager. User-specific credentials are accessible only by the individual agent acting on behalf of the associated user.

The mechanism worth walking through slowly is the on-behalf-of flow, because it is where agent identity stops resembling anything you have deployed before.

A user signs in to your app and calls the agent with a JWT. The runtime’s authorizer validates it against the configured IdP. The validated user token is then exchanged for a workload access token — the call is bedrock-agentcore:GetWorkloadAccessTokenForJWT — and that token is what the agent uses to reach into the vault for the user’s downstream credentials. Outbound tokens are cached keyed by (agent workload identity, user ID), which is the mechanical reason one user’s Google token cannot be handed to another user’s session: the cache key includes the user.

Notice what this buys you at incident time. Two agents and two users produce four distinct authority contexts, each traceable to a workload identity ARN. Compare that with a shared service account, where the only honest answer to "who did this?" is "the platform".

Acting on behalf of a user, end to end

User signs in to your app (IdP)
Cognito, Okta or Microsoft Entra ID — the IdP you already run. The agent never sees the user’s password.
App invokes agent with the user’s JWT
Inbound auth was configured at CreateAgentRuntime: IdP discovery URL plus the list of allowed clients.
Agent authorizer validates the token
May this caller invoke this agent? Rejected calls never reach your agent code.
Exchange for a workload access token
bedrock-agentcore:GetWorkloadAccessTokenForJWT. The agent now has a token bound to its own workload identity plus this user.
Fetch this user’s credential from the token vault
Resource credential provider says how; the vault holds the OAuth token, KMS-encrypted. Outbound tokens are cached keyed by (workload identity, user ID).
Call the third-party API as that user
The user’s calendar, the user’s repository — scoped to what that user consented to, not to what your organisation could do.
Touch AWS resources via the execution role
A separate question with a separate answer: ordinary IAM, scoped per agent. Do not let this role become the union of every agent’s needs.
Result returned, actions attributable

Interactive sorting exercise: Seven access requirements from one real deployment. Which mechanism answers each? The test is always: whose authority is this, and where is it enforced?

Key terms: workload identity, least privilege, prompt injection, blast radius, egress control

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.