Summary

  • The IETF announced a 28 September 2026 OAuth Working Group virtual interim with the agenda “Anthropic & OpenAI Agentic Use Cases.” That is a scheduled discussion, not evidence that either company supports a particular draft or that the group has adopted a solution.
  • OAuth already supports fine-grained authority and sender-constrained tokens. The residual failure begins when a model generates the concrete tool call: the same untrusted arguments must not define both the proposed act and their own permission. Bind an independent decision to the finalized parameters, verify and consume it at the first effective sink, then record execution and outcome separately.

The access token can be perfectly valid while the bank account is wrong.

That sentence describes a narrower failure than token theft. The client may be the expected client. Its key may prove possession. The token may name the correct payment API and allow the correct operation. Yet a poisoned document, compromised retrieval result or model error can replace the beneficiary while leaving every upstream credential intact. The system calls an authorized tool with an unauthorized argument.

The IETF meeting announcement gives this problem a timely standards venue. The OAuth Working Group will hold a virtual interim on 28 September, from 17:00 to 18:00 UTC. Its entire published agenda is “Anthropic & OpenAI Agentic Use Cases.” The wording proves a meeting and a subject. It does not say what either company will present, endorse or implement. It does not make a mailing-list proposal a working-group item.

The institutional distinction is especially important here because several ideas are moving at once. The OAuth charter defines the protocol as delegation: a user can grant a third-party application limited access without sharing long-term credentials or even identity. That mandate includes an extensive standards base. Agentic systems do not arrive in an empty security landscape.

RFC 9396, Rich Authorization Requests, can carry structured authorization_details. Its canonical payment example includes an amount and creditor. If the user already knows the merchant, EUR 123.50 and the destination account, the authorization server can approve those values and the resource server can reject a different POST. That is exact, useful authority. Calling OAuth intrinsically coarse would be false.

RFC 9449 adds Demonstrating Proof of Possession. DPoP sender-constrains a token to a key and makes stolen-token replay easier to detect. It answers “is this presenter holding the expected key?” It does not answer “did the principal authorize this newly generated beneficiary?” A legitimate key-holder can still submit the wrong act.

RFC 8693 lets an OAuth authorization server exchange security tokens and represent delegation or impersonation. In a multi-agent chain, that can preserve who acts for whom and narrow access for a downstream party. The chain can nevertheless faithfully carry authority to the wrong final parameters. Provenance of the actor and legitimacy of the act are related, not interchangeable.

The remaining gap appears after authority exists but before consequence. A 1 September OAuth/WIMSE thread asked whether a grant could bind to the exact tool name and arguments emitted by a model rather than merely a class of calls. The initiating message contrasted DPoP, RAR and other scoping work with a prompt-injected agent that holds a valid token yet supplies attacker-controlled arguments.

The most useful correction in the subsequent exchange about RAR is that the issue is not expressive power. RAR can describe exact values. The issue is who makes those values authoritative. When the model emits {tool, arguments} and the host simply copies that object into a fine-grained request, the same untrusted output has described the act and nominated itself for approval. A more detailed envelope has not created an independent decision.

An authorization source has to stand outside that loop. It might be a human-confirmed mandate, an enterprise policy with a versioned rule set, a pre-validated purchase order, an inventory state signed by a separate service or an escalation decision. Its test can be automatic. Independence does not mean that a person must click for every call. It means the candidate cannot mint its own permission merely by being well formed.

This becomes obvious when time separates intent from execution. The Chen use-cases draft describes a user asking on Monday for help planning a picnic and receiving an authorization prompt on Tuesday after the agent has chosen a park. The ordinary consent screen may display parks.book and calendar.write while losing the original reason, chosen location and price. The draft calls this context collapse. It also says OAuth need not parse natural-language intent or orchestrate the task. Its concern is whether previously approved constraints and later concrete execution can remain connected.

The Liu operation-authorization draft takes another route. It proposes a structured operation request converted into a JWT without the original natural-language input, followed by a token representing confirmed authorization for a specific operation. The separation is valuable: prose is evidence of what the user said, but it is a poor execution contract until someone converts it into reviewable fields and accepts responsibility for that conversion.

The Yossif mandate problem statement sharpens the temporal problem into T0 and T1. At T0, a principal authorizes constraints. At T1, the agent executes concrete actions while the principal is absent. One authorization may govern thousands of actions, so asking the human again every time destroys the promised autonomy. The desired property is independent verification that a T1 action remains within the T0 mandate. The draft explicitly proposes no protocol behaviour.

None of these documents is an RFC. They are Internet-Drafts: work in progress that may change, expire or be replaced. The meeting notice does not promote them. Their value for leadership is diagnostic. They expose four questions that dashboards often compress into one green “authorized” light:

  1. What authority did the principal delegate?
  2. Who or what approved this concrete act under that authority?
  3. Where was the approved act compared with the last live values before effect?
  4. What happened in the external system?

The binding between questions two and three needs deterministic bytes. Tool arguments can have different key order, numeric forms, encodings or defaults while expressing the same—or a materially different—act. The host must select a canonicalization method, version it and compute a digest over every load-bearing field: tool identity, destination, amount, account, object identifier, consequence class and any live state that can change the effect.

But the digest is only a commitment. It proves that the bytes presented later match the bytes considered earlier. If the model supplies a malicious beneficiary and the host hashes it, the hash faithfully preserves the malicious beneficiary. Cryptography can freeze a decision; it cannot supply the missing principal.

The Das tool-binding draft offers one concrete profile for this boundary. It would hold the model’s tool block as a non-effective candidate act, canonicalize the arguments, validate, commit evidence, issue scoped authority, verify and consume that authority at the dispatch sink, and only then call the tool. This is an individual informational draft with an intellectual-property note, not an IETF-selected architecture. Its useful contribution is the placement test: tool_use is not invoke().

Placement decides whether the control is real. For an HTTP API, the resource server may be the first system able to move money or alter infrastructure. For a local function, the host’s function map is already the sink. For computer use, the browser controller can create the external effect before any OAuth-aware downstream service sees it. For MCP, enforcing only on one cooperative server leaves other client routes open. Every path holding effective credentials must meet the same gate, or the unguarded path becomes the product.

The mailing-list follow-up phrases the possible rule as refusing to invoke a tool sink unless the finalized parameter digest matches an authorized policy assertion. That is a participant’s formulation, not binding standards language. It nevertheless captures three operational requirements: compare the live act, verify that the authority is current and intended for this sink, and consume single-use authority before the effect so concurrent or replayed calls cannot reuse it.

Consumption creates a hard recovery question. Suppose the gate marks an authority used and the process crashes before the downstream call. A blind retry risks duplicating an irreversible action; refusing every retry risks losing one. The system needs an idempotency identity shared with the effecting service, a reconciliation state and a receipt that distinguishes “authorized,” “submitted,” “accepted,” “committed” and “observed.” An HTTP 200 is not a business outcome, and a timeout is not proof that nothing happened.

The same separation protects against success theatre. A scheduling tool may accept an event while the calendar later rejects a participant. A cloud tool may return a job ID before the control-plane change propagates. A messaging API may queue a message that policy later suppresses. Leadership needs the final state and, where possible, the user-visible consequence—not only the agent transcript or provider response.

The smallest defensible receipt chain begins before the model. Preserve the principal or policy identity, versioned mandate, task context and any approved limits. At proposal time, record the candidate tool, consequence class, canonicalization version and finalized argument digest. At authorization, record the independent basis, issuer, audience, expiry and sender constraint. At the sink, record the live digest, destination, replay check and atomic consumption. Afterward, record the downstream response, durable state, compensation and user-visible result.

Those records also define revocation. Revoking a reusable token does not explain which candidate acts were already approved, which single-use authorities were consumed, which calls are in flight or which effects must be reversed. Task cancellation needs a mapping from the principal’s mandate to derived authorities and effective receipts. Otherwise “cancel the task” is a UI promise without a causal chain.

Heng Lu’s minimum-initial-specification principle suggests restraint in standardization. A common format may need only enough structure for independent systems to identify the mandate, act, binding, sink and receipt. Local policy can decide which actions require fresh approval, which risks permit standing authority and which evidence is retained. Making every organizational decision part of one global authorization protocol would create a new chokepoint.

His reality-layers argument supplies the stricter warning. A token is a protocol fact. A policy assertion is an authorization fact. A dispatch receipt is an implementation fact. An external state change is an operational fact. A user’s completed objective is an outcome fact. Each may support the next; none should impersonate it.

Running-code primacy then tells leadership where to test. Do not ask only whether the authorization object is elegant. Inject an altered beneficiary after approval. Change a browser field after the screenshot. race two calls against one authority. Bypass the wrapper through a legacy client. Kill the host after consumption. If any path can produce the effect without a matching receipt—or if the approved bytes differ from the live ones—the system has authorization language, not authorization control.

The September meeting could decide that OAuth should carry more of this binding, that host and resource implementations own it, or that existing work is sufficient when assembled correctly. Any of those is a legitimate standards outcome. The wrong outcome would be to treat possession of a well-scoped token as the end of the authority question. For an agent, it is often the beginning.

Sources