The Agent Identity Standards Map 2026

AI agent identity is mostly buildable on published standards today, but the parts that make agents different from ordinary software are still drafts. Of the 11 agent identity problems mapped here, 7 have a published standard (an RFC, an OpenID Final Specification, a stable SPIFFE spec, or a released MCP or A2A revision): 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. One, an agent lifecycle registry that binds each agent to an accountable owner, has no working-group draft at all. Meanwhile the IETF datatracker holds 123 individual agent identity drafts updated since January 2025, and only one of them has been adopted. This report maps all of it, dates every status, and publishes the dataset.

Methodology

Scope. We started from the specifications that AI agent protocols actually cite (the Model Context Protocol authorization spec and the A2A 1.0 specification), added the working-group documents in the IETF OAuth and WIMSE groups, the OpenID Foundation's Shared Signals, AuthZEN, CIBA and eKYC & IDA work, the SPIFFE standards, W3C, FIDO Alliance and NIST NCCoE activity, and the most visible individual Internet-Drafts aimed specifically at agents. The result is 70 rows.

Sources and verification date. Every status and date comes from the primary source: the IETF datatracker document page (WG state, IESG state, latest revision), the RFC Editor record, the OpenID Foundation specification page, the MCP and A2A specification sites and repositories, and the SPIFFE repository. All were read on 30 October 2026. Adoption signals are listed only where a vendor's own documentation, press release, or source code confirms them.

Status definitions.

Maturity score. Each problem gets a score from 0 to 5, computed as Spec level + Agent fit + Adoption:

• Spec level (0 to 3): 3 if a Specified document directly solves the problem; 2 if the best direct coverage is a working-group draft; 1 if only individual drafts, community groups or editor's notes exist; 0 if nothing does.
• Agent fit (0 or 1): 1 if a document at that level addresses the agent case normatively (an agent protocol requires it, or the spec text is written for agents), not only the general primitive.
• Adoption (0 or 1): 1 if at least one named implementation in a shipping product or an official reference SDK is verified from a primary source.

Coverage status follows the spec level: 3 is Specified, 2 is Drafted, 1 or 0 is a Gap.

The individual-draft count. We queried the datatracker for Internet-Drafts with "agent" in the filename, kept those whose title or name contains an identity, authorization or trust term (identity, auth, delegation, credential, trust, attestation, token, OAuth, SCIM, consent, revocation, provenance, PKI, identifier, permission, privilege, SPIFFE, WIMSE, accountability), excluded the unrelated SSH agent protocol, and counted those with any datatracker activity between 1 January 2025 and 30 October 2026. That gives 123. The filter misses agent drafts without "agent" in the filename (the AAuth drafts, for example), so the real number is higher.

Limits. This field moves monthly. Six of the drafts in the dataset were revised on the day we verified them. Every status below is dated, and the dataset carries a verified_on field. Problem boundaries are our editorial judgment; another reasonable map could split them differently. We report adoption only when confirmed, so a missing adoption signal means "not verified", not "not deployed".

The map: problem by standard

Read across a row to see what you can rely on today (Specified), what is in a working group (Drafted), and what exists only as proposals.

Maturity scores

The mean across all 11 problems is 3.9 out of 5. The four scores below 4 (problems 3, 4, 10 and 11) are exactly the problems that are new with agents: approving actions nobody is watching, delegating through several hops, owning an agent over its life, and proving afterwards who did what. The parts that score 5 are plain OAuth and workload identity applied to a new kind of client.

The standards behind the map, by body

IETF RFCs (published). These are settled and safe to build on.

IETF working-group drafts. Adopted, moving, and not yet stable. Dates are the latest revision.

Agent protocols. MCP and A2A are both hosted by the Linux Foundation's Agentic AI Foundation: Anthropic announced MCP's donation on 9 December 2025, and the A2A specification site announces that A2A has joined the foundation.

OpenID Foundation, CNCF, W3C, FIDO, NIST and OWASP.

What the map shows

Agents are being treated as workloads, on purpose. The one IETF working-group document written for agents, AIMS, opens with the position that "agents are workloads" and says that, "Rather than defining new protocols", it describes how existing standards apply. Its authors span Defakto Security, AWS, Zscaler, Ping Identity, OpenAI and Okta. It replaced the individual draft draft-klrc-aiagent-auth, which is the single adoption among the 123 individual agent drafts we counted. Practitioners should read that as a signal: the standards path for agents runs through workload identity, OAuth and SPIFFE, not through a new agent protocol.

The production path is ahead of the standards path. ID-JAG was an individual draft (draft-parecki-oauth-identity-assertion-authz-grant, last revised as -05 on 2 July 2025) before the OAuth working group adopted it and replaced it in August 2025. It is now at -06, still a working-group draft, and it is already the basis of a stable MCP extension and of Okta Agent SSO, which Okta made generally available on 24 August 2026 with prebuilt Cross App Access integrations for applications including Anthropic's Claude, Atlassian, Notion and Slack. Our earlier analysis, agent identity just got a protocol, covers what that adoption does and does not solve.

MCP depends on two moving drafts. The 2026-07-28 MCP revision builds its core on OAuth 2.1 (it cites draft-13; the draft is at -17) and makes the Client ID Metadata Document, an OAuth working-group draft at -02, the preferred registration method, while marking Dynamic Client Registration (RFC 7591) as deprecated and retained only for backwards compatibility. The client registration priority is: pre-registration, then CIMD, then DCR, then asking the user. Both drafts are stable enough in practice, but anyone writing an MCP authorization server is implementing against moving text.

Signals exist; agent signals do not. SSF, CAEP and RISC are Final, and the OpenID Foundation's press release of 16 September 2025 names Apple, IBM and Okta among adopters. But the 8 CAEP event types and 14 RISC event types describe sessions, credentials, devices, assurance, risk and accounts. None describes "this delegation grant was withdrawn" or "this agent was disabled". AIMS recommends SSF for agents, and that works if you model each agent as a subject, but nothing standardizes it.

Gap analysis

These are the missing pieces, named plainly. Each has at least one individual draft trying to fill it, and none has a published standard.

1. Mid-task human approval bound to an authorization grant. CIBA lets a client ask a user to approve out of band, but AIMS itself notes that "CIBA itself only accounts for client initiation, which doesn't map well to cases that envision the need for User confirmation to occur mid-execution". A2A 1.0 defines the AUTH_REQUIRED state but says agents "MUST arrange to receive credentials via an out-of-band means". MCP URL-mode elicitation sends the user to a page but explicitly is not for authorizing the client. The OAuth working group's Deferred Token Response (-00, September 2026) is the first adopted piece, and the FIDO Alliance's agentic working group, announced 28 April 2026, has published nothing yet. Nothing yet ties "the user approved this specific action" to a verifiable grant that a resource server can check.

2. Enforceable multi-hop delegation. RFC 8693 can nest act claims to record every prior actor, then states they "are informational only and are not to be considered in access control decisions". Identity Chaining (in the RFC Editor queue) handles one cross-domain hop at a time. Transaction Tokens propagate context inside one trust domain. Delegate SD-JWT (-00, adopted October 2026) is the working-group draft aimed squarely at agents: it lets a holder delegate onward to a delegate holder with its own key binding. Attenuation, the rule that each hop can only narrow authority, lives in individual drafts.

3. Agent lifecycle and ownership registry. No working group has adopted anything that records an agent's accountable owner, purpose, creation and expiry, or deprovisions it. The SCIM agent extensions (draft-abbey-scim-agent-extension, draft-wahl-scim-agent-schema) have expired, and the W3C Agent Identity Registry Protocol Community Group has published no drafts. This is the gap behind the orphaned and over-privileged agents that the OWASP Non-Human Identities Top 10 ranks as its first and fifth risks (Improper Offboarding, Overprivileged NHI).

4. A standard audit record for agent actions. AIMS says deployments "MUST produce durable audit logs" and lists seven minimum fields (authenticated agent identifier, delegated subject, resource or tool, action and decision, timestamp and correlation ID, posture or risk state, remediation events), then puts the policy model and compliance format out of scope. The only record-format proposal is the individual draft-gilda-audit-agent-audit-record (-03, 29 October 2026).

5. Turning an agent's mission into authorization. AIMS describes the agent's "Mission", usually natural language, and states that translating it into authorization requirements "is out of scope". RAR and AuthZEN can express the resulting request, but no standard covers the step from intent to scoped request, which is where prompt injection turns into over-broad access.

6. Agent-specific revocation events. See above: the signal pipe is Final, the agent vocabulary is not. An individual draft extending RFC 7009 for batch and cascade revocation of agent authorizations (draft-chen-oauth-agent-revocation, -01) was revised to -01 on 30 October 2026.

7. Sender-constrained tokens in agent protocols. DPoP and mTLS-bound tokens are published RFCs, but MCP core requires Authorization: Bearer and its DPoP profile is an open SEP. A2A lets an agent declare mutual TLS as an authentication scheme but does not require token binding. Agents hold tokens in processes that read untrusted input, which is the situation where a stolen bearer token costs most.

What to build on today

Every pattern below uses only Specified documents unless marked. Where a draft is the only option, pin the revision you implement and track it.

Two cross-cutting rules hold for every row. First, prefer no standing access: issue tokens just in time and scope them to the task, the approach in our zero standing privileges guide. Second, keep identity decisions out of the model: the authorization server and resource server decide, the agent only carries credentials. The securing AI agent identities guide walks through the program side, and the AI agent identity tools ranking, the non-human identity platforms ranking, the authorization tools ranking and the AI identity vendor directory cover products. For the underlying protocols see OAuth 2.1, OpenID Connect and agentic identity.

About the data

The dataset has 70 rows, one per specification, draft or guidance document: 31 Specified, 22 working-group drafts, 9 individual drafts, 2 open agent-protocol proposals, 2 chartered groups with no spec, and 4 guidance documents. Each row carries name, body, identifier, status, status_class, latest_version_date, url, problems_addressed (semicolon-separated problem slugs matching the 11 rows above), adoption_signal (only where verified) and verified_on. The JSON file adds the status-class and problem definitions. Download it as CSV or JSON.

Dates use the granularity the source publishes: a month for RFCs, a day for drafts and OpenID specifications. For IETF drafts the date is the latest revision, not the last datatracker event. The 9 individual drafts in the dataset are a sample chosen because they target an open gap or are widely discussed. They are not endorsements, and the full population is the 123 counted in the methodology.

We will re-verify the map when any of these change: Identity Chaining or Transaction Tokens become RFCs, ID-JAG or Client ID Metadata Document reach working-group last call, MCP publishes a new revision, or the FIDO Alliance publishes a draft. Corrections with a primary-source link are welcome through the contact page and are credited.