Two questions, two layers, and they get read as one. The five parts of Amazon Bedrock AgentCore places both in the wider runtime, 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 identity layer that establishes which workload is asking before an agent runs, and the policy layer that constrains what a permitted agent may then do.
- An agent that acts on real systems needs an identity of its own. A long-lived key sitting in the agent’s environment is shared by every request it makes, so the logs cannot attribute an action to a particular caller or a particular person, and the credential cannot be narrowed to the job in hand or revoked without breaking every other use of it.
- Amazon Bedrock AgentCore Identity establishes which workload is asking, before your agent code runs. It covers inbound authorisation, meaning whether the caller reaching the agent is allowed to invoke it, and it also obtains outbound credentials, meaning the short-lived access the agent then uses to reach a downstream system on somebody’s behalf.
- The token vault is where those outbound credentials live: OAuth tokens, client secrets and API keys, encrypted with an AWS KMS key. A credential is handed back only against verifiable proof of workload identity, and only to the agent and user combination that obtained it, so one agent cannot fetch a token that belongs to another.
- Policy in AgentCore constrains what a permitted agent may then do, which is a different question from who it is. Identity without policy still leaves an authenticated agent able to do everything its credentials allow, which is usually far more than the task it was invoked for.
- None of this replaces IAM. The guide keeps listing “IAM roles, policies, and permissions” alongside the two new names because IAM still governs which AWS APIs the agent’s execution role may call. AgentCore identity and policy sit above that, deciding who reached the agent and what the agent may do with the access it has.
Pick it when
Reach for these names when a scenario describes an agent acting against real systems or on a named person’s behalf, and the worry is either attribution (whose action was that) or scope (what could it have touched). The first is Amazon Bedrock AgentCore Identity, the second is Policy in AgentCore.
It's the wrong answer when
They are the wrong answer for what the model is allowed to say, which is Amazon Bedrock Guardrails, and for who may call an AWS API, which stays with IAM. They also do nothing about a tool that is dangerous by design: an agent correctly identified and correctly permitted to issue refunds can still issue a bad one.