# The Agent Identity Standards Map 2026

Source: https://startwithidentity.com/reports/agent-identity-standards-map-2026/
Last updated: 2026-10-30
License: content by Start with Identity. Cite the source URL.

---

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](#about-the-data).

## Methodology

**Scope.** We started from the specifications that AI agent protocols actually cite (the [Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) authorization spec and the [A2A 1.0 specification](https://a2a-protocol.org/v1.0.0/specification/)), added the working-group documents in the IETF [OAuth](https://datatracker.ietf.org/wg/oauth/documents/) and [WIMSE](https://datatracker.ietf.org/wg/wimse/documents/) groups, the OpenID Foundation's Shared Signals, [AuthZEN](https://startwithidentity.com/glossary/authzen/), CIBA and eKYC & IDA work, the [SPIFFE standards](https://github.com/spiffe/spiffe/tree/main/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.**

| Status class | What it means |
|---|---|
| Specified | Published RFC, OpenID Final Specification, W3C Recommendation, SPIFFE "Stable" specification, or a released revision of an agent protocol (MCP 2026-07-28, A2A 1.0) |
| Drafted (WG) | Adopted by a standards working group but not final: IETF WG document, OpenID working-group draft, SPIFFE "Incubating" |
| Drafted (individual) | Individual Internet-Draft not adopted by any working group, including expired drafts |
| Agent-protocol draft | Open proposal (SEP) in an agent protocol, not part of a released revision |
| Chartered, no spec | A group exists but has published no draft |
| Guidance | Non-normative guidance, risk list or concept paper |

**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.

| # | Agent identity problem | Specified (published) | Drafted (working group) | Proposals only | Coverage |
|---|---|---|---|---|---|
| 1 | Agent authenticates itself | SPIFFE X.509-SVID and JWT-SVID (Stable); RFC 8705 mTLS; RFC 7523 JWT client assertion; MCP OAuth Client Credentials extension; A2A 1.0 security schemes | WIMSE workload-creds -03, http-signature -08, mutual-tls -03, wpt -02; OAuth attestation-based client auth -12; OAuth SPIFFE client auth -02; WIT-SVID (Incubating) | MCP SEP-1933 (workload identity federation); AAuth | Specified |
| 2 | Agent acts on behalf of a user with delegated scope | RFC 6749 with PKCE (RFC 7636); RFC 8693 Token Exchange; MCP 2026-07-28 authorization; MCP Enterprise-Managed Authorization extension | OAuth 2.1 -17; ID-JAG -06 | draft-oauth-ai-agents-on-behalf-of-user (expired); FIDO Agentic Authentication TWG (no spec) | Specified |
| 3 | Consent for autonomous or asynchronous actions | CIBA Core 1.0 (client-initiated only); RFC 9470 step-up; MCP URL-mode elicitation; A2A AUTH_REQUIRED task state | Deferred Token Response -00; AuthZEN Access Request and Approval Profile (Draft 1) | AAuth; FIDO TWG | Drafted |
| 4 | Chained delegation across agents and tools, chain preserved | RFC 8693 nested `act` claim (recorded, not enforced) | Identity Chaining -17 (RFC Editor queue); Transaction Tokens -11; Delegate SD-JWT -00 | Attenuating agent tokens; Transaction Tokens for Agents | Drafted |
| 5 | Per-call fine-grained authorization | RFC 9396 RAR; AuthZEN Authorization API 1.0; MCP per-operation scope challenges | COAZ-MCP binding (Draft 1); RAR metadata and remediation -00 | Several RAR and scope extensions for agents | Specified |
| 6 | Token audience and resource binding | RFC 8707 Resource Indicators; RFC 9728 Protected Resource Metadata; MCP audience-validation MUSTs | OAuth 2.1 -17 | None needed | Specified |
| 7 | Proof of possession | RFC 9449 DPoP; RFC 8705 certificate-bound tokens; RFC 9421 HTTP Message Signatures | WIMSE WPT -02 and http-signature -08; WIT-SVID | MCP SEP-1932 DPoP profile | Specified (not required by MCP or A2A) |
| 8 | Real-time revocation and session signals | OpenID SSF 1.0, CAEP 1.0, RISC 1.0; RFC 8417 SET; RFC 7009 revocation | AIMS -00 (recommends SSF for agents) | Agent revocation extension to RFC 7009 | Specified (no agent-specific events) |
| 9 | Client registration and capability discovery | RFC 7591 DCR; RFC 8414; RFC 9728; A2A Agent Card with JWS signing | Client ID Metadata Document -02 | Many agent discovery drafts | Specified |
| 10 | Agent lifecycle registry (owner, purpose, deprovisioning) | None for agents (VC Data Model 2.0 and SCIM 2.0 are generic) | None | SCIM agent extensions (expired); W3C Agent Identity Registry Protocol CG (no drafts) | **Gap** |
| 11 | Audit and attribution of actions to human and agent | RFC 8693 `sub` plus `act` in tokens | AIMS -00 minimum audit fields; Transaction Tokens -11 | Agent audit record format draft | Drafted |

### Maturity scores

| # | Problem | Spec level | Agent fit | Adoption | Score | Basis |
|---|---|---|---|---|---|---|
| 1 | Agent authenticates itself | 3 | 1 | 1 | **5** | SPIFFE Stable; MCP Client Credentials extension; SPIRE v1.15.5 (20 Oct 2026) |
| 2 | On-behalf-of delegation | 3 | 1 | 1 | **5** | OAuth RFCs; MCP authorization; Okta Agent SSO GA 24 Aug 2026 |
| 3 | Async and autonomous consent | 2 | 1 | 0 | **3** | Best direct coverage is Deferred Token Response -00; A2A defines the signal, not the approval |
| 4 | Chained delegation | 2 | 1 | 0 | **3** | Chain is carried by RFC 8693 but enforced only in drafts; Delegate SD-JWT targets agents |
| 5 | Fine-grained authorization | 3 | 1 | 0 | **4** | RAR and AuthZEN 1.0 Final; MCP scope challenges; no verified agent deployment |
| 6 | Audience and resource binding | 3 | 1 | 1 | **5** | RFC 8707 and 9728 required by MCP; checked in the official MCP TypeScript SDK |
| 7 | Proof of possession | 3 | 0 | 1 | **4** | DPoP in Okta and Auth0 docs; neither agent protocol requires it |
| 8 | Revocation and session signals | 3 | 0 | 1 | **4** | SSF, CAEP, RISC Final; adopters named by OIDF; no agent event types |
| 9 | Registration and discovery | 3 | 1 | 1 | **5** | RFC 7591, 8414, 9728; MCP CIMD support in the official TypeScript SDK |
| 10 | Agent lifecycle registry | 1 | 1 | 0 | **2** | Only expired individual SCIM drafts and a W3C community group |
| 11 | Audit and attribution | 2 | 1 | 0 | **3** | AIMS lists minimum fields but leaves the format out of scope |

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.

| Specification | Identifier | Published | Agent problem |
|---|---|---|---|
| OAuth 2.0 Token Exchange | [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html) | January 2020 | Delegation, actor chains, attribution |
| Resource Indicators | [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) | February 2020 | Audience binding |
| Protected Resource Metadata | [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728.html) | April 2025 | Discovery, audience binding |
| Dynamic Client Registration | [RFC 7591](https://www.rfc-editor.org/rfc/rfc7591.html) | July 2015 | Registration |
| Rich Authorization Requests | [RFC 9396](https://www.rfc-editor.org/rfc/rfc9396.html) | May 2023 | Fine-grained authorization |
| DPoP | [RFC 9449](https://www.rfc-editor.org/rfc/rfc9449.html) | September 2023 | Proof of possession |
| mTLS client auth and certificate-bound tokens | [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705.html) | February 2020 | Agent authentication, proof of possession |
| JWT client authentication and grants | [RFC 7523](https://www.rfc-editor.org/rfc/rfc7523.html) | May 2015 | Agent authentication; carrier for ID-JAG |
| Step Up Authentication Challenge | [RFC 9470](https://www.rfc-editor.org/rfc/rfc9470.html) | September 2023 | Consent, escalation |
| OAuth 2.0 Security BCP | [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html) | January 2025 | Baseline for every flow |
| Security Event Token | [RFC 8417](https://www.rfc-editor.org/rfc/rfc8417.html) | July 2018 | Signal format under SSF |
| GNAP | [RFC 9635](https://www.rfc-editor.org/rfc/rfc9635.html) | October 2024 | Delegation and asynchronous interaction; we found no agent protocol that cites it |

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

| Draft | Revision | Latest revision | State on 30 Oct 2026 |
|---|---|---|---|
| [OAuth 2.1](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) | -17 | 2026-10-30 | WG Document |
| [Identity Assertion JWT Authorization Grant (ID-JAG)](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) | -06 | 2026-10-30 | WG Document |
| [Identity and Authorization Chaining Across Domains](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) | -17 | 2026-07-19 | Approved, in RFC Editor queue (Proposed Standard) |
| [Transaction Tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/) | -11 | 2026-07-30 | WG Consensus, waiting for write-up; milestone to reach IESG December 2026 |
| [Client ID Metadata Document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) | -02 | 2026-07-06 | WG Document |
| [Deferred Token Response](https://datatracker.ietf.org/doc/draft-ietf-oauth-deferred-token-response/) | -00 | 2026-09-16 | WG Document |
| [Delegate SD-JWT](https://datatracker.ietf.org/doc/draft-ietf-oauth-delegate-sd-jwt/) | -00 | 2026-10-30 | WG Document |
| [Attestation-Based Client Authentication](https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/) | -12 | 2026-10-12 | WG Consensus, waiting for write-up |
| [OAuth SPIFFE Client Authentication](https://datatracker.ietf.org/doc/draft-ietf-oauth-spiffe-client-auth/) | -02 | 2026-06-15 | WG Document |
| [AI Identity Management System (AIMS)](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) | -00 | 2026-09-15 | WG Document, Informational |
| [WIMSE Architecture](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) | -08 | 2026-07-06 | WG Document |
| [WIMSE Workload Credentials](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) | -03 | 2026-10-30 | WG Document |
| [WIMSE Authentication with HTTP Signatures](https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/) | -08 | 2026-10-20 | Publication requested (Proposed Standard) |
| [WIMSE Workload Proof Token](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) | -02 | 2026-08-27 | WG Document |
| [Workload Identity Practices](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-practices/) | -08 | 2026-10-30 | IETF Last Call, ends 2026-11-13 (Informational) |

**Agent protocols.** MCP and A2A are both hosted by the Linux Foundation's Agentic AI Foundation: Anthropic [announced MCP's donation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) on 9 December 2025, and the A2A specification site announces that A2A has joined the foundation.

| Specification | Version | Status | What it settles for identity |
|---|---|---|---|
| [MCP Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) | 2026-07-28 | Current revision | OAuth 2.1 resource server model; RFC 9728 required; RFC 8707 `resource` required in authorization and token requests; tokens must be audience-checked; servers must not pass tokens through; CIMD SHOULD, DCR deprecated |
| [MCP Enterprise-Managed Authorization](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx) | 2026-07-28 | Stable extension | ID-JAG applied to MCP: SSO assertion exchanged at the enterprise IdP for access to each MCP server |
| [MCP OAuth Client Credentials](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/oauth-client-credentials/2026-07-28/oauth-client-credentials.mdx) | 2026-07-28 | Stable extension | Agent or service acting as itself |
| [MCP DPoP profile, SEP-1932](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1932) | n/a | Open proposal, updated 2026-10-21 | Sender-constrained tokens for MCP |
| [A2A Protocol](https://a2a-protocol.org/v1.0.0/specification/) | 1.0 ([v1.0.1](https://github.com/a2aproject/A2A/releases/tag/v1.0.1), 2026-05-28) | Released | Security schemes in the Agent Card; every request authenticated; optional JWS-signed Agent Cards (RFC 7515 with RFC 8785 canonicalization); AUTH_REQUIRED task state |

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

| Specification or effort | Body | Status | Date |
|---|---|---|---|
| [Shared Signals Framework 1.0](https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html), [CAEP 1.0](https://openid.net/specs/openid-caep-1_0-final.html), [RISC 1.0](https://openid.net/specs/openid-risc-1_0-final.html) | OpenID Foundation | Final | 29 August 2025 (approval announced 2 September 2025) |
| [AuthZEN Authorization API 1.0](https://openid.net/specs/authorization-api-1_0.html) | OpenID Foundation | Final | 11 January 2026 (approval announced 12 January 2026) |
| [COAZ-MCP binding](https://openid.github.io/authzen/authzen-coaz-mcp-binding-1_0.html) | OpenID AuthZEN WG | Draft 1 | 13 February 2026 |
| [AuthZEN Access Request and Approval Profile](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html) | OpenID AuthZEN WG | Draft 1 | 29 October 2026 |
| [CIBA Core 1.0](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) | OpenID Foundation | Final | 1 September 2021 |
| [OpenID Connect Authority claims extension](https://openid.bitbucket.io/ekyc/openid-authority.html) | OpenID eKYC & IDA WG | -00, no agent text | 25 May 2026 |
| [Identity Management for Agentic AI](https://openid.net/new-whitepaper-tackles-ai-agent-identity-challenges/) | OpenID AIIM Community Group | Whitepaper (the CG does not write protocols) | 7 October 2025 |
| [SPIFFE standards](https://github.com/spiffe/spiffe/tree/main/standards) (SPIFFE ID, X.509-SVID, JWT-SVID, Workload API, Federation) | CNCF | Stable | Workload API last changed 26 September 2026 |
| [WIT-SVID](https://github.com/spiffe/spiffe/blob/main/standards/WIT-SVID.md) | CNCF | Incubating | 1 July 2026 |
| [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/) | W3C | Recommendation (no agent profile) | 15 May 2025 |
| [Agent Identity Registry Protocol CG](https://www.w3.org/community/agent-identity/) | W3C Community Group | No drafts; not standards track | Call for participation 24 April 2026 |
| [Agentic Authentication Technical Working Group](https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/) | FIDO Alliance | Announced, no published spec | 28 April 2026 |
| [Software and AI Agent Identity and Authorization concept paper](https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd) | NIST NCCoE | Initial Public Draft; comments closed 2 April 2026 | 5 February 2026 |
| [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) | OWASP GenAI Security Project | Published risk list | 9 December 2025 |
| [OWASP Non-Human Identities Top 10](https://owasp.org/www-project-non-human-identities-top-10/2025/) | OWASP | Published risk list | 2025 edition |

## What the map shows

**Agents are being treated as workloads, on purpose.** The one IETF working-group document written for agents, [AIMS](https://datatracker.ietf.org/doc/draft-ietf-wimse-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](https://startwithidentity.com/glossary/workload-identity/), OAuth and SPIFFE, not through a new agent protocol.

**The production path is ahead of the standards path.** [ID-JAG](https://startwithidentity.com/glossary/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](https://startwithidentity.com/vendors/iam/okta/) Agent SSO, which Okta [made generally available](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) 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](https://startwithidentity.com/blog/agent-identity-gets-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](https://startwithidentity.com/glossary/client-id-metadata-document/), an OAuth working-group draft at -02, the preferred registration method, while marking [Dynamic Client Registration](https://startwithidentity.com/glossary/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](https://startwithidentity.com/glossary/risc/) are Final, and the OpenID Foundation's [press release](https://openid.net/press-release-openid-foundation-finalizes-global-standards-for-real-time-identity-security/) of 16 September 2025 names Apple, [IBM](https://startwithidentity.com/vendors/iam/ibm-verify/) 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](https://startwithidentity.com/glossary/identity-chaining/) (in the RFC Editor queue) handles one cross-domain hop at a time. [Transaction Tokens](https://startwithidentity.com/glossary/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](https://datatracker.ietf.org/doc/draft-abbey-scim-agent-extension/), [draft-wahl-scim-agent-schema](https://datatracker.ietf.org/doc/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](https://owasp.org/www-project-non-human-identities-top-10/2025/) 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](https://datatracker.ietf.org/doc/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](https://startwithidentity.com/glossary/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](https://datatracker.ietf.org/doc/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.

| Problem | Build on | Avoid |
|---|---|---|
| Agent authenticates itself | A distinct identity per agent deployment: [SPIFFE](https://startwithidentity.com/glossary/spiffe/) SVIDs (for example from [SPIRE](https://startwithidentity.com/vendors/machine-identity/spiffe-spire/)) or cloud workload identity; authenticate to the authorization server with [mTLS](https://startwithidentity.com/glossary/mtls/) (RFC 8705) or a signed JWT assertion (RFC 7523); for MCP agents acting as themselves, the OAuth Client Credentials extension | Shared API keys, static client secrets in agent config or prompts, one service account shared by many agents |
| On-behalf-of delegation | Authorization code with [PKCE](https://startwithidentity.com/glossary/pkce/) and a `resource` parameter, per MCP 2026-07-28; RFC 8693 [token exchange](https://startwithidentity.com/glossary/token-exchange/) at each boundary. ID-JAG via the MCP Enterprise-Managed Authorization extension is production-ready at some vendors but still a draft: pin to -06 | Token passthrough (MCP forbids servers from accepting or transiting tokens not issued for them); requesting `offline_access` by default; agents reusing the human's session |
| Async and autonomous consent | CIBA for out-of-band approval the agent initiates; RFC 9470 and MCP `insufficient_scope` challenges for step-up; a fresh, narrow grant for each high-risk action | Treating a "yes" in a chat window as authorization (AIMS: local UI confirmation alone is not sufficient); long-lived refresh tokens for unattended agents |
| Chained delegation | RFC 8693 exchange at every hop, down-scoped each time, keeping the `act` chain for logging; each hop enforces its own policy. Transaction Tokens (draft -11) inside one domain if you accept draft risk | Forwarding the inbound token downstream; making access decisions from nested `act` claims, which RFC 8693 says not to do |
| Fine-grained authorization | RFC 9396 `authorization_details` for high-value actions; an external policy decision point behind the AuthZEN 1.0 API at the MCP server or gateway; one scope per tool or action ([fine-grained authorization](https://startwithidentity.com/glossary/fga/)) | A single "agent" scope that grants every tool |
| Audience binding | RFC 8707 on every request, `aud` validation at every resource server, RFC 9728 metadata | Tokens valid at many audiences; skipping audience checks on internal services |
| Proof of possession | [DPoP](https://startwithidentity.com/glossary/dpop/) (RFC 9449) or certificate-bound tokens (RFC 8705) wherever your authorization and resource servers support them, documented by [Auth0](https://startwithidentity.com/vendors/ciam/auth0/) and Okta among others; otherwise lifetimes in minutes | Long-lived [bearer tokens](https://startwithidentity.com/glossary/bearer-token/) stored where the model's context or tools can read them |
| Revocation and signals | Short access-token lifetimes; RFC 7009 revocation of refresh tokens; SSF receivers on resource servers with [CAEP](https://startwithidentity.com/glossary/caep/) session-revoked and RISC account-disabled, using the agent as the subject | Relying on expiry alone with hour-long tokens |
| Registration and discovery | RFC 9728 plus RFC 8414; pre-registration for enterprise MCP clients; CIMD where the authorization server advertises `client_id_metadata_document_supported`; JWS-signed A2A Agent Cards | Open Dynamic Client Registration endpoints with no policy (and DCR is deprecated in MCP) |
| Agent lifecycle registry | No standard exists. Put agents in your existing [non-human identity](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/) inventory and governance: owner, purpose, expiry, review. A private [SCIM](https://startwithidentity.com/glossary/scim/) schema extension is reasonable inside one organization | Agents with no named owner; agents that outlive the project that created them |
| Audit and attribution | Log `sub`, `act`, `client_id`, resource, action, decision and a correlation ID on every call; use the AIMS minimum field list as a checklist; propagate one transaction ID across hops | Logs that show only a service account, so no one can tell which human the agent was acting for |

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](https://startwithidentity.com/articles/zero-standing-privileges-best-practices/) 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](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide walks through the program side, and the [AI agent identity tools ranking](https://startwithidentity.com/rankings/best-ai-agent-identity-tools/), the [non-human identity platforms ranking](https://startwithidentity.com/rankings/best-non-human-identity-security-platforms/), the [authorization tools ranking](https://startwithidentity.com/rankings/best-authorization-tools/) and the [AI identity vendor directory](https://startwithidentity.com/vendors/ai-identity/) cover products. For the underlying protocols see [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) and [agentic identity](https://startwithidentity.com/glossary/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](https://startwithidentity.com/data/reports/agent-identity-standards-2026.csv) or [JSON](https://startwithidentity.com/data/reports/agent-identity-standards-2026.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](https://startwithidentity.com/contact/) and are credited.