OAuth Solved Agent Access. It Hasn't Solved Agent Authority

OAuth can get an AI agent to the right API with a short-lived, audience-bound token. That was the urgent problem in 2025, and the identity industry has mostly solved it.

The harder problem starts after the token arrives.

An access token can say that a customer authorized an application to reach a travel service. It cannot say: check flights to Stockholm, spend at most ₹35,000, do not purchase without approval, and let a sub-agent search schedules without inheriting the ability to charge the card.

That difference is the identity problem of the agentic era. Access says which principal may reach which resource. Authority says which actor may perform which task, with which arguments, under whose intent, through how many delegation hops.

No adopted standard expresses that full sentence as of August 2026.

MCP got the OAuth architecture right

The Model Context Protocol moved from having no protocol-level authorization in November 2024 to a conventional OAuth resource-server architecture in eighteen months. The current MCP authorization specification requires protected-resource metadata, resource indicators, audience validation, PKCE, and issuer identification. Token passthrough is forbidden.

That is real progress. In particular:

• RFC 9728 lets an MCP server publish which authorization servers protect it.
• RFC 8707 binds the token request to the target resource.
• RFC 9207 helps the client identify which issuer produced the authorization response.
• PKCE protects the authorization code when a public client cannot keep a secret.

These controls close familiar OAuth failures: confused deputies, code interception, token passthrough, cross-resource replay, and issuer mix-up. If you are building an MCP server, implement them. Our guides to MCP authorization and audience-bound MCP tokens cover that layer.

But none of those controls knows why the model chose a tool or whether the tool call still fits the customer's task.

OAuth solved the transport of authority. It has not finished defining the authority agents need.

Agent access and agent authority are different

An agent does not act at the granularity of an OAuth scope. It acts by selecting a tool and supplying arguments.

This is not an argument against OAuth. OAuth is the right substrate. It is an argument that scope=travel.write is not a complete authorization model for an actor that plans its own sequence of calls.

The gap has four parts: task scope, attenuation, attribution, and intent.

Task scope must reach tool arguments

OAuth scopes name classes of access. They work well for permissions such as calendar.read or payments.write. They do not normally constrain a particular invocation.

An agent needs a grant closer to this:

{
  "task": "book approved conference travel",
  "tools": {
    "flights.search": {
      "destination": { "one_of": ["ARN", "BMA"] }
    },
    "flights.purchase": {
      "currency": { "exact": "INR" },
      "amount": { "max": 35000 },
      "approval": "required"
    }
  },
  "max_uses": 20,
  "expires_at": "2026-08-11T18:00:00Z"
}

The important fields are not decorative context for the model. They are constraints evaluated by a server-side policy engine before execution.

RFC 9396 Rich Authorization Requests already provides the right container: structured authorization_details instead of a flat scope string. The current Attenuating Authorization Tokens draft applies that shape to tool names and argument constraints. It even defines how a child constraint must be proven at least as restrictive as its parent.

The catch matters: this is an individual Internet-Draft, not an adopted standard. MCP does not currently define a task-grant object or a standard binding for Rich Authorization Requests.

You can implement task-shaped policy today. You cannot expect another vendor to understand your representation.

Offline attenuation must only remove power

Suppose a travel agent delegates flight search to a specialist sub-agent. The parent can purchase a ticket, but the child only needs to search routes.

Two common implementations both fail least privilege:

1. Pass the parent's token downstream. The child inherits the ability to purchase.
2. Ask the authorization server for a new token at every hop. The server becomes synchronous infrastructure for every planning step and must understand the delegation topology.

Attenuation offers a third model: the token holder derives a child capability that can only be narrower. The child might remove flights.purchase, reduce the expiry, lower the use count, bind a new holder key, and pass the result downstream. It cannot add a tool or increase a limit.

Customer grant
  search + purchase, max ₹35,000, depth 3
        │
        └── Travel agent
              search + purchase, max ₹35,000, depth 2
                    │
                    └── Search sub-agent
                          search only, ARN/BMA, depth 1

Macaroons and capability systems established this property long before LLM agents existed. What is missing is an interoperable OAuth model for deriving and verifying the chain offline.

RFC 8693 Token Exchange can mint a narrower downstream token and represent prior actors with the act claim. It still requires an authorization server exchange. The nested actor history is information in the newly issued token, not a self-verifying chain created by each delegator.

The June 2026 attenuation draft proposes parent hashes, holder keys, maximum depth, monotonic constraint checks, and proof of possession. It is the most concrete proposal we found. It is also early enough that production systems should treat it as research, not a compatibility promise.

Attribution must survive every delegation hop

An audit event that says customer-42 called payments.write loses the actor. An event that says agent-7 called payments.write loses the customer and the delegated authority. Both are incomplete.

Useful attribution needs at least:

• the customer or workforce principal who authorized the task;
• the application that obtained access;
• the named agent and runtime that planned the action;
• every delegated actor in the chain;
• the grant and immutable policy version evaluated;
• the exact tool definition enforced; and
• the resource's execution outcome.

The chain must also resist splicing. If each hop merely reports who acted before it, a receiver has to trust the final issuer's reconstruction. Cryptographic links between parent and child make removal, reordering, and substitution detectable.

This is where agent identity and customer identity meet. The customer remains the authority root for a delegated customer action. The agent is still a distinct actor. Collapsing one into the other makes the log misleading; separating them without a signed relationship makes the log unverifiable.

The correct record preserves both.

Intent binding is the unsolved boundary

Task scope says what an agent may do. Intent binding asks whether this invocation came from the task the customer actually authorized.

That distinction matters because a correctly authenticated and authorized agent can still follow an instruction hidden in untrusted content. In the documented Supabase MCP incident, a support ticket instructed a coding agent to read sensitive integration tokens and post them back into the ticket. The database credentials were valid. The service role behaved as designed. No classical permission boundary stopped the action.

As the incident analysis put it: “No permissions were violated.” The instruction was the attack.

A bearer token contains no cryptographic link to the customer's prompt, the trusted instruction source, or the planning context that produced the tool call. Adding a task_id claim can correlate events, but it does not prove that a model followed only trusted instructions associated with that task.

This is why prompt-injection detection cannot be the authorization boundary. The research paper The Attacker Moves Second evaluated twelve recent prompt-injection defenses and reported that adaptive attacks bypassed most of them at rates above 90%. A probabilistic detector can reduce risk. It cannot decide whether money moves.

There is no adopted standard for intent binding. Worse, it is not clear that hashing a prompt would solve it: agent plans evolve, prompts contain sensitive data, and untrusted content becomes part of the context. The identity industry should be honest about that limit.

Today, the defensible control is architectural: do not let one agent context combine untrusted input, sensitive data, and consequential external action without a deterministic boundary.

Consent screens cannot carry this load

The web trained users to approve a list of scopes once. Agent actions can number in the hundreds, and the risk often depends on arguments or combinations that do not fit in a scope label.

Asking for confirmation before every tool call produces a rubber stamp, not informed consent. Asking once for payments.write gives too much standing authority. Hiding the decision inside the agent gives the requester control over its own authorization.

The better interaction is policy first, approval by exception:

• allow low-risk actions within explicit constraints;
• deny actions outside the task grant;
• require stronger authentication when assurance is stale;
• pause a high-impact action for an attributable approval; and
• bind the approval to the action digest, arguments, policy version, and expiry.

The OpenID Foundation's June 2026 AuthZEN AARP and COAZ drafts are important for exactly this reason. AARP models “not yet” as a real authorization outcome: the agent receives a resumable handle while a prerequisite such as approval, attestation, or risk assessment is satisfied. COAZ applies that pattern to MCP tool authorization.

These are Working Group Drafts, not final specifications. Their core idea is still right: a safe agent must know how to stop, wait, and resume without treating policy friction as an error to route around.

Customer identity becomes an authority issuer

Customer identity platforms have traditionally owned registration, login, recovery, sessions, and consent. Agentic products add another responsibility: translating customer intent into bounded, inspectable authority that software can enforce.

That does not mean the identity provider should read every prompt or authorize every business operation. The resource still owns domain policy. The agent runtime still owns planning. The identity layer should own the durable relationship between:

customer → application → agent → task grant → resource

At minimum, that relationship needs independent revocation. A customer should be able to stop one agent without ending every application session. A product should be able to revoke a task without deleting the customer. A resource should be able to reject a stale grant even when the OAuth access token remains cryptographically valid.

This is the shift from customer authentication to customer-authorized agency.

What you can build safely now

The absence of a final agent-authority standard is not an excuse to return to API keys. Separate the stable foundation from the experimental layer.

Use standards now:

• OAuth authorization code with PKCE for interactive customer delegation;
• RFC 9728 protected-resource metadata for discovery;
• RFC 8707 resource indicators and strict audience validation;
• short-lived access tokens and replay-resistant refresh handling;
• exact issuer and redirect validation; and
• RFC 8693 token exchange where the authorization server mediates a downstream grant.

Model explicitly inside your boundary:

• named agents with an owner or sponsor;
• short-lived task grants that narrow standing authority;
• tool and argument constraints;
• maximum uses, expiry, and revocation;
• deterministic allow, deny, require_approval, and require_step_up decisions;
• approvals bound to exact action digests; and
• audit records that separate principal, application, agent, runtime, policy, and resource.

Do not claim interoperability yet:

• offline attenuating token chains;
• cross-organization recursive delegation;
• cryptographic intent binding;
• universal agent identity claims; or
• a shared industry representation for task authority.

That boundary will move. It has not moved yet.

OAuth got agents to the door. The next identity layer must decide what they are allowed to carry through it.