The IETF’s WIMSE working group has published a full model for agent authentication and authorization — not a new protocol, but a claim about which existing standards do the work, and where the gaps still are.
What happened
On 2 November 2026 the working group published revision 01 of draft-ietf-wimse-aims, “AI Identity Management System” — 33 pages, Informational, expiring 6 May 2027. The authors are Pieter Kasselman (Defakto Security), Jason Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Nick Steele (OpenAI) and Aaron Parecki (Okta).
The document’s premise is that agent identity work is fragmenting: too many efforts “reinventing existing mechanisms unaware of applicable prior art,” which risks “incompatible implementations.” Its answer is a conceptual stack built from WIMSE and the OAuth 2.0 family, plus CNCF and OpenID Foundation work, rather than a new protocol:
- Agent identifier — an agent MUST have exactly one WIMSE identifier, which MAY be a SPIFFE ID. Credentials expire; the identifier persists. When an agent is retired its identifier must not be reassigned, so audit and delegation records stay interpretable.
- Credentials and provisioning — cryptographic binding between identifier and agent attributes, issued at runtime rather than baked into deployment.
- Authentication — at the transport layer, and at the application layer through WIMSE proof tokens or HTTP message signatures.
- Authorization — an agent receives a Mission (a task in natural language), which is decomposed into resource requests; those are then obtained through OAuth 2.0, including transaction tokens for finer-grained calls and cross-domain access patterns.
- Monitoring, observability and remediation — with signed signals (OpenID Shared Signals, CAEP, RISC, WISE) that must be acted on: cached tokens and stale authorization decisions “MUST NOT continue to be used after a revocation or risk notification.”
- Policy and compliance — the configuration and measurement layer over the whole stack.
Two rules stand out for anyone shipping agents.
First, a user clicking “approve” in an agent’s own UI is not authorization. The draft says interactive confirmations, including MCP-style tool-approval prompts, “do not by themselves constitute authorization and MUST be bound to a verifiable authorization grant issued by the authorization server.” Step-up approval should run out of band — CIBA is named — with the authorization server keeping the decision.
Second, audit is a security control, not a log line. Deployments MUST produce durable, tamper-evident records covering, at minimum: the authenticated agent identifier, the delegated subject, the resource or tool, the action and decision, a timestamp and correlation identifier, the risk state behind the decision, and any remediation or revocation event.
The draft is honest about what it does not solve. Translating a natural-language mission into authorization requirements is explicitly out of scope, and the authors note that CIBA only covers client-initiated approval, which “doesn’t map well” to confirmation requested mid-execution.
Why it matters for KYA
It gives “know your agent” a technical definition you can audit against. KYA in practice needs four things: a stable identifier, a credential bound to it, evidence of what the agent was authorised to do, and a record of what it did. This draft specifies all four and marks which are MUSTs.
It separates identity from authority — structurally. The identifier is stable and never reused; credentials are short-lived; authority arrives as a mission-scoped OAuth grant. That is the opposite of the pattern most enterprises still run, where an agent inherits a long-lived service account and “identity” means an API key in a config file.
It makes the audit record the deliverable. An auditor asking “who did this and under whose authority” gets an answer only if the identifier, the delegated subject and the decision are all in the same record. The minimum field list here is a reasonable checklist for a procurement question.
The human-in-the-loop warning is the practical takeaway. Platforms that treat an in-app approval dialog as consent are building something this draft says is insufficient. If you need a control, it has to be a grant from a server the agent does not control.
What to watch
Whether the working group keeps this Informational or pushes parts of it toward a profile that implementers can conform to — and whether the mission-to-authorization step gets picked up as separate work, since that is where agent authority is actually decided. Also watch the companion drafts in the same submission window: Mission-Bound Authorization for OAuth 2.0, Verifiable Mandates for Agents Acting Across Administrative Domains, and Evidence Binding for AI Agent Credentials all fill gaps this document leaves open.
Sources
- IETF, draft-ietf-wimse-aims-01, “AI Identity Management System”, 2 November 2026 — datatracker.ietf.org
- Full draft text — ietf.org
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.