Identity and access management has been one of the most important security disciplines of the cloud era. IAM — policies, roles, service accounts, least-privilege principles — is how organizations control what software is allowed to do in their infrastructure.
AI agents break IAM. Not because IAM is wrong, but because IAM was designed for a world where principals are either humans or deterministic programs. AI agents are neither. And the gap between what IAM was designed to handle and what agents actually need is where most agent security incidents live.
Traditional IAM works well for two kinds of principals:
Humans: authenticated with passwords, MFA, or SSO. Their identity is stable, their behavior is (mostly) predictable, and they make intentional decisions about what actions to take. When a human uses a permission, there's an actor we can attribute it to.
Service accounts and microservices: these are even simpler. A payment service has specific API keys with specific scopes. It calls specific endpoints. It doesn't make decisions — it executes code. The permission envelope is well-understood because the behavior is deterministic.
IAM was built for this world. Roles, policies, and least-privilege assumptions all make sense when you know exactly what a principal will do with its permissions.
An AI agent is non-deterministic. Given the same task and the same data, it may take different action sequences on different runs. It makes judgment calls about which tools to use and in what order. It reasons across multi-step plans that weren't fully specified at deployment time.
This creates three problems for traditional IAM:
When you give an agent an API key with read access to your database, it can read any row in any table — not just the rows relevant to its current task. Traditional IAM doesn't have a concept of "permissions scoped to the current task objective."
Humans have judgment about which data is relevant to what they're trying to do. Agents may not. And more importantly, an agent that has been compromised by a prompt injection will use every permission it has been granted — not just the ones its task requires.
A single agent step might involve reading from a database (permission A), calling an external API (permission B), and writing to a queue (permission C). These are three separate permissions in IAM. But in combination, they might enable something no single permission was intended to allow — for example, exfiltrating sensitive data to an external service.
IAM doesn't reason about permission composition. Each permission is granted or denied independently. Agents, by their nature, compose permissions in dynamic and unpredictable ways.
A human who realizes they're about to do something wrong can stop. A service account runs a fixed code path. An agent runs a dynamic execution loop that can last minutes or hours, making hundreds of decisions. Traditional access control models have no concept of "this principal has been running for too long" or "this principal is exhibiting unusual patterns compared to its baseline."
IAM grants access at authentication time and doesn't re-evaluate based on runtime behavior. Agents need runtime controls.
The mental model that works is not "what roles does this agent have?" but "what is the specific surface this agent is allowed to touch?" A few principles:
Instead of "this agent has read access to the database," declare "this agent can read rows in the orders table where customer_id matches the task context." The permission is specific to the data the task requires, not broad across a resource type.
This is harder to implement but dramatically shrinks the blast radius of any single agent compromise.
The tools an agent can call are effectively its permissions. An agent with access to a send_email tool can send emails. An agent without that tool cannot — regardless of what it's been instructed to do. Limiting tool availability is one of the most direct forms of permission scoping for agents.
Grant access for a bounded runtime: "this agent is allowed to run for up to 5 minutes, call at most 200 tools, and incur at most $0.50 in API costs." If any condition is exceeded, the execution is terminated and the event is logged. This is not a concept in traditional IAM — it's something agent permission systems need to build explicitly.
Who changed the agent's permissions, when, and why? What was the permission set at the time of a specific incident? These questions matter enormously for post-incident analysis and compliance. Permission manifests should be versioned with the same rigor as application code.
The shift: Traditional IAM asks "what is this principal allowed to access?" Agent permission models need to ask "what is this principal allowed to do, in what context, for how long, and at what cost?" The unit of analysis changes from identity to execution envelope.
SOC 2 and HIPAA auditors are increasingly asking about AI agent access controls. The questions they ask are good ones: Who authorized this agent's access? What can it read? Can you show us the access log? How do you prevent one agent from accessing data it's not supposed to?
Teams that have tried to answer these questions using traditional IAM documentation quickly discover the gap. IAM roles don't capture the full picture. Agent-specific permission manifests, versioned and auditable, are what compliance reviewers are moving toward requiring.
Building that infrastructure now — before the auditors ask — is a defensible choice.
Agent Enclosure gives you an enclosure manifest that captures exactly what each agent is allowed to do — and enforces it at runtime.
Request early access