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

Non-human identities now outnumber human ones by roughly 144 to 1 in cloud-native environments, per Entro Security research, up from 92 to 1 in the first half of 2024. That's a 56% jump in a single year, and it happened before most enterprises figured out what to do with the ratio they already had. OAuth 2.0 scopes are the sharpest tool available for controlling what AI agents can actually do inside that sprawl, but only if scope design, token binding, and delegation chains get treated as engineering work, not paperwork. Most organizations still haven't made that switch. The ones that haven't are the ones that will get burned first, and the burning has already started.

Across all enterprise environments, not just cloud-native ones, the average ratio sits closer to 45 to 1, driven by the usual suspects: cloud adoption, microservices, SaaS integrations that each mint their own service accounts. An analysis of 27 million enterprise NHIs confirms the 144-to-1 figure and adds a worse detail: only 21.9% of organizations treat agents as independent identity principals. The rest run agents on shared API keys (45.6%) or on human credentials built for people, not machines, to hold. That's the structural failure this piece is about. A shared API key is not a security control. It's a group chat where everyone has the same name, and nobody can tell who actually sent the message that deleted the production database.

How OAuth 2.0 scopes function as an authorization boundary for agent NHIs

Strip away the acronyms and OAuth's model is simple. An agent acting as an OAuth client asks an authorization server for a token, hands that token to a resource server, and can only do what the token allows. The agent never decides its own permissions. The authorization server does, at the moment it issues the token, because authority has to live outside the thing being authorized, not inside it.

Scopes are the mechanism that makes this concrete: named permission strings, set at issuance time, that spell out which resources and operations a given token covers. An agent operates under one of three postures depending on how it's built. In delegated user access, the agent acts for a specific person, and its scopes are capped by what that person actually consented to share. In service-level automation, the agent holds its own client credentials, and scopes come from the client registration itself, not from any human's delegated rights. In scoped delegation across services, an agent trades one token for another as it calls downstream APIs, with scopes constrained by what the parent token allowed.

OAuth 2.1, still a draft rather than a ratified RFC, is where the industry is heading regardless. It folds OAuth 2.0 together with PKCE, drops the implicit grant entirely, kills the resource-owner password grant, and makes PKCE mandatory for every client using the authorization-code flow. What this buys the people running the infrastructure is control at the token layer: they can audit, constrain, and revoke access without touching a single line of agent code.

A few disciplines follow from this. Register one client_id per distinct agent role, not one shared credential for a fleet of agents and not a fresh registration for every instance either. Don't pass tokens between agents; each one should get its own token for its own slice of work. Tokens for agents need to be short-lived, because agents run continuously and a long-lived token is just a long-lived door left open for whoever finds it. And revocation needs to be a shutdown habit, not an afterthought: call the revocation endpoint defined in RFC 7009 for every active token when an agent shuts down, and build a process that mops up tokens left behind by instances that crashed or got evicted before they could clean up after themselves.

Done right, this turns an agent from an unpredictable little automation engine into something governed and auditable, with a blast radius someone actually defined on purpose.

Where the standard scope model breaks under multi-agent delegation

The trouble starts once delegation gets long. Picture a chain: a human hands off to Agent A, which calls Agent B, which calls Agent C, which finally calls Service D. Four hops, and at every one of them, the receiving party needs to know exactly what authority the caller is actually holding, not just what it claims to hold.

RFC 8693, Token Exchange, is the current standard for handling this. A client hands over one token and gets back a different one, with narrower scopes or a different token type, and the delegation history gets tracked through nested act claims inside the JWT. It's a reasonable mechanism, but it has documented holes. A draft submitted in August 2025 (draft-oauth-ai-agents-on-behalf-of-user-02) states that RFC 8693 "does not natively support obtaining explicit user consent for an agent via the front channel from the authorization endpoint" and "does not specify how to acquire the subject token, adding complexity to the delegation process." Translation: the standard assumes someone already solved consent and subject-token acquisition. Nobody has.

Three structural gaps follow from that. Cross-domain trust doesn't exist by default, since every trust domain runs its own authorization server, and there's no built-in way to verify a token across domains without pre-arranged federation. Chain opacity is a second gap: once a token exchange happens, the new token carries no record of the original authorization chain, so an intermediary further down the line can't inspect what authority was granted way back at the top. And there's no holder-side scope attenuation. Only the authorization server can narrow a scope at issuance, so an agent holding a token can't voluntarily trim its own permissions before handing it to the next agent in line, even if it wanted to be conservative.

Underneath all of this sits a harder problem. Otsuka et al. call it a nondeterminism problem: a credential can verify what an agent is, but it cannot guarantee what that agent will do. Same model weights, same inputs, different outputs, run to run. Scope boundaries have to be enforced from outside the agent, because trusting the agent's own behavior is trusting a coin that sometimes lands on its edge. Concurrency makes it worse: the same agent role can run as many simultaneous instances, and a scope policy designed with a single instance in mind may not account for the full surface that emerges when many instances operate simultaneously.

The practical fallout: in a chain of agents, an over-scoped token doesn't cause one bad action. It sets off a cascade, hop after hop, before a human notices the first domino fell.

The IETF has several drafts circulating to patch these holes, each carrying the usual expiry clock that comes with draft status. "Attenuating Authorization Tokens for Agentic Delegation Chains" (draft-niyikiza-oauth-attenuating-agent-tokens) goes after the holder-side attenuation gap. "Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange" (draft-mw-oauth-actor-chain) goes after chain opacity. "OAuth Identity and Authorization Chaining Across Domains" (draft-ietf-oauth-identity-chaining), the only one of the four that's an actual working group document rather than an individual submission, targets cross-domain trust. "TLS-Session-Bound Access Tokens for OAuth 2.0" (draft-mw-oauth-tls-session-bound-tokens) targets token binding. None of these is ratified, and anyone waiting for the IETF to finish before shipping has already lost the argument. The gap between what teams building agent systems need right now and what the standards bodies will eventually hand them is wide enough to drive a truck through.

How MCP's OAuth 2.1 mandate turns scope design into an engineering requirement

Model Context Protocol changed the incentive structure here. Its March 2025 spec (version 2025-03-26) made OAuth 2.1 the required authentication standard for remote MCP servers, not a suggestion, and the November 2025 revision (version 2025-11-25) tightened the framework further. That makes MCP the first major agentic protocol to mandate OAuth rather than just gesture at it.

The flow it requires works like this: an unauthenticated agent hits a protected MCP server, gets back a 401 along with Protected Resource Metadata (RFC 9728) pointing at the right authorization server, registers a client if it needs to (via Dynamic Client Registration), and then runs whatever OAuth flow applies. The November 2025 revision hardened several pieces of this. PKCE now has to use the S256 method when a client is technically able to. Resource parameters under RFC 8707, introduced back in the June 2025 revision and carried forward here, are required on every authorization and token request, which binds a token to one specific server's audience and stops a credential minted for one MCP server from getting reused against another. The 401 response itself must carry a properly formatted WWW-Authenticate header pointing where the agent needs to go next.

None of that solves the scope-naming problem, and the spec leaves it wide open on purpose. A single MCP server can expose a read-only analytics query and a write operation on production data side by side. OAuth scopes can gate access to each tool separately, but the spec doesn't prescribe any naming convention for how to do it. So teams invent their own, and inconsistent conventions across servers make it close to impossible to reason about an agent's cumulative privileges once it's touching four or five MCP servers at once. The actual engineering problem hides behind the compliance checkbox, skipped past by most teams because the spec technically says they're done.

Enterprise-Managed Authorization, stable as of June 18, 2026, addresses a related piece of this. It lets an organization provision MCP server access straight from the same identity provider console it already uses for everything else, using an Identity Assertion JWT Authorization Grant to connect organizational identity infrastructure with MCP server access. Okta shipped the first identity-provider implementation of this using its Cross App Access mechanism, with clients including Anthropic's Claude, Claude Code, and Cowork, plus Visual Studio Code, and servers including Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase.

The number that follows makes the whole mandate look aspirational. A Knostic security scan of roughly 2,000 MCP servers (cited in the Prakash AIP paper, March 2026) found every single one lacking authentication entirely. Zero out of two thousand. The spec says OAuth 2.1 is required. The deployed population hasn't gotten the memo, and scope design, however carefully done, can't protect an agent talking to a server that never checked who it was talking to in the first place. The real engineering task isn't "implement OAuth 2.1." It's building a scope taxonomy on purpose, binding every token request to RFC 8707 resource parameters, and deciding in advance what an agent should do when the server on the other end hasn't bothered to authenticate anyone.

What sound scope design actually requires in an agentic deployment

Least privilege functions here as an enforced default, not a value statement. It's the main lever anyone has for controlling blast radius, and it matters more with agents than it ever did with static service accounts, because 97% of NHIs already carry excessive privileges according to Entro Security's 2025 State of Non-Human Identities and Secrets report. Agents get dropped into that already-over-permissioned environment and inherit all of it on day one, before they've made a single call.

Granularity is where this gets solved or doesn't. Read, write, and delete need to be distinguished at the resource level, not the service level. A scope granting write access to an entire service isn't a scope, it's a master key with a different label stuck on it. For MCP deployments specifically, a naming convention needs to exist before the first server gets registered, something like resource:operation, enforced across every server in the deployment, not just the first one someone remembered to think about. Tools with different privilege levels belong behind different scope-gated resources, not lumped under one flat scope string because that was faster to set up on a Tuesday afternoon.

Registration discipline matters just as much. One client_id per distinct agent role, not per instance and not one shared credential across the whole fleet. Every sub-agent in a chain gets its own registration and its own token for its own piece of the work, and nobody passes tokens hand to hand like a relay baton. Dedicated identities are also the only thing that makes an audit log worth reading. Without them, an agent's actions and a user's actions blur together, and figuring out who did what after an incident turns into guesswork dressed up as forensics.

Token lifecycle needs specific handling for agents that run for hours or days at a stretch. Short-lived access tokens should be the default, with refresh handled automatically and never gated on a human clicking anything. On a clean shutdown, the revocation endpoint defined in RFC 7009 should be called for every active token before the process exits. On a crash, an OOM kill, or a forced eviction, a reconciliation job needs to run on restart and clean up whatever tokens the previous instance left dangling.

Delegation chains deserve their own attention. RFC 8693 token exchange is the tool for multi-hop chains, and nested act claims should express the delegation history so a downstream service can actually inspect who authorized what further up the chain. Every exchange is a chance to narrow scope, and a downstream token should never come out broader than the upstream token that spawned it. The latency cost of doing a token exchange at every hop, a real round trip to the authorization server each time, isn't theoretical. It shows up in production, and it belongs in the architecture conversation from the start, not as a surprise during a load test.

Tenant isolation rounds this out. Token scope has to bind to a specific tenant context and an approved set of APIs, because a token that can act across tenants in a multi-tenant deployment is a privilege escalation sitting there waiting for someone to notice it. And revocation needs to work as a real-time control, checked at request time, not something that runs as post-incident cleanup after the damage is already logged.

What runtime monitoring must add where scope boundaries alone fall short

Scopes draw the boundary. They don't tell anyone whether the boundary held. That gap between what an agent is allowed to do and what it actually did is, more or less, the exact gap Otsuka et al. (August 2026) point to when they describe the identity problem in agentic systems as foundational rather than incidental.

The nondeterminism issue shows up again here, this time as a monitoring problem rather than a design one. A correctly scoped token says nothing about whether the agent behind it will behave the same way twice. Same scopes, same agent, different sequence of actions, because the underlying model isn't deterministic. Watching the agent in real time is the only thing that catches that difference. Scope design alone never will.

The confidence numbers back this up. In an industry survey on non-human identity security (818 respondents, June 2024), only 15% of organizations said they felt highly confident in their ability to prevent attacks related to this issue, while 69% said they were concerned about it. Fifteen percent confident against sixty-nine percent worried is not a gap, it's a chasm, and it lines up with the problem described here: scoping a token correctly at issuance feels like security, but it's comfort without evidence unless something is actually watching what the token gets used for afterward.

What monitoring has to surface, and what scope design structurally cannot, starts with anomalous call patterns. An agent that suddenly fires off hundreds of API calls in a few seconds, against a profile that's normally quiet, is doing something its scopes technically permit. The scopes were built to catch a different kind of violation, one about what an agent is allowed to touch, not how fast or how often it touches it. Only something watching the pattern itself can catch that, and nothing about a well-designed scope was ever going to.