The moment you give an AI agent the ability to call tools — query a database, hit an API, kick off a workflow — you've created a new kind of identity in your AWS account. It's an identity that can be talked into doing things, because the instructions it follows arrive as natural language, some of it from sources you don't control. Your old IAM model wasn't designed for that.
AWS's answer, from re:Invent 2025, is Amazon Bedrock AgentCore Identity. Here's the practitioner view of how to bound an agent.
Practitioner guidance, not legal or audit advice.
The problem: an agent inherits too much
The naive pattern gives the agent the application's role. Now anything that can manipulate the agent's prompt — including indirect prompt injection from retrieved content — can use the application's full permissions. That's the same mistake as running every microservice as root, except the attacker's input arrives as a sentence.
The principle hasn't changed: least privilege. What's changed is that the agent's effective permissions must also depend on who it's acting for.
What AgentCore Identity does
AgentCore Identity provides authentication and access controls for AI agents, restricting their interactions to authorized services and data based on the specific user's permissions and attributes. Two things matter in that sentence:
- The agent has its own identity boundary — it's not just borrowing the app's.
- Its access is scoped to the user it's currently acting on behalf of — so the agent can't do for User A what only User B is allowed to do.
It composes with Amazon Verified Permissions (fine-grained authorization decisions) and Cognito (user identity), so authorization becomes an explicit decision the agent's tools enforce — not an assumption baked into one over-broad role.
The pattern to implement
- Give the agent its own execution role, scoped to the minimum AWS actions it needs — never the application's role.
- Scope tool access to the acting user. When the agent calls a tool, the authorization decision considers the end user's permissions, not just the agent's. Verified Permissions is built for exactly this.
- Make every tool enforce its own authorization. Assume the agent can be tricked into calling a tool; the tool must independently check whether this action, for this user is allowed.
- Log the agent's actions with the user context, so you can answer "what did the agent do, for whom, and why" after the fact.
The mental model
You cannot guarantee the model won't be fooled by a malicious prompt. So you make sure a fooled agent can't do anything its identity — scoped to the current user — isn't allowed to do. Prompt injection becomes an authorization problem, and authorization is a problem AWS gives you real tools to solve — at the IAM and AgentCore layer, not inside the prompt where it can't be trusted.
Why this matters for regulated workloads
For an APRA-regulated entity deploying agentic AI, "restrict administrative privileges" and "implement controls sized to the threat" (CPS 234, and Essential Eight strategy 5) now extend to non-human AI identities. An agent with standing broad permissions is the same finding as a human with standing admin — and a sharper one, because the agent follows instructions from untrusted text. Treat agent identities with the same least-privilege discipline you (hopefully) apply to humans.
Primary sources: Amazon Bedrock AgentCore Identity · AWS re:Invent 2025 AI security