Two questions, two layers, and they get read as one. Amazon Bedrock AgentCore itself sets out the services around them, and matching a security worry to the control that owns it is the habit this card feeds. At this level, recognising the names and knowing which problem each solves is enough; the credential exchange itself is covered at professional depth in giving an agent credentials without a standing key.
Flash card
Amazon Bedrock AgentCore Identity and Policy in AgentCore: the layer that establishes which workload is asking before an agent runs, and the layer that constrains what it may then do.
- An agent that acts on real systems needs an identity of its own. A long-lived key in the agent’s environment is shared by every request it makes, so logs cannot attribute an action to a caller, and it cannot be narrowed or revoked without breaking every other use.
- Amazon Bedrock AgentCore Identity establishes which workload is asking, before your agent code runs. Inbound, a JWT authoriser validates the token of whoever is invoking the agent or gateway. Outbound, it supplies the short-lived credentials the agent then uses against a downstream system, on its own behalf or a named user’s.
- The token vault stores those outbound credentials: OAuth 2.0 tokens, OAuth client credentials and API keys, encrypted with a customer-managed or service-managed AWS KMS key. A credential is released only against verifiable proof of workload identity, and only to the agent and user combination that obtained it.
- Policy in AgentCore constrains what a permitted agent may then do. A policy engine attaches to an AgentCore Gateway, which evaluates every tool call against rules written in Cedar before the tool runs. Identity without that leaves an authenticated agent able to use everything its credentials allow.
- None of this replaces IAM. IAM still governs which AWS APIs the agent’s execution role may call, and the AgentCore actions themselves are IAM-gated. Identity and Policy sit above that, covering who reached the agent and what it may do with that access.
Pick it when
Reach for these names when a scenario describes an agent acting against real systems or on a named person’s behalf. If the worry is attribution, whose action was that, it is AgentCore Identity. If the worry is scope, what could it have touched, it is Policy in AgentCore.
It's the wrong answer when
They do not cover what the model is allowed to say, which is Amazon Bedrock Guardrails, nor who may call an AWS API, which stays with IAM. Neither helps with a tool that is dangerous by design: an agent permitted to issue refunds can still issue a bad one.