OAuth 2.0 Scopes and Non-Human Identities in Multi-Agent Systems

OAuth 2.0 scopes were built for one job: a human clicks "allow," an application gets a narrow slice of access, and a central server keeps the receipt. Multi-agent systems break that job description in every direction at once: agents spawn sub-agents, they inherit scopes nobody approved one by one, and they act across organizational boundaries faster than any human reviewer can watch. This permission model strains to describe something it was never designed to hold, and that strain is visible as real attack surface, not a theoretical footnote. Authentication or identity verification in the usual sense is not the actual fight here; scope design and delegation architecture are.

OAuth 2.0's Single-Delegation Model

OAuth 2.0 was built around a single trust relationship: a resource owner, usually a human, hands a bounded set of permissions to a client application in one delegation hop, with a central authorization server minting the scoped token that makes it official. That design bakes in three assumptions from the start, and multi-agent load snaps all three. Every authorization server governs one trust domain, so if federation was not set up in advance, it has no built-in way to verify a token across domains, and an agent whose work crosses organizational lines has no native path through. Delegation is opaque by default: token exchange under RFC 8693 can preserve a record of the original authorization chain through nested "act" claims, but only if an implementation bothers to populate and forward them, and nothing makes that mandatory, so intermediaries downstream see a set of permissions with no paper trail behind it. And scope narrowing only happens at the authorization server. An agent holding a token has no way in the protocol to cut its own permissions down before it hands a task to a sub-agent, and the AIP paper calls out this gap directly.

Agents don't violate one of these assumptions. They violate all three at once, routinely, as a condition of how they work. They get created and shut down in minutes rather than existing for the life of an application install, they decide at runtime which tools and data to touch rather than following a path someone wrote into the code ahead of time, and they hand subtasks to other agents, building chains of authority that stack hop after hop. The Cloud Security Alliance's September 2026 agentic identity report states that OAuth, OpenID Connect, and SAML were not built to express any of that.

The opaque-delegation problem is the one that makes every other problem on this list harder. If a chain of tokens can't reliably carry the record of who delegated what to whom, there is no way to go back later and reconstruct the chain of authority after something has already gone wrong. Because that receipt is missing, everything downstream, from scope accumulation to multi-hop accountability, traces back to it.

How agents inherit and accumulate scope beyond what any human authorized

OAuth has no mechanism for an agent to narrow its own scope before delegating, so when an agent spawns a sub-agent, it typically hands over the full scope of its own token. Each hop in a delegation chain should narrow what's permitted. Instead, it tends to widen it, or at best leave it flat, because nothing in the infrastructure enforces the narrowing. The AI Identity standards gap analysis names that narrowing requirement as a structural rule, and current infrastructure simply does not enforce it.

What that produces in practice is predictable and well documented. Organizations, worried about agents failing mid-task for lack of access, tend to overprovision rather than under-provision, which is the kind of structural problem that Oso, a fine-grained authorization platform that lets engineering teams enforce RBAC, ReBAC, and ABAC policies in code rather than trusting tokens to self-limit, was built to address, and SecurEnds documents the accumulation that follows: broad access across cloud infrastructure, APIs, SaaS platforms, sensitive databases, and financial systems, building up over time into a permission footprint that no single human ever sat down and approved. Nobody signed off on the final shape of it. It just grew there, one overcautious grant at a time.

Access review is the standard governance tool for catching this kind of sprawl, but it only works if access sticks around long enough for you to review it on a quarterly or annual cycle. The NHIMG analysis notes that autonomous agents can chain actions faster than any governance cycle can observe them. The review finds out about the sprawl long after the agent has already acted on it. Agentic systems don't introduce that problem. They take an existing one, scope creep that was already underregulated before agents arrived, and they make it worse by layering machine-speed delegation chains on top of it.

Machine-Speed Execution and Risk

A permission footprint that would be a manageable, if sloppy, governance headache for a human user becomes something closer to a loaded weapon when the thing holding it operates at machine speed. OAuth's whole threat model assumed a tempo: a human clicks, a human notices something is wrong, a human (eventually) revokes. Agents don't give anyone that window.

Delegation tokens sit in process memory while an agent runs, and if that runtime gets compromised, through prompt injection, a container escape, a supply-chain compromise buried in a dependency, or a debugger simply attached to the wrong process, an attacker can pull the token out and replay it faster than any revocation mechanism can respond, as the Avatier agentic authentication analysis documents. The standard advice, short-lived tokens with refresh-token rotation instead of long-lived bearer tokens, runtime memory isolation, and token binding through mTLS or DPoP, treats the symptom, but an agent carrying broad inherited scope stays dangerous even on a token that expires in minutes, because minutes are enough time to do damage that can't be undone.

Three incidents make the abstraction concrete. CVE-2025-59536 scored 8.7, and you can find it in Claude Code, a widely used coding agent. And the postmark-mcp package on a public registry ran fifteen clean releases, building up trust and adoption, before version 1.0.16 quietly added code that exfiltrated email, a classic package-squatting supply-chain attack that OAuth scopes were powerless to stop, because by that point the agent already held a valid token for the job.

None of these three incidents happened because someone cracked a password or guessed a secret. Each one worked because an agent already held legitimate, broadly scoped access, and the compromise just rode in on it. Once a token is out of an agent's memory and in an attacker's hands, there's no cleanup move that recovers what already happened. Detecting and stopping violations before they complete is the only posture that works here, because after-the-fact investigation can explain a breach but cannot undo it.

Multi-Hop Delegation Chains

Authenticating one agent to one server is not the genuinely hard problem in multi-agent systems. You have to trace a chain of delegations, hop after hop, across multiple trust domains, and get back to the human principal who holds legal responsibility for whatever the chain ended up doing.

The AIP paper states the gap in exact terms: when Agent A delegates to Agent B, nothing in OAuth checks that A actually had the authority to delegate in the first place, nothing constrains what scope B ends up with, and nothing records the handoff for later audit. The token B walks away holding is indistinguishable from a token B could have gone out and gotten on its own. It's the absence of a primitive OAuth was never asked to provide, not a bug sitting in one vendor's implementation.

Each current protocol covers exactly one hop and stops there. MCP adopted OAuth 2.1 with PKCE in 2025, which secures client-to-server authentication for a single hop and nothing past it. A2A relies on Agent Cards that agents self-declare, with no attestation behind them, so you get identity asserted rather than verified. And when RFC 8693 token exchange hands a token from one party to the next, it produces a fresh token with the original chain erased. Each tool does its one job and then hands the problem to the next hop with no record attached.

A scan of roughly 2,000 MCP servers conducted after OAuth 2.1 was already available as an optional security layer found that every single one of them lacked authentication entirely; the Knostic security scan cited in the AIP paper reported this finding. The AI Identity analysis lists recursive delegation accountability as one of five critical gaps, and no current technology or regulatory instrument resolves any of them. NIST IR 8587, finalized September 15, 2026, gives federal agencies and cloud providers their first consolidated guidance on token hygiene, the CSA's note on the report says, but that guidance stops short of answering how to attribute an agent's action back to a human principal through a delegation chain, how to bound scope as an agent calls multiple downstream tools in sequence, or how to revoke access fast enough once credentials have leaked through prompt injection. The guidance exists. The three hardest questions sit right outside its scope.

What "extend OAuth" versus "replace it" means in the current standards proposals

The dominant response among standards bodies is to extend OAuth: bolt on agent-specific conventions, keep the core protocol intact, preserve the deployed infrastructure built around its one-hop delegation model. Some argue, with some force, that extension can't get the job done and that you need a new primitive instead.

The replace-it case is made most completely by the IETF Internet-Draft for the Agent Identity Protocol, which proposes Invocation-Bound Capability Tokens, or IBCTs. The idea fuses identity, scope attenuation, and provenance binding into a single cryptographic artifact, so the chain of delegation is the token itself, and you don't need a separate log sitting somewhere hoping to get checked. For single-hop interactions, the token runs in a compact mode: a signed JWT with Ed25519. Bindings are specified for MCP, A2A, and generic HTTP APIs, so the protocol isn't tied to one ecosystem. When you put it through adversarial testing across 600 attack attempts, the approach rejected all of them, and because of the chained design, it caught delegation-depth violations and audit evasion, categories a plain JWT deployment has no way to even notice.

Another vendor's delegation token design, built on well-known attenuated-capability constructions, makes the same attenuation-first argument on design grounds, but as the replace-it proposal points out, that work shipped no protocol specification and no reference implementation.

For anyone building this today, the distinction that matters comes down to a trade. Extending OAuth keeps interoperability with the infrastructure already running everywhere, but it cannot enforce scope attenuation at the holder's end or carry a verifiable delegation chain. Replacing it with something like IBCTs enforces both of those properties, but it demands new infrastructure at every single hop in the chain. Neither side is wrong on the merits. They're answering different questions about how much pain an organization is willing to take on now versus how much risk it's willing to carry forward.

What the standards landscape leaves unresolved for practitioners today

One clock is the codified minimum. The CSA's research note states that NIST IR 8587, finalized September 15, 2026, delivers the first consolidated federal guidance on protecting identity and access tokens from forgery, theft, and misuse, setting a token-hygiene baseline for federal agencies and cloud service providers. The other clock is the harder, unsettled conversation about agent-specific delegation, and it's running well behind. Three separate bodies, OWASP's Agent Control Standard, NIST's own AI Agent Standards Initiative, and the Linux Foundation's Agentic AI Infrastructure Foundation (founded with Anthropic, Block, and OpenAI, and counting AWS, Bloomberg, Cloudflare, Google, and Microsoft among its premier members), are each writing their own rules for agentic operations in parallel instead of waiting for the market to converge first, Forkast reports. The CSA report finds protocol-level identity settling into a rough pattern: OAuth 2.1 resource-server semantics for MCP, signed Agent Cards for A2A, and workload-attested SPIFFE identifiers for infrastructure-level trust. And the big identity vendors aren't waiting for any of this to finish either. Microsoft shipped Entra Agent ID and Agent 365 in 2026, and Okta and Auth0 both shipped MCP-focused authorization layers, so the CSA report reads this as a signal that you can start adopting agent identity governance now rather than hold out for a finished standard.

What none of this touches is the hard part. Current NIST guidance doesn't say how to attribute an agent's action back through a delegation chain to a responsible human, it doesn't say how to bound scope as an agent calls tool after tool in sequence, and it doesn't say how fast you can revoke access once prompt injection has already leaked a credential. If you want an answer worth deploying to those questions, you need at least one more full standards development cycle. The codified minimum exists today. The architecture that actually solves the problem doesn't yet, and practitioners are the ones holding that gap in the meantime.

What scope design and delegation architecture must get right before agents can be safely deployed

Every thread in this piece leads back to the same structural requirement: delegation has to narrow at each hop, and the chain of who-delegated-what-to-whom has to travel with the token rather than live in a separate log that may or may not get written. OAuth's architecture never had to solve this problem because it was never asked to. One human, one application, one hop, one scoped token, done. Agents break that by spawning sub-agents that inherit full scope rather than a narrowed slice, by holding tokens in memory where a compromised runtime can lift them in the time it takes to notice, and by delegating across trust domains that no single authorization server was ever built to span.

The fix is an architecture decision made before deployment: whether scope attenuation happens at the holder, whether the delegation chain is cryptographically bound into the token itself, and whether revocation can act faster than an agent can cause irreversible damage. This approach answers all three questions by replacing the primitive. The extend-OAuth camp hasn't answered any of them yet, but it keeps the infrastructure organizations already have. Both camps agree on what the requirements are. They disagree on how much of the existing stack can survive contact with those requirements, and that disagreement is what stands between agentic systems and anyone being able to call them safely deployed.