An AI agent doesn't just answer questions: it calls tools, reads systems and takes actions, often for a specific user. That creates two security questions a chatbot never had to answer. How does the agent prove who it is, and get credentials to other services safely? And what stops it from taking an action it shouldn't, even if a prompt tricks the model? On AWS, Amazon Bedrock AgentCore Identity answers the first, and Policy in AgentCore answers the second.
Why Agents Need Their Own Controls
A language model decides what an agent does next, and a model can misread a business rule or be manipulated by a cleverly worded prompt. If the only thing standing between the agent and a costly action is an instruction in its prompt, the protection is only as strong as the model's judgment. Agents also need credentials: to read a user's calendar, update a ticket or query a database. Storing passwords or API keys inside agent code is risky, because anyone who reads the code or tricks the agent can get them.
AgentCore Identity
Amazon Bedrock AgentCore Identity manages identities and credentials for agents. Each agent gets its own workload identity, with a unique ARN, held in a central directory so administrators can govern agents the way they govern users.
Its token vault stores OAuth 2.0 tokens, OAuth client credentials and API keys, encrypted with AWS KMS keys. An agent can only retrieve a credential when it proves its identity, so secrets don't need to live in code or configuration files. AgentCore Identity supports both main OAuth 2.0 patterns:
- Machine-to-machine access, where the agent authenticates as itself with no user involved.
- User-delegated access, where a user explicitly consents and the agent then acts on that user's behalf, for example reading their files in a third-party service.
It includes ready-made credential providers for common services such as Google, GitHub, Slack and Salesforce, verifies every request independently, and logs operations for auditing.
Policy in AgentCore
Policy in AgentCore puts a rule-checking boundary around what an agent can do with its tools. Agent tool calls go through an AgentCore Gateway, and Policy intercepts each call and checks it against the rules in a policy engine before the tool runs. Rules can depend on who the user is and on the tool's input values, such as the amount of a refund.
Policies are written in Cedar, an open-source authorization language, or described in plain English and turned into Cedar for you. AWS validates natural-language policies with automated reasoning, flagging rules that are too permissive, too strict or impossible to satisfy. Because enforcement happens outside the agent's code and outside the model, the result is deterministic: a prompt can't talk its way past it. Every decision is logged to Amazon CloudWatch for audit.
Layers That Work Together
| Control | Question it answers |
|---|---|
| AgentCore Identity | Who is this agent, and which credentials may it use? |
| Policy in AgentCore | Is this specific tool call allowed, with these inputs? |
| IAM | Which AWS resources can the agent's role reach? |
| Amazon Bedrock Guardrails | Is this prompt or response safe and on topic? |
These controls don't replace each other. Guardrails check content; Policy checks actions. A refund request can be politely worded and pass every content filter, yet still break a spending rule.
On the Exam
If a scenario says an agent must act on a user's behalf in another service without storing secrets in code, choose AgentCore Identity. If it says an agent must never perform an action above a limit, "even if the model is tricked", choose Policy in AgentCore, because the rule is enforced outside the model. A tempting wrong answer is "add the rule to the system prompt": prompt instructions guide a model but can't guarantee its behavior.