Agent Identity Standards Map 2026: Findings

SWI's Agent Identity Standards Map 2026 dates the status of 70 specifications for AI agent authentication, delegation and authorization. Most of the problem is buildable on published OAuth and workload standards. The parts that make agents different, from delegation chains to an owner registry, are still drafts or nothing at all.

AI agent identity can mostly be built on published standards today, but the parts that make agents different are still drafts. Of 11 agent identity problems mapped in SWI's Agent Identity Standards Map 2026, 7 are covered by a published standard, 3 only by working-group drafts, and 1 has no working-group draft at all. The map covers 70 specifications, drafts and guidance documents across the IETF, OpenID Foundation, MCP, A2A, SPIFFE, W3C, FIDO Alliance and NIST, with every status read from the primary source on 30 October 2026.

Seven problems solved, one with nothing

The seven covered problems are agent authentication, delegated access on a user's behalf, fine-grained authorization, token audience binding, proof of possession, revocation signals, and client registration and discovery. Three rely only on working-group drafts: consent for asynchronous actions, delegation chains that keep every hop, and attributing actions to both human and agent. The gap is an agent lifecycle registry that ties each agent to an accountable owner.

The pattern is the useful part. The problems that score well are plain OAuth and workload identity applied to a new kind of client. The ones that score poorly are the ones that are new with agents. Until a standard exists, an agent's owner, purpose and expiry belong in your existing non-human identity inventory.

123 individual drafts, one adoption

The report counted 123 individual IETF Internet-Drafts with "agent" in the filename and an identity, authorization or trust term in the title, updated between 1 January 2025 and 30 October 2026. Exactly one was adopted by a working group.

What it became is telling. The only IETF working-group document dedicated to AI agents, draft-ietf-wimse-aims-00 (15 September 2026), is Informational and defines no new protocol. It maps agents onto WIMSE, OAuth, Transaction Tokens, CIBA and Shared Signals. Read that as direction: the standards path for agents runs through workload identity, OAuth and SPIFFE, not a new agent protocol.

Delegation chains are recorded, not enforced

RFC 8693 Token Exchange can record a full chain of nested actors, but says prior actors "are informational only and are not to be considered in access control decisions". No published standard enforces a multi-hop delegation chain.

For anyone building agent-to-tool or agent-to-agent flows, this is the main design constraint. Exchange the token at every hop, narrow its scope each time, keep the act chain for logs, and have each hop enforce its own policy. Do not make access decisions from nested act claims.

MCP and Cross App Access run on moving drafts

The protocols agents use are ahead of the standards they cite. MCP revision 2026-07-28 deprecates Dynamic Client Registration (RFC 7591) in favor of Client ID Metadata Documents, an IETF draft at revision -02, and still cites OAuth 2.1 draft-13 while that draft has reached -17. See Client ID Metadata Document, Dynamic Client Registration and OAuth 2.1.

ID-JAG (Cross App Access) is in production before it is a standard. It is a working-group draft at -06 (30 October 2026), yet it underpins the stable MCP Enterprise-Managed Authorization extension and Okta Agent SSO, generally available since 24 August 2026. Anyone writing an MCP authorization server should pin the draft revision they implement and track it. Our ID-JAG entry and the earlier analysis agent identity just got a protocol explain the flow.

Revocation and token binding stop short of agents

Shared Signals is Final, but its vocabulary is not agent-aware. None of the 22 event types in OpenID CAEP 1.0 and RISC 1.0 (Final, 29 August 2025) is specific to agents or to delegation grants, so revoking an agent's authority mid-task has to be mapped onto session or account events. In practice, model each agent as a subject and use CAEP session-revoked and RISC account-disabled.

Token binding is the second gap. Neither MCP nor A2A requires sender-constrained tokens. MCP core authorization uses bearer tokens, and its DPoP profile is an open proposal, although DPoP has been RFC 9449 since September 2023. Agents hold tokens in processes that read untrusted input, so where your servers support DPoP or mTLS-bound tokens, use them, and otherwise keep token lifetimes in minutes.

How we did it

We started from the specifications MCP and A2A cite, added the IETF OAuth and WIMSE working-group documents, the OpenID Foundation's Shared Signals, AuthZEN, CIBA and eKYC work, SPIFFE, W3C, FIDO and NIST activity, and the most visible agent-specific individual drafts, for 70 rows. Each of the 11 problems got a 0 to 5 maturity score from spec level, agent fit and verified adoption. Limits: the field moves monthly (six drafts were revised on the day we verified them), problem boundaries are editorial judgment, adoption is listed only where confirmed from a primary source, and the 123 count misses agent drafts without "agent" in the filename, so the real number is higher.

The full report has a build-on-today table for each problem. For products, see the AI agent identity tools ranking and the agentic identity glossary entry.

Use the data: download the map as CSV or JSON, with status and problem definitions. It is free to reuse under CC BY 4.0 with attribution to Start with Identity and a link to the report.