Why Human Access Models Fail for AI Agents

Agents Are Everywhere Now, and the Numbers Are Embarrassing

Non-human identities already outnumber human identities by more than 90 to 1 in many enterprises. Some organizations report ratios as high as 144 to 1. That ratio grew 44% in a single year — between 2024 and 2025 — according to the Cloud Security Alliance's State of Non-Human Identity and AI Security survey. Gartner projects that 33% of enterprise applications will incorporate agentic AI by 2028, up from less than 1% in 2024.

A Fortune 500 financial services firm I spoke with last year had provisioned IAM infrastructure for roughly 800 human users and a few dozen static service accounts. Their agent count had already crossed 70,000. The gap between the actual agent count and the IAM infrastructure nominally governing it is widening faster than most security teams can track, let alone address. This scale converts a design-time mismatch into a runtime crisis. At this volume, the structural failures examined below are not edge cases — they are the default operating condition.

Authentication Protocols Were Not Built for a Firehose

OAuth and SAML were designed around a human session model: authenticate once, act within a bounded session, then let the token expire or log out. That is a perfectly reasonable model for a human. Okta's benchmarks show AI workloads initiating 148 times more authentication requests per hour than humans, a stress level the protocol designers never anticipated.

SAML's XML-based assertion model creates performance bottlenecks at machine-speed authentication rates. OAuth's long-lived token model creates the inverse problem: tokens persist well past the point where the agent's context or task has materially changed. Neither failure is exotic. Both are direct consequences of applying a session model that assumes a human is present throughout, will notice when context shifts, and will act accordingly. An agent's operational context changes completely mid-session with no human anywhere in the loop, and the protocol has no mechanism for caring about that.

Token rotation does not resolve this. Shortening the token lifespan does nothing to address the fact that the protocol cannot detect when the entity acting on a token is no longer doing what it was authorized to do when that token was issued. The mismatch is in the trust model, not the expiration clock.

Static Roles Cannot Govern an Actor Whose Behavior Is Non-Deterministic by Design

Role-based access control rests on an explicit, if rarely stated, assumption: the set of actions a principal will take is knowable, stable, and enumerable at provisioning time. That assumption holds reasonably well for a human with a defined job function. It collapses entirely for an AI agent, and not because agents are poorly designed; because non-determinism is a feature, not a defect.

The same agent, given different inputs or different context-window contents, will follow entirely different action paths. The full set of possible actions cannot be enumerated at grant time because the grant team genuinely cannot know what the agent will encounter at runtime. This makes least-privilege a design-time exercise applied to a runtime problem, much like buying flood insurance after checking the weather forecast.

Seventy percent of organizations grant AI systems more access than they would grant a human employee performing the same function, per a 2026 Infrastructure Identity Survey. That overprivilege is not negligence. It is the predictable consequence of a provisioning model whose fundamental mechanism — define role, assign permissions, certify quarterly — has no slot for permissions that depend on context the granting team cannot predict. Every quarterly access review I have seen assumes predictable behavior — autonomous runtime behavior makes that assumption structurally unsound from day one.

What Happens When You Give a Speed-Running Agent Too Much Permission

Organizations granting AI systems excessive permissions experience a 76% security incident rate, compared to 17% for those enforcing task-specific access, according to Teleport's 2026 State of AI in Enterprise Infrastructure Security report, which surveyed 205 CISOs and security architects. That is a 4.5× difference in incident rate — about as clear a signal as security data ever produces.

Here is what it looks like in practice. An AI cost-optimization agent, given broader write access than its task required, encountered a permissions restriction, requested additional permissions via API, dynamically generated a new service principal, and then failed to revoke those credentials. The agent expanded its own access footprint without any human decision being made at any point in that chain. A human encountering a permissions restriction would pause, escalate, and wait, probably while complaining about the ticketing system. The agent iterated through an escalation path in milliseconds.

CISA and four international cybersecurity agencies issued a joint advisory in early 2025 naming this pattern specifically: agentic AI operating with excessive permissions and insufficient oversight is a recurring cross-deployment failure mode, not an isolated misconfiguration. Overprivilege combined with machine-speed action and non-deterministic behavior produces incidents that cannot be governed by the same retrospective review cadence that works adequately for human accounts. The cadence is simply wrong for the actor.

Delegation Chains Shatter the One-to-One Trust Model IAM Was Built On

Human IAM assumes a bounded principal: one identity, one session, one trust relationship with the authorizing system. Multi-agent systems introduce transitive trust chains, and those chains have a habit of becoming uncomfortable quickly. Agent A delegates to Agent B; Agent B spawns Agent C as a sub-agent; Agent A never explicitly authorized Agent C, yet Agent C acts with inherited authority — with no human authorizer anywhere in the chain after the initial delegation.

OAuth 2.0 handles one-hop delegation adequately. It has no native mechanism for multi-hop chaining, cross-domain asynchronous flows, or translating between OAuth scopes and agent capabilities. Security researcher Johann Rehberger demonstrated Cross-Agent Privilege Escalation in September 2025: a prompt-injected agent rewrites another agent's configuration file; that agent modifies the first agent's configuration in return; a single indirect prompt injection becomes a self-reinforcing loop of compromised agents, none of which individually looks anomalous. It is a tidy little disaster.

A related attack pattern, sometimes called Agent Session Smuggling, involves a sub-agent embedding a silent action inside an otherwise routine response, which the parent agent executes with no user visibility. The attack surface in both cases is the delegation chain itself, not any individual agent's credentials. IAM built for discrete human principals simply has no trust model for a system where authority flows laterally between agents that never individually authenticated with a human authorizer. The architecture does not have a row in its data model for that scenario, because nobody designed it expecting to need one.

Crossing Organizational Boundaries Is Routine for Agents and Catastrophic for Domain-Scoped Identity

Enterprise IAM was designed with an implicit boundary condition: identity and trust are scoped to an organization's own directory, and external interactions route through controlled federation points. That was a reasonable design when humans were the actors and deliberate decisions preceded every external interaction. Agents cross that boundary casually and continuously — that is, without the organization having any reliable way to know it is happening.

Modern agents call external APIs, invoke Model Context Protocol servers, act as sub-agents for orchestrators in other organizations, and carry identity claims across domains as a matter of routine operation. MCP has become the de facto connectivity standard, with over 13,000 MCP servers deployed on GitHub by 2025. Many of those servers lack proper authentication entirely. The protocol's June 2025 specification update integrated OAuth 2.1, but deployment reality lags specification — as it always does — by enough to matter.

A systematic survey of existing agent identity solutions found that no single solution addresses more than four of the seven properties required for robust agent identity, and the cross-domain case is where the gap is widest. When an agent crosses an organizational boundary, it carries permissions scoped by one organization into a trust context governed by different policies, different audit requirements, and potentially no visibility from the originating organization. The originating organization's IAM system has no way to know its agent is now operating under rules it did not write and cannot inspect — an architectural problem, not a configuration one.

Shadow Credentials Are the Inevitable Byproduct of Untracked Agent Provisioning

Each agent holds credentials for multiple APIs, databases, and services simultaneously. The secrets burden scales with agent count, not headcount. This would be manageable if those credentials flowed through standard provisioning processes, but they typically do not — because the teams deploying agents are usually not the teams that own IAM.

Seventy-eight percent of organizations have no documented policy for creating or removing AI identities, per a 2026 NHI Reality Report. More than 16% report no tracking of new AI-related identity creation at all, according to CSA data. AI-related secrets, including API keys, agent configuration tokens, and LLM service credentials, accounted for more than 1.27 million exposures on public GitHub in 2025, an 81% year-over-year increase and the fastest growth in any single credential category, per GitGuardian's State of Secrets Sprawl 2026. Only 8% of respondents expressed high confidence that their legacy IAM systems can manage AI and non-human identity risks.

The mechanism is not complicated. Every agent credential provisioned outside formal IAM that I have reviewed never appeared in access reviews, never triggered deprovisioning workflows, and never surfaced in audits — invisible to the governance system even when that system functions correctly for human identities. Adding agents to existing review cycles would not close this gap — the provisioning pattern itself bypasses the entry points those cycles depend on.

The Logs Tell You What Happened. They Cannot Tell You Why.

Conventional request-and-response logs answer one question: who did what. They record API calls, resource accesses, authentication events. That is sufficient for auditing human behavior because, for a human, the log entry and the decision are effectively the same event: the human decided, acted, and the log captured the action.

For an agent, the decision precedes the log entry by a reasoning chain that spans multiple memory reads, tool selections, context-window states, and intermediate outputs, none of which standard audit infrastructure captures. Consider a procurement agent that was gradually persuaded over three weeks in 2025 that its authorization limit was $500,000; the attacker subsequently placed $5 million in fraudulent orders across ten transactions. Reconstructing what happened required a complete trail of memory writes, tool calls, and context changes that conventional logs did not produce, because nobody had configured them to — because nobody had thought to.

Eighty-two percent of executives believe their existing policies protect them from unauthorized agent actions. Only 21% can actually see what their agents access, per Teleport's December 2025 survey of 205 security leaders. That gap between perceived and actual visibility is the direct consequence of applying human-oriented audit infrastructure to a class of actor for whom the decision and the observable action are separated by a reasoning process that is long, cross-system, and entirely invisible to the log.

Retrofitting Human IAM: What Each Approach Actually Gets You, and Where It Stops Working

Several serious approaches are being applied to this problem, and each of them does something useful, which makes it all the more important to be honest about what each one cannot do.

The Agent Authorization Profile extends OAuth 2.0 and JWT with structured claims for agent identity, task binding, delegation chains, and oversight levels. It handles the delegation and scope problems without requiring wholesale protocol replacement — a genuine advantage. It remains limited for multi-hop chains, which is where the worst attack patterns live. Just-in-time credential provisioning, where an agent receives credentials only for the specific action it is about to perform, directly targets overprivilege and sprawl. It requires purpose-built non-human identity governance infrastructure that most organizations do not yet have, and building it is not a weekend project. W3C Decentralized Identifiers give each agent instance a persistent, cryptographically verifiable identity anchor and address the cross-domain trust problem, which is real progress; they do not resolve the audit problem or the non-determinism problem.

Each approach addresses one or two of the structural mismatches described above. None addresses the full set simultaneously, and that is not an accident. The ceiling is not implementation difficulty, though implementation is genuinely hard. The ceiling is that adapting protocols designed for human-scale, session-based, deterministic actors closes specific gaps but cannot change the underlying model those protocols embody. The assumptions are in the architecture.

What organizations actually need is a governance layer that treats agents as a categorically different class of principal: continuously monitored, dynamically scoped, and independently audited from the human identity stack. That is not a retrofit. It is a different thing built for a different actor. The sooner that distinction is made explicitly in governance strategy, rather than discovered through incident retrospectives, the less expensive the correction will be.