Your OAuth Intuition Is Right Until It Isn't

Authorization delegation from human to AI agent is the concept sitting at the center of most serious public sector conversations about agentic AI right now. It sounds like it should be familiar, because the shape of the problem is familiar: a user grants software the authority to act on their behalf, within defined limits, against a resource server that enforces those limits. You've been selling this pattern for years. It's OAuth.

Your OAuth intuition is genuinely useful here. The major agent protocols are building on it directly. But there's a structural point where that mental model stops working, and it shows up in specific ways that will come up in your next meeting. If you don't know where the breaks are, you'll say something confidently wrong to a buyer who's trying to decide whether to trust you with their architecture.

Where OAuth still maps

It holds further than you might expect. The MCP authorization specification assigns roles that map directly to OAuth 2.1: the MCP server is the resource server, the MCP client is the OAuth client, an authorization server handles token issuance. PKCE is required for public clients. Access tokens ride in Authorization: Bearer headers. Invalid tokens get 401s. Insufficient scope gets 403s.

This was a deliberate design choice. MCP servers serve multiple clients acting on behalf of different users, and the server needs to know who is asking for what. That's the exact problem OAuth was designed for. API keys can't distinguish between users. Mutual TLS is painful to distribute to desktop apps. OAuth 2.1 was the obvious fit.

Google's A2A protocol supports OAuth 2.0 Authorization Code flow, Client Credentials flow, and Device Code flow. Every A2A agent publishes an Agent Card describing its authentication requirements, discoverable through a well-known endpoint the way OIDC publishes provider configuration. A2A adds agent-specific metadata on top: skills, capabilities, security schemes.

So far, your mental model is carrying weight. You know how scopes work: the issuer sets them, the resource server checks them, the token carries the grant. Consent, scoped access, token lifecycle. All applicable.

That's where the map runs out.

Where the bridge stops bearing weight

OAuth's consent model assumes the client application faithfully represents user intent when requesting authorization, which allows the user to meaningfully evaluate what they're consenting to. An IETF draft calls this the intent-execution separation problem. When an agent dynamically generates workflows, creates sub-agents, and makes authorization decisions during a run, the scope of what might be accessed expands beyond what anyone could have anticipated at consent time.

That gap between intent and execution shows up two ways, and the second one loops back into the first.

The scope problem. OAuth scopes are defined at application registration time by developers who know what the application will do. A calendar app requests calendar.read and calendar.write because that's all it will ever need. The scope set is static because the application's behavior is static, and an agent's behavior is anything but.

The same prompt can produce different tool plans across different runs. An agent asked to "prepare a summary of Q3 pipeline" might query your CRM, pull data from a reporting tool, and hit a shared drive. Run it again and it might also search a Slack channel for context. Tool selection is a runtime decision, not a build-time decision made by a developer. So the scope set at consent time is either too narrow (the agent hits a 403 mid-task and fails) or too broad (you over-authorize by default to avoid failure). Both options are wrong. With traditional OAuth clients, you can enumerate what the application will do. With agents, you can't, because the agent doesn't know yet either.

The specs are aware of this. The MCP specification emphasizes token audience binding via OAuth Resource Indicators (RFC 8707), which prevents an agent from taking a token issued for one resource server and passing it downstream to another. That's a real mitigation — it constrains lateral movement. The scope granted at session start still may not match what the agent actually needs mid-run.

If you want a concrete illustration of why over-scoping matters: in August 2025, attackers compromised OAuth tokens held by Drift, a chatbot from Salesloft embedded on other companies' websites. Those tokens provided access to the Salesforce instances of Drift's customers, including Cloudflare and PagerDuty. The damage scaled directly with the agent's permission set. An agent holding tokens for multiple services is a single point of compromise for all of them. Over-scope the token and you've pre-sized the blast radius.

The consent problem. You know the consent screen. The user sees what the app is requesting, clicks Allow, the authorization code flow completes. That screen works because there's a human at a browser at the moment of delegation.

A 50-step agent loop has no such moment after session start. The agent is chaining tool calls, making decisions, calling APIs, possibly spawning sub-tasks. Pausing for human approval at each step is operationally impossible. But blanket consent at session start means the user approved actions they couldn't have fully anticipated, because the agent hadn't planned them yet.

The practical compromise emerging is a two-tier model: broad consent at session start, supplemented by targeted human approval for high-impact actions only. Auth0 for AI Agents implements this using CIBA (Client-Initiated Backchannel Authentication). The agent runs autonomously until it hits a sensitive operation, then sends an approval request to the user's phone or email. The user approves or denies on a separate device without breaking the agent's execution context. Rich Authorization Requests let the approval prompt carry specifics: "Approve payment of $50.00 to ExampleCorp" rather than a generic "allow access."

Clever, genuinely useful, and incomplete, because someone has to pre-define what counts as a "sensitive operation," and that definition is static while the agent's behavior is not. You're back to the scope problem.

Who is actually authenticated?

The agent's scope can't be fully pre-defined. Fine. So whose authority is the agent exercising when it acts, and how does a downstream resource server know? This question is genuinely unsettled, and you should say so if it comes up. Three architecturally distinct answers are in play, and the field hasn't converged.

User only. The user authenticates and consents. The agent acts under the user's token with no separate identity. This is how most current deployments work. The audit trail can't distinguish between what the user did and what the agent did on the user's behalf, which is a problem that gets worse the more agents you run.

Agent only. The agent authenticates as a workload, typically via SPIFFE credentials at the transport layer. Downstream resources see the agent, not the user. The user's delegation scope isn't cryptographically bound in the token, so the resource server has to trust the agent's claim about who sent it.

Both. The agent has its own workload identity, and the human principal's context is carried alongside it. An IETF draft on Transaction Tokens for Agents defines two contexts within a single token: an actor context (the agent) and a principal context (the human on whose behalf the agent operates). The spec calls this "delegation," which is a generous word for what's actually happening. This dual-identity model is not yet deployed at scale.

The standards community is leaning toward treating agents as workloads and composing human delegation separately in the token's claims. The practitioners are mostly doing neither. An audit of 30 open-source agent projects found 93% using unscoped API keys, with not a single project assigning a cryptographically verifiable identity to each agent instance. That audit comes from a vendor with a product in this space, so treat the specific numbers as directional. The pattern is consistent with what LangChain's own documentation acknowledges: they distinguish between delegated access (user present, agent acts on their behalf) and direct access (no human, agent acts as itself via client credentials), but the framework doesn't enforce the distinction.

There are at least seven active IETF drafts working on OAuth extensions for agents. None have achieved RFC status. A lot of smart people are working on this. They don't agree yet.

What to carry into the room

The per-run token is the key design choice. When the token's lifetime is bound to the run, the blast radius has a natural temporal boundary. That's a different risk profile than a long-lived token with narrow scopes, which can sit around waiting to be compromised.

High-impact actions get selective human approval via backchannel authentication. Token audience binding constrains lateral movement by preventing agents from forwarding credentials to services they weren't scoped for. Revocation is binary and immediate. A kill switch, not a graceful degradation.

When your buyer asks how agent authorization works, start with OAuth. It's the right frame. Then mark the breaks: the agent's behavior isn't deterministic, so scopes can't be pre-defined the way they are for traditional apps. Per-action consent doesn't survive a multi-step workflow. The user can't meaningfully consent to actions the agent hasn't planned yet. All three trace back to the same root: OAuth's consent model assumes the client knows what it's going to do before it asks permission.

If they ask who's authenticated, the honest answer is that the industry is working on "both, at different layers" but hasn't shipped a consensus standard yet. Seven IETF drafts, zero RFCs. That honesty will serve you better than a confident answer that breaks the first time someone checks the spec.