In August I wrote a gap analysis built on draft-klrc-aiagent-auth-03, an individual IETF submission that stitched SPIFFE, WIMSE and OAuth into one picture of how an AI agent should authenticate and be authorized. On 15 September 2026 the same document came back as draft-ietf-wimse-aims-00, “AI Identity Management System,” now a document of the WIMSE working group. The author list didn’t change: Kasselman (Defakto Security), Lombardo (AWS), Rosomakho (Zscaler), Campbell (Ping Identity), Steele (OpenAI) and Parecki (Okta).
A second revision, -01, followed on 2 November 2026. It adds a section on policy-based authorization and renumbers part of section 10; I note the changes where they matter below. Section numbers in this piece refer to -00.
Adoption gives the framework standing. It doesn’t change what the framework is. The abstract says AIMS “proposes best practices” and, “rather than defining new protocols,” describes how existing standards can be applied. Its intended status is Informational. Every mechanism it relies on lives in some other document, and those documents are at very different stages.
I wanted to know which of those stages you can actually build on, so I sorted them by maturity using the IETF datatracker as it stood on 10 October 2026, and re-checked the statuses on 13 November. The result is a fairly blunt pattern. Everything finished is general-purpose OAuth and HTTP. Everything written for agents is still a draft.
The stack by maturity
The finished tiers contain no document written for agents. The agent-specific documents sit in the bottom two tiers.Published RFCs
Everything in the top tier predates the agent wave and was written for ordinary OAuth and HTTP: RFC 8693 token exchange, RFC 9449 DPoP, RFC 8707 resource indicators, RFC 7523 JWT grants, RFC 9728 protected resource metadata, RFC 9207 issuer identification and RFC 9421 HTTP message signatures. The MCP authorization specification requires three of them directly (RFC 8707, 9728 and 9207). Its extensions and open SEPs pull in RFC 7523 and RFC 9449.
Most of the security value available today sits in this tier. Audience-restricted tokens, proof of possession and mix-up protection are finished standards with shipping implementations. They’re boring, and that’s the point.
The RFC Editor queue
OAuth Identity and Authorization Chaining Across Domains is approved and waiting for its first editor pass at revision 17. It lets a client carry a user’s identity and authorization into another trust domain: exchange a token for a JWT authorization grant at home, present that grant in the next domain. AIMS section 10.6 (10.7 in -01) says agents “SHOULD” use it for cross-domain access. A revision of RFC 7523, draft-ietf-oauth-rfc7523bis, is in the same queue.
With the IESG or in last call
Workload Identity Practices (revision 07) is in Area Director evaluation as an Informational document. It describes how platforms already hand workloads credentials without long-lived secrets, and it says it “does not take into account the standards work in progress for the WIMSE architecture.”
OAuth 2.0 Attestation-Based Client Authentication (revision 12, posted 12 October) has finished working group last call: on 18 October the chairs moved it to “WG Consensus: Waiting for Write-Up,” the step before it goes to the IESG. It lets a client instance present a key-bound attestation from a client attester. That’s the closest standard mechanism to the “posture assessment” AIMS section 8 wants at credential provisioning.
Working group drafts
This tier holds the mechanisms AIMS leans on hardest. Transaction Tokens (revision 11) has working group consensus and is waiting for its shepherd write-up; the OAuth charter targets 31 December 2026 to send it to the IESG. The Identity Assertion JWT Authorization Grant (revision 04), which MCP’s Enterprise-Managed Authorization uses, and Client ID Metadata Documents (revision 02), now MCP’s preferred way to register clients, are both adopted drafts. So is OAuth SPIFFE Client Authentication, which lets a client authenticate to an authorization server with a JWT-SVID or X.509-SVID.
The WIMSE mechanisms all live here too: the architecture (revision 08), the Workload Proof Token (revision 02), HTTP signatures (revision 08, posted 20 October), mutual TLS, identifiers and credential formats.
The WIMSE charter tells you something about pace. Three proposed standards, including the JOSE-based WIMSE token for protecting chains of HTTP calls, were due at the IESG by March 2025. The architecture document was due in July 2026. None of them has gone. Standards work runs past its milestones all the time, so I don’t read this as a failure. I read it as a warning: anything you build on these drafts today will see wire-format changes.
AIMS is the only document in this tier written specifically for AI agents.
Individual drafts
The bottom tier is where the agent-specific protocol work actually lives, and it’s crowded. On 10 October 2026 the OAuth working group’s documents page listed 78 related individual drafts and the WIMSE page listed 16. Fifteen of those 94 have “agent” in the draft name. None has working group standing, and several were revised in the week I checked.
They cluster around five problems, and each cluster lines up with a gap AIMS or the MCP specification leaves open.
Naming the agent instance. OAuth 2.0 AI Agent Instance Profile takes on the case where “a single OAuth client identifier” stands for an agent platform running many concurrent instances. It defines claims for an attested instance identifier and its provenance (platform, model, runtime). WIMSE Applicability for AI Agents covers binding an agent identity to an accountable user or organization.
Delegation chains. OAuth Actor Profile for Delegation and its companion Actor Receipts give the RFC 8693 act claim consistent processing rules and a hash-linked chain of signed receipts, one per hop. Verifiable Attenuated Delegation for AI Agent Chains and Attenuating Authorization Tokens let each hop narrow authority with offline verification. All of them start from the same sentence in RFC 8693: nested act claims are “informational only.” I covered why that matters in the delegation chains piece.
Revocation. Revocation Closure for Agentic Authorization Systems argues that “credential invalidation alone does not establish that every path from revoked authority to a consequential effect has been closed,” and models revocation over an authority graph. I’ll come back to this one later in the series, because it’s the problem incident responders actually hit.
Proof at the tool. Per-Call Proof for Local Tool Invocation by AI Agents, first posted on 7 October 2026 and revised on 12 October, targets local tool servers reached over channels such as the “stdio transport of the Model Context Protocol.” It puts a Call Authority outside the agent process that issues a short-lived proof per invocation. The gap it’s aimed at is real. The MCP authorization spec says stdio implementations “SHOULD NOT follow this specification, and instead retrieve credentials from the environment,” which leaves reusable credentials sitting in the agent process. AIMS section 8, meanwhile, says “the Large Language Model MUST NOT have access to an agent’s credentials.” Those two sentences are hard to satisfy at the same time.
Audit. An Audit Record Format for AI Agent Authorization Decisions offers a signed record that carries the minimum audit fields AIMS lists, plus a comparison between the authorization decision and the effect actually observed. It was renamed on 16 October, from a WIMSE draft to one aimed at a new effort: AUDIT, short for Agent Use of Delegation and Interaction Traceability. AUDIT is a proposed working group. Its BoF request was approved on 8 October, the IETF lists it as a working-group-forming BoF at IETF 127 in San Francisco on 17 November 2026, and its draft charter is being argued on the mailing list now, including over its overlap with the vCon working group.
Off to one side sits a different architecture altogether: AAuth (revision 11), an agent-to-resource authorization protocol built on HTTP message signatures with five resource access modes, rather than a profile of existing OAuth flows.
What AIMS asks for, and who supplies it
AIMS describes its stack as components: identifier, credentials, provisioning, authentication, authorization, observability, policy and compliance. Mapping each one to the document that would supply it shows where an implementer actually stands.
Delegation is the only component fully backed by published RFCs today. The two components closest to agent behaviour, audit format and mission scoping, have no adopted document.Three things stand out.
Delegation is the most mature layer and the weakest for agents
OAuth grants and token exchange are finished, which is why every agent framework uses them. But RFC 8693 enforces only the current actor, as the delegation chain analysis shows. The maturity is real. So is the gap.
Section 11 says observability “is therefore a security control, not solely an operational feature,” and lists what every audit event must record at a minimum: the authenticated agent identifier, the delegated subject, the resource or tool, the action and the decision, a timestamp and correlation ID, the posture or risk state, and remediation or revocation events with their cause. It also says audit records “MUST be tamper-evident.” AIMS doesn’t define a record format, though. The only proposal for one is an individual draft, and the group that might take it on hasn’t been chartered yet.
Three things are out of scope on purpose
Section 10.1 puts mission-to-authorization translation out of scope. Section 12 says the policy model and document format “are out of scope for this framework and are not recommended as a target for standardization within this specification.” Section 13 says the same about compliance criteria. That’s an honest choice. It also means nobody else is going to write those parts for you. The -01 revision softens this slightly for policy: a new section 10.4 says that where token claims aren’t enough, a resource server can ask an external policy decision point, and names the OpenID AuthZEN Authorization API as a common interface. That standardizes how you ask for a decision, not the policy that makes it. Sections 12 and 13 are unchanged.
Limits of this snapshot
Maturity isn’t quality. An individual draft can be well designed, and an RFC can be misapplied. The statuses here come from the datatracker on 10 October 2026, re-checked on 17 October, and they change weekly. Individual drafts expire after six months unless revised, so some of the 94 will vanish and others will merge. That count is what the two working groups’ pages list as related documents. It isn’t a census of all agent identity work at the IETF, and the newest draft I cite, the per-call proof draft, wasn’t on either list yet.
What this means if you are building
- Build on the top two tiers. Audience-restricted tokens (RFC 8707), proof of possession (RFC 9449), token exchange (RFC 8693) and cross-domain chaining are stable enough to design around.
- Pilot the working group drafts behind an abstraction. Transaction tokens and SPIFFE client authentication are worth adopting in a gateway or broker you control, so a new revision changes one component instead of every agent.
- Use the individual drafts as design input, not dependencies. The delegation-chain and per-call proof drafts describe the right problems. Copy their invariants into your own checks (authority that only narrows, lifetimes that can’t outlive the parent, proofs issued outside the agent process) without taking a dependency on their wire formats.
- Write down the three out-of-scope items yourself. Mission scoping, policy format and compliance criteria won’t come from a standard, and they’re what an auditor asks about first.
- Log the AIMS minimum fields now. No format is standardized, but the seven fields are listed. A deployment that records them consistently, in any format, will map onto whatever gets adopted later.
The WIMSE and OAuth working groups work on public mailing lists, and individual drafts are where implementer feedback has the most leverage. Right now the agent drafts are being written mostly by vendors, and implementation reports and attack cases are scarce. If you run agents in production, that’s an opening.
Primary sources
IETF working group pages (status snapshot, 10 October 2026)
Working group documents
- draft-ietf-wimse-aims-00: AI Identity Management System, 15 September 2026, sections 8, 10.1, 10.6, 11, 12 and 13; -01, 2 November 2026
- draft-ietf-oauth-identity-chaining-17, RFC Editor queue
- draft-ietf-oauth-rfc7523bis-11, RFC Editor queue
- draft-ietf-wimse-workload-identity-practices-07, AD evaluation
- draft-ietf-oauth-attestation-based-client-auth-12, WG consensus, waiting for write-up (18 October)
- draft-ietf-oauth-transaction-tokens-11
- draft-ietf-oauth-identity-assertion-authz-grant-04
- draft-ietf-oauth-client-id-metadata-document-02
- draft-ietf-oauth-spiffe-client-auth-02
- draft-ietf-wimse-arch-08
- draft-ietf-wimse-wpt-02
- draft-ietf-wimse-http-signature-08
Individual drafts referenced
Published RFCs
MCP
Earlier in this series
