On 30 August 2026, revision -02 of an Internet-Draft titled OAuth Profile for Delegated AI Agent Authorization published its change list. One line in it describes a boundary most agent deployments are standing on without noticing: the revision "moves audit, budget, policy, events, and credential-vault behavior outside the interoperable core."

Agent authorization is the problem of deciding whether a particular action by a particular agent, on behalf of a particular person, is permitted right now. A credential can carry identity, consent and a resource binding, but it is issued before the agent plans. The decision about a specific call can only be made at the moment the call is attempted. That is the line this draft drew, and it is worth understanding why it was drawn there rather than somewhere more flattering.

A note on standing first, because it changes the document's weight. draft-mishra-oauth-agent-grants-02 is an individual submission, and the IETF Datatracker states plainly that such a document "is not endorsed by the IETF and has no formal standing in the IETF standards process." It is not a standard and should not be cited as one. What makes it worth reading is that the draft became stricter between March and August, and the same revision that made it stricter also made it smaller.

What did the draft give up, and what did it keep?

The March revision, then titled Delegated Agent Authorization Protocol (DAAP), described a far broader stack: cryptographic agent identity using Decentralized Identifiers, a signed JWT grant format with agent-specific claims, "a hash-chained append-only audit trail," "a policy engine for automated authorization decisions," "budget controls for spending limits," and "real-time event streaming."

The August revision keeps the authorization machinery and lets the rest go. What it specifies now is a strict profile of existing mechanisms: pushed authorization requests, PKCE with S256, exact redirect URI matching, resource indicators, resource-bound and sender-constrained JWT access tokens, attenuated delegation via OAuth Token Exchange, and refresh-token rotation. It "defines no new JWT claims or OAuth endpoints." The introduction is blunt about why: dynamic agent instances calling high-impact APIs "do not justify replacing OAuth. They do justify a strict profile that removes unsafe choices."

The single change list that adds those requirements is also the one that removes the rest, and Section 8 names what left. Headed Operational Extensions, it says "the following topics are intentionally outside core conformance" and enumerates tamper-evident audit storage and external witnessing; policy decision points and policy languages; financial budgets and atomic debit ledgers; event streams and webhooks; credential vaults; anomaly detection; and enterprise provisioning and SSO configuration. The scope section repeats it in the other direction: the document "does not standardize agent orchestration, model selection, policy languages, payments, budget ledgers, audit storage APIs, event delivery, credential vaults, SCIM, SSO configuration, or vendor deployment endpoints." The stated reason is not that those things are unimportant — it is that they "require separate specifications and security analysis."

Read that list again. Not a catalogue of nice-to-haves — almost exactly the list of things a security team is handed when it is asked to sign off on an agent fleet.

Why does the boundary fall there?

Because the two halves answer questions at different times, and one of them cannot be answered early.

A token is minted once. At mint time the authorization server knows who the principal is, which client is asking, which resource the token is good for, and which key must be present to use it. Those facts are stable, which is why they compress into a credential well. The draft's security model leans on that stability, and on one distinction worth quoting: "An Agent Client Instance is not trusted merely because a developer registered it or supplied an API key. Developer authentication and Principal authentication are separate security events. A developer credential MUST NOT be accepted as proof that the Principal approved a live authorization request."

That rule exists because the common agent-security failure is a category error rather than a cryptographic one. A service credential in a config file gets treated as standing consent, and every action the agent takes inherits an approval nobody gave.

But the facts that decide whether this call should proceed are not stable at mint time. Whether a delete is acceptable depends on the target; whether a payment is acceptable depends on the amount and on what the agent has already spent this hour; whether a tool is safe depends on whether its description changed since it was reviewed. None of that is knowable when a scope string is written, because the agent has not planned yet.

So the structural answer is not that the token layer is weak. It is that scope is the wrong instrument for a condition evaluated per call. Attenuation is a property of a credential; enforcement is an event, and events need somewhere to happen.

Who else is pointing at the same surface?

Three United States federal workstreams are working the agent-security question in public right now, and each describes itself as still in progress.

The Center for AI Standards and Innovation at NIST published a Request for Information on securing AI agent systems on 12 January 2026, with a comment period that closed on 9 March 2026. Its topic list ends on a bullet that names a surface precisely: "Interventions in deployment environments to address security risks affecting AI agent systems, including methods to constrain and monitor the extent of agent access in the deployment environment." NIST adds that the responses "will inform future work on voluntary guidelines and best practices related to AI agent security."

Alongside it, the NIST National Cybersecurity Center of Excellence has a concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, whose project page carries the status line "SOLICITING COMMENTS" and seeks feedback "to help determine the scope, feasibility, and potential value of the project." And NIST's SP 800-53 Control Overlays for Securing AI Systems project, which says it "will develop a series of overlays for securing AI systems," lists five proposed use cases, two of them agent systems: single-agent and multi-agent.

The guidance, in other words, is being written now. Organisations running agents today are making deployment-environment decisions ahead of the documents that will eventually describe them — an argument for making those decisions deliberately rather than waiting.

What does a defensible record actually require?

One more sentence in Section 8 deserves lifting out, because it is a governance rule disguised as a cryptography note: "An implementation MUST NOT claim that an operator-signed hash chain is operator-independent evidence. Such a claim requires publication to or countersignature by an independent witness."

Translated: a log you sign yourself demonstrates integrity against tampering by third parties, and considerably less against you. For internal security work that is fine. For an external auditor, a regulator or opposing counsel the distinction matters, and a product claiming "tamper-proof" where it means "tamper-evident, signed by us" is claiming more than it can support. Worth putting on the call.

How Waxell handles this

If the decision has to happen at the call, it needs somewhere to happen. For MCP tool calls that place is the Waxell MCP Gateway: one governed MCP endpoint per tenant that agent clients point at instead of configuring upstream servers individually.

The mechanic that matches the argument above is the policy gate. A brokered tools/call is evaluated against the tenant's rules before the upstream sees it, and the result is evaluated again on the way back. Rules match on upstream, tool glob, user, role, team and — the part that matters for delegated work — on which agent profile made the call, so the same human gets different rules depending on which agent is acting for them. The documented actions sit in four groups: access control (among them deny and require_approval), data protection (redact_args, dlp_block_result, egress_block and others), budget and abuse (rate_limit, cost_cap), and supply-chain defence (deny_drift, risk_deny), under a fixed deny > require_approval > redact > allow precedence. The product page states that rule changes propagate to the fleet within 30 seconds, with no restart and no redeploy.

Line that up against the draft's out-of-scope list and the correspondence is instructive. Policy decision points: the rules engine. Financial budgets: cost_cap. Anomaly detection: risk_deny and the DLP scanners. Event streams: approval lifecycle events routed to incident notifications. Tamper-evident audit storage: the audit log, which records the resolved identity, the decision and the rules that fired for each brokered call, exports to CSV, and stores no payload values.

Two mechanics answer the failure modes above specifically. Identity resolution means a brokered call reaches GitHub or Slack attributed to the person who triggered it rather than to a service account — the operational form of the draft's rule that a developer credential is not proof of a principal's consent. And require_approval parks a call for a human reviewer with the caller, the agent, the tool and the arguments in view, holding the MCP connection open with progress notifications so the agent waits rather than times out; on denial it receives a structured error it can recover from. The approval pauses the agent instead of breaking it, which is the difference between a human-in-the-loop control a team keeps and one it switches off in week two. The broader policy engine is described the same way: 50+ policy categories, evaluated deterministically before execution proceeds rather than logged after it.

One boundary, stated plainly, because it is the difference between a governance claim and a marketing claim. The gateway governs the calls that traverse it. Agents holding direct upstream credentials, locally registered MCP servers and unconfigured clients do not pass through it, so coverage is configured rather than automatic. What it changes is that for the tool access routed through it, the decision and the record exist at the moment of the call rather than being reconstructed afterwards.

FAQ

Is the OAuth agent draft a standard I should be implementing?

No. It is an individual Internet-Draft, and the IETF Datatracker states that such documents are not endorsed by the IETF and have no formal standing in the standards process. Its value is as a statement of where the token layer ends. The mechanisms it profiles — pushed authorization requests, PKCE, resource indicators, OAuth Token Exchange — are established specifications adoptable on their own merits today.

What is the difference between attenuating a token and enforcing a policy?

Attenuation reduces the authority a credential carries before it is used: a narrower scope, a single resource, a shorter life — which is what this profile is good at, via resource-bound, sender-constrained tokens and Token Exchange. Enforcement evaluates the specific attempt — this tool, these arguments, this spend so far, whether the tool changed since it was reviewed. You want both, and only one of them fits inside a JWT.

Does any of this apply to agents that do not use MCP?

The reasoning does; the mechanism is scoped. Issue-time versus call-time authority is a property of any agent calling any API. A gateway governs MCP tool calls specifically, so plain HTTP calls an agent makes directly are captured in execution traces but are not gated by it — worth scoping deliberately rather than assuming coverage.

What governs handoffs between agents rather than tool calls?

A different record. Waxell Connect, which includes the MCP Gateway, owns agent registration, agent-to-agent handoffs and the versioned, audited record of those handoffs. The gateway's audit log answers what an agent did to an upstream tool; Connect's record answers what one agent handed to another, and on whose authority.

Our auditors asked for a tamper-proof agent log. Can we buy one?

Ask what "tamper-proof" means in the specific product. The draft's rule is the right standard to hold a vendor to: an operator-signed hash chain is not operator-independent evidence without publication to, or countersignature by, an independent witness. An exportable, payload-free decision log covers most audit requirements honestly; a claim of independence requires a third party in the picture.

Sources

• IETF Datatracker, S. Kumar, "OAuth Profile for Delegated AI Agent Authorization" (draft-mishra-oauth-agent-grants-02), last updated 30 August 2026.

• IETF Datatracker, S. Kumar, "Delegated Agent Authorization Protocol (DAAP)" (draft-mishra-oauth-agent-grants-01), 2 March 2026.

• NIST, "CAISI Issues Request for Information About Securing AI Agent Systems" (nist.gov), 12 January 2026.

• NIST NCCoE, "Software and AI Agent Identity and Authorization" (nccoe.nist.gov), status: soliciting comments.

• NIST CSRC, "SP 800-53 Control Overlays for Securing AI Systems (COSAiS)" (csrc.nist.gov), updated 8 January 2026.

• Waxell, "MCP Gateway — Governed AI Tool Access" (waxell.ai).

• Waxell, "Policies & Approvals" (waxell.ai docs).

• Waxell, "Policies" (waxell.ai).

Your agents are already making tool calls against credentials somebody issued weeks ago. See the Waxell MCP Gateway's policy gate and audit log run against your own upstreams — bring your security team and book a 30-minute walkthrough at waxell.ai/demo.