AI agent access control: where enterprise IAM breaks down

AI agent access control fails on current enterprise IAM because the architecture assumes sessions with clear boundaries and identities with stable permissions. Agents operate on neither basis. They sustain state across hours, delegate tasks through chains of sub-agents, and change their permission requirements with every step of a workflow.

The scale of the problem is already here

57.3% of engineering teams are running agents in production as of 2026, and Gartner projects that 40% of enterprise applications will embed task-specific agents by end of year, up from under 5% in 2025. The identity infrastructure those agents are running on was not designed for them.

The numbers on the security side are blunt. Only 18% of security leaders report high confidence that their current identity systems can handle agent identities effectively, and only 23% of organisations have a formal, enterprise-wide strategy for agent identity management. Those two figures together describe a deployment pattern that has run ahead of the governance architecture supporting it.

This is not a prediction about future risk. Klarna’s AI agent now handles two-thirds of customer service inquiries, saving an estimated $60 million annually and delivering response times 82% faster than human agents. JPMorgan Chase has over 450 AI use cases in production and is extending agent runtimes from minutes to one to two hours to support autonomous back-office work. These are not pilots. The agents are already acting, already calling APIs, already reading and writing data. The identity question is not hypothetical.

Three ways human IAM assumptions break for agents

Assumption 1: sessions have a beginning and an end

Human IAM is built around the session. A user authenticates, receives a token, performs actions, and the session expires. The identity system only needs to verify the user at the point of login and can treat everything within the session as implicitly authorized.

Agents do not work this way. A single agent handling a legal document review at a firm like Thomson Reuters, where CoCounsel autonomously queries 150 years of case law across thousands of domain specialists, may hold multiple tool connections open simultaneously, spawn sub-agents to handle parallel lookups, and sustain that state across hours rather than minutes. There is no clean session boundary to enforce policy against. The moment you try to map that to a session token with a standard expiry, you are either blocking legitimate work or leaving the credential alive far longer than is safe.

The session model also fails in multi-agent systems, where a coordinating agent delegates tasks to specialist sub-agents. Each hop in that chain needs its own verifiable identity and scope. A single inherited session token passed down through the chain means a compromised sub-agent carries the full authority of the orchestrator.

Assumption 2: permissions are attached to the identity

In role-based or attribute-based access control, you assign permissions to a user or role, and that assignment travels with the identity wherever it goes. This works when the entity using the permission is a human with stable intent and a clear job function.

An agent’s effective permission requirement changes with every task. The same coding agent at Doctolib that needs read access to a test suite at one moment may need write access to a deployment pipeline at the next. With 600 engineers using agents continuously and features shipping 40% faster, the agent’s access requirements are not stable across a workday. If you provision that agent with the union of all permissions it might ever need, you have created an over-privileged principal that can do significant damage if manipulated. If you provision it narrowly, you create constant friction that breaks the automation.

The deeper problem is that permission sets attached to an identity say nothing about the context of use. An agent with read access to the payments database has that access whether it is performing a legitimate reconciliation or has been tricked through prompt injection into exfiltrating records. The identity system cannot tell the difference because it was not designed to evaluate intent, only identity.

For a detailed comparison of how RBAC and ABAC apply differently to agent workloads, that link covers the tradeoffs in depth.

Assumption 3: the principal is a human with accountable judgment

Human access control assumes that behind the credential is a person who can be held accountable, who exercises judgment, and who will notice when something looks wrong. Audits, access reviews, and least-privilege policies all rest on that assumption.

Agents do not exercise that kind of judgment by default. An agent that has been given a tool and a task will use the tool. If the task description has been manipulated, if the context it is operating in has been poisoned, or if its instruction chain has been compromised somewhere upstream, it will still use the tool. It will do so confidently and at machine speed. The accountability model breaks because the agent cannot be sanctioned, does not notice the anomaly, and does not pause to verify.

This is why AI agents security requires structural controls at the infrastructure level, not just policy documents and post-hoc audit logs.

What the replacement architecture looks like

The gap is not filled by adding more roles to your existing IAM system. It is filled by introducing runtime context coordination as a first-class component of your access model.

flowchart TD
    A[Agent receives task] --> B[Task metadata extracted\nintent, scope, duration]
    B --> C[Context broker evaluates\nagainst policy]
    C --> D{Policy allows?}
    D -- Yes --> E[Scoped credential issued\nfor this task only]
    D -- No --> F[Request denied\nor escalated to human]
    E --> G[Agent executes action]
    G --> H[Action logged with\nfull context]
    H --> I[Credential expires\nor revoked on completion]
    F --> J[Human reviews\nand approves or rejects]

Runtime context coordination

Instead of assigning permissions to an identity and trusting that identity indefinitely, the runtime context coordination model issues access based on three things evaluated at the moment of each action: the agent’s verified identity, the task it is currently performing, and the context in which that task was initiated.

The context includes: who delegated the task, through what chain of instructions, at what time, against what data sources, and with what expected scope. A policy engine evaluates the combination and issues a scoped, short-lived credential for that specific action. When the action completes, the credential expires. If the context does not match the policy, the action is blocked and, depending on configuration, escalated to a human reviewer.

This model pairs naturally with AI agent governance frameworks that define what legitimate task contexts look like for each agent role, and with agent observability tooling that captures the full execution trace for audit.

Intent-based access control

Intent-based access adds a layer above authorization. Instead of asking only “does this identity have permission for this action,” the policy engine also asks “is this action consistent with the declared purpose of this agent’s current task.”

The practical implementation requires agents to carry a structured task declaration: a machine-readable statement of what they are trying to accomplish, issued by the system that initiated them and cryptographically bound to their session. When an agent calls a tool, the access control layer checks whether that tool call is within the declared scope. A legal research agent declaring intent to retrieve case law should not be calling the billing API. That discrepancy is blockable at the infrastructure layer without relying on the agent to notice it.

This is the architectural response to the prompt injection risk that sits at the center of most agent security concerns. See the guide on adopting an AI security framework for how intent-based controls fit into a broader security posture.

Decision verification for high-consequence actions

For actions above a defined consequence threshold, writing to a production database, initiating a financial transaction, modifying access controls, runtime context coordination should require a verification step before execution.

flowchart TD
    A[Agent proposes action] --> B{Consequence score\nabove threshold?}
    B -- No --> C[Execute with logging]
    B -- Yes --> D[Action queued\nfor verification]
    D --> E{Verification mode}
    E -- Automated --> F[Second agent or\nrule-based check]
    E -- Human --> G[Human reviewer\nnotified]
    F --> H{Check passes?}
    G --> I{Human approves?}
    H -- Yes --> C
    H -- No --> J[Block and alert]
    I -- Yes --> C
    I -- No --> J

eSentire’s cybersecurity agent compresses threat analysis from five hours to seven minutes with 95% alignment with senior experts. That speed is valuable. But when the agent’s recommended action is to isolate a segment of network infrastructure, that is a consequence-threshold action. The architecture should require a verification step, either automated cross-check against a second policy engine or escalation to a human, before the action executes. The agent’s speed advantage is preserved for the analysis; the human’s judgment is preserved for the irreversible action.

The guide on runtime governance versus pre-deployment review covers where to draw that line for your specific deployment context.

Putting it together: identity architecture decisions you need to make now

The transition from human IAM to an agent-capable identity architecture involves four concrete decisions.

Decide how agents are enrolled as principals. Agents need verifiable identities issued and managed by your organisation, not inherited from the human account that deployed them. This means a registration process, a credential lifecycle, and a revocation path. Some organisations handle this through certificate authorities; others use dedicated non-human identity platforms. Tools like Prefactor sit in this category, providing agent-specific identity and access management infrastructure. Whichever approach you choose, the requirement is the same: each agent has a unique, auditable identity that is separate from the human identities around it.

Decide what constitutes a valid task declaration. Intent-based access only works if the task declaration format is defined and enforced. Your platform team needs to specify what fields a task declaration must carry, who can issue one, and how it is verified at the access control layer. This decision belongs in your AI governance framework alongside the policies it will enforce.

Decide your consequence threshold. Not every agent action warrants human review. Defining the threshold, by data sensitivity, action type, blast radius, or financial value, is a policy decision that should precede deployment, not follow an incident. Your AI risk governance process is the right home for this.

Decide how you audit. Full context logging at the action level, not just the session level, is required for meaningful audit. That means capturing the task declaration, the credential issued, the tool called, and the result, bound together in a trace that can be reconstructed after the fact. AI governance and compliance requirements in regulated industries will make this non-negotiable; building the logging infrastructure before you need the audit trail is substantially easier than retrofitting it.

For identity architects and security leaders preparing agent infrastructure, the AI security best practices guide covers the technical controls that complement the identity architecture described here.

Where to start

The decisions above require a clear picture of where your current agent deployments sit relative to the architecture you need. Take the agent readiness assessment to identify which of the four structural gaps are most urgent for your organisation, and to get a prioritised view of what to address first.