OAuth 2.0 Limitations for Non-Human Agent Identities

OAuth 2.0 was built for a person sitting at a browser, clicking "allow" on a consent screen. Every part of the protocol assumes that setup: consent happens live, sessions track a person's presence, and one credential maps to one clear principal. None of that holds anymore. Duct-taping agents onto a system built for humans is how organizations end up with an identity layer that doesn't actually know what's running against it.

Machine identities now outnumber human ones by more than 90 to 1 at many organizations, with some enterprises reporting ratios closer to 144 to 1. IDC projects as many as 1.3 billion AI agents in operation by 2028. Every quarter that passes widens the gap between what OAuth handles and what's actually running against it.

Most organizations are coping in a way that makes the gap worse, not better. Only 21.9% treat agents as their own identity principals, distinct from whatever human or service spun them up. Only 45.6% run agents on shared API keys, and 25.4% use hardcoded credentials baked straight into code. That's duct tape, and the wrong call, because shared keys and hardcoded secrets mean nobody can tell one agent's actions from another's once something breaks. That's duct tape, and it's the wrong call, because shared keys and hardcoded secrets mean nobody can tell one agent's actions from another's once something breaks.

The four properties that make agent identity structurally unlike human identity

Agents are built differently from humans, at a structural level. They're built differently, at a structural level, and bolting a human identity framework onto that structure produces the same failures over and over. An "AI Identity" report from Otsuka, Toyoda, and Leung names four dimensions where agents diverge from humans: substrate, persistence, verifiability, and legal standing. Skipping past any one of these causes the framework to break somewhere predictable.

Start with substrate. Human identity rests on a body: one person, one continuous physical presence. Agent identity rests on model weights, and weights get copied. Running a hundred concurrent instances off the same weights leaves no way to tell them apart unless you bind the agent to specific hardware. OAuth was not designed with that kind of binding in mind.

Persistence works differently too. A person wakes up tomorrow as the same person who went to sleep. Agents don't carry that continuity by default. Many are sessionless, with no memory bridging one interaction to the next, so there's no stable core to anchor a lasting identity to. "The same agent acting over time" is a much shakier idea than it looks on paper.

Verifiability is where it gets uncomfortable. Agents are nondeterministic: feed the same model the same input twice, and it can hand back two different outputs. A credential proving what an agent is says nothing about what it will actually do next. Verifying identity and verifying behavior are separate problems. OAuth was only ever built to solve the first one, for humans, on the assumption that a verified human behaves within some rough, predictable range. Agents break that assumption by design.

Where interactive consent breaks when agents authenticate programmatically

OAuth's Authorization Code flow needs a human in the loop: someone who reads the consent screen, weighs the scopes being requested, and clicks approve or deny. An agent can't do any of that. It authenticates on its own, continuously, and what it's allowed to do can shift minute to minute, long after any human made a decision about it.

Walk through the timeline. A user grants consent once, at T=0. The token issued from that moment might get used hours or days later to authorize actions the user never pictured when they clicked "allow." The agent chains API calls together, triggers actions in situations nobody planned for, and keeps working long after the user closed the laptop and went to bed. Consent covered whatever the user imagined at the moment of the click, and nothing past that. It never covered the chain of calls that followed.

OAuth's model centers on a client that is registered and known before the interaction begins. Agents don't work that way. An agent decides at runtime which tools to call, which sub-agents to spin up, which resources to touch. OAuth models a static identity, and the agent's actual, functional identity, the thing making decisions in the moment, is anything but static.

Coarse OAuth scopes and agents that need moment-to-moment authorization decisions

OAuth scopes are strings written once, at registration: "read:files," "send:email," "admin." They describe a category of access, not what one specific action is trying to accomplish right now. That mismatch is the whole problem.

Broad roles like "administrator" or "finance access" make sense for a human employee whose job stays roughly stable week to week. They make far less sense for an agent, where the right authorization call depends on what the agent is doing at that exact moment, not what box someone checked when the token got issued. The AI Identity report names "semantic intent verification" as one of five critical gaps in current systems: token-based authorization can't confirm that what an agent claims it's about to do lines up with what it actually executes.

The data already shows the scale of over-permissioning. Research found that 73% of secrets held by non-human identities carry more permission than they need, and 1 in 20 non-human identities holds full administrative privileges. That's a standing blast radius, sitting there, waiting for one compromised credential to turn a quiet Tuesday into an incident report.

Bearer tokens as a structural liability in multi-agent pipelines

Bearer tokens run on a simple rule: whoever holds the token gets to use it, no questions asked about how they got it. Fine, when tokens live briefly inside one browser session. A liability, once tokens start moving through a chain of agents calling other agents.

Across the hops in a multi-agent pipeline, bearer tokens propagate between agents, and any one of those tokens can get pulled out through prompt injection or a side channel buried in a tool call. The TLS-Session-Bound Access Tokens draft, discussed in OAuth working group literature, points straight at this problem: multi-hop delegation chains in autonomous, agent-driven systems (built on the Token Exchange protocol, RFC 8693) are a main reason token binding needs to exist. Once a bearer token is stolen, it stays valid, because possessing it is the only check that ever happens.

Scope monotonicity is the principle that should govern these chains: each hop should only narrow permissions, never widen them. Bearer tokens carry no mechanism to enforce that. A sub-agent that inherits a delegated credential can turn around and use it at full scope, well past whatever narrow task it was actually handed. A2A's authentication scheme supports bearer tokens as one option among several, alongside API keys, mTLS, and OpenID Connect, and MCP similarly layered in OAuth 2.1 support. The bearer model carried forward into the wider OAuth ecosystem, and that design choice deserves scrutiny.

The limits of RFC 8693 token exchange verification in a multi-hop agent chain

RFC 8693 Token Exchange is the standard building block behind on-behalf-of flows. A service hands over a token it already holds, trades it for a new one scoped to a different audience, and the delegation gets recorded through an "act" claim. Chain a human to Agent A to Service B, and the whole thing is representable, with act claims nesting inside each other. On paper, that looks solved.

It isn't, and the RFC says so itself. Prior-actor claims are informational. RFC 8693 delegation works point-to-point, one hop checked against the next, but a real multi-hop scenario, agent calls agent calls agent, never produces a single artifact a resource server can check end-to-end and trust.

That gap opens the door to a specific set of failures. Scope explosion lets a chain end up granting more authority than whoever started the delegation ever intended. Attribution loss means the resource server can't trace a request back to whoever first authorized it. Chain depth attacks use deeply nested delegation on purpose, to confuse policy checks along the way. Cross-tenant escape lets a chain slip across tenant boundaries it should never have crossed.

Every one of these traces back to the same root cause. Token exchange verifies a link. It never verifies the chain, and treating a verified link as proof of a verified chain is exactly the mistake that lets these four failures through.

The provenance and attestation gap: why token claims cannot tell you what an agent is

An OAuth token makes one claim: this is agent X, authorized by user Y. That's an identity assertion, and it's the only thing OAuth was ever built to give you. It says nothing about what code is actually running, what model weights produced the behavior in question, or if the agent got altered since someone last reviewed and signed off on it.

That's a provenance question, and OAuth has no answer for provenance. Confirming that the agent invoking a credential is the same agent that got reviewed and approved takes cryptographic build attestation, a different tool.

A2A agent cards make the gap concrete. They carry self-declared identities: the agent states who it is, and nothing in the protocol checks that statement against the actual running instance behind it. MCP took a step toward fixing authorization when it adopted OAuth 2.1 as an optional layer. "Optional" turned out to mean something specific once it hit real deployments. Research into deployed MCP servers found that authentication was broadly absent in practice, even where the spec made it available as an option. Optional in a spec becomes absent in practice, once enough servers ship in a hurry and nobody circles back.

The accountability and audit trail absence in practice for security and platform teams

None of this stays theoretical. A measurable hole in accountability appears in the data. Research from an industry security association found that only 28% of organizations can trace an AI agent's actions back to a human sponsor across all their environments. Every gap covered so far, the delegation chains, the bearer tokens, the unverifiable provenance, lands here.

Picture several agents authenticating through one shared service account, common practice given how many organizations still lean on shared credentials. Individual agent behavior becomes impossible to pull apart. The audit trail shows which account got used. It doesn't show which agent acted, or which human actually authorized the task behind it, and that failure to identify either one is the core difficulty security teams run into when something goes wrong.

The same research found that 92% of respondents said their existing identity and access management tools can't handle the risks that come with AI and non-human identities. Seventy-eight percent admitted there's no formally documented policy for creating or retiring an AI agent's identity. Separate research from Oasis Security found that close to half of organizations had already experienced a compromise tied to a non-human identity, with 66% of those cases turning into a successful attack. That's the baseline now.

Requirements of a functional agent identity model beyond OAuth

OAuth 2.0 doesn't need to get torn out. It needs to stop being asked to do a job nobody designed it for. Consent, scopes, and bearer tokens work fine for authorizing a human sitting at a browser. They don't solve agents spawning agents across trust boundaries, and stretching the same primitives to cover both produced every gap laid out above.

A model that actually holds for agents needs pieces OAuth doesn't supply on its own. Authorization decisions have to get made at the moment of action, based on what the agent is trying to do right then, not what box got checked at registration. Delegation chains need to verify end-to-end as one connected chain, not get stitched together from point-to-point claims that trust each other by convention. Credentials need cryptographic attestation tying them to the specific, unmodified code that actually got reviewed. Audit trails need to survive contact with a shared service account, naming the agent and the human behind a given action rather than the account everyone happened to be using.

That means treating agent identity as its own category, with its own protocols running alongside whatever OAuth already handles well for humans. Organizations still running agents on shared API keys and hardcoded secrets aren't behind on paperwork. They're operating without any identity system for most of what's actually happening across their infrastructure, and no amount of OAuth 2.1 upgrades fixes that on its own. Non-human identities already outnumber human ones by more than 90 to 1 at many organizations. That gap doesn't close by itself.