Agent identity standards are being written right now, across several bodies at once. Protocols for connecting agents to tools and to each other, OAuth extensions for delegation, workload identity for agents, authorisation APIs, agent authentication for payments, and government guidance are all moving in parallel. Some are published and stable; many are drafts that will change between one review and the next. This tracker summarises where the main standards and initiatives stand, the exact version or stage we verified, what each means for identity and security teams, and what to watch next. It is for architects, identity engineers and security leads deciding what to build on now. Always check the linked primary source before relying on a specific requirement.
Last reviewed: 20 October 2026
Key takeaways
- Build on existing standards: the IETF, OpenID Foundation, MCP and NIST are all applying OAuth, OpenID and workload identity (including SPIFFE) to agents rather than inventing a separate identity system.
- Stable enough to use now: the core OAuth RFCs (token exchange, resource indicators, protected resource metadata, DPoP, mTLS, security best current practice), the MCP authorisation specification, A2A 1.0, SPIFFE, OpenID AuthZEN Authorization API 1.0, the Shared Signals Framework, CAEP and RISC Final specifications, and the OWASP NHI and Agentic Top 10 lists.
- Moving fast: MCP's 2026-07-28 revision made the protocol stateless and tightened client registration and issuer checks; OAuth identity chaining has reached the RFC Editor queue; transaction tokens are awaiting write-up after working group consensus.
- Still early: multi-hop delegation semantics, agent-specific workload identity, agent registries, agent payment intent and NIST agent identity guidance remain at draft or concept stage.
- Design for change: prefer open-standards products, record which features depend on drafts, and plan to adopt new revisions.
Status key
- Published: final standard, RFC, OpenID Final Specification or dated specification revision.
- In publication: approved by its working group and the IESG or equivalent, waiting for the RFC Editor.
- Draft: working draft, working group draft or Internet-Draft. Expect changes.
- Initiative: programme, working group or community group without a finished specification.
- Guidance: framework, profile or list intended to inform practice rather than define a protocol.
- Law: legislation with staged application dates.
In this review we re-checked every entry against the standard's own current page. Main corrections: the Shared Signals Framework itself is now Final, the MCP authorisation changes previously listed as planned are in the current revision, and the EU AI Act amendments are in force.
Agent protocols
| Standard | Body | Status (verified) | Identity and security relevance |
|---|---|---|---|
| Model Context Protocol (MCP) | Agentic AI Foundation (Linux Foundation); created by Anthropic | Published; date-versioned revisions. Current revision 2026-07-28 (previous 2025-11-25) | Authorisation for HTTP transports builds on OAuth 2.1: servers must publish Protected Resource Metadata (RFC 9728); clients must send the resource parameter (RFC 8707); servers must validate that tokens were issued for them and must not pass tokens through to upstream APIs. Client ID Metadata Documents are the recommended registration method and Dynamic Client Registration is deprecated. See the MCP Security Guide. |
| MCP 2026-07-28 changes that matter for identity | As above | Published | Protocol-level sessions removed; every request carries its protocol version and client capabilities. Clients must validate iss (RFC 9207) when present. Client credentials are bound to the issuing authorisation server and must not be reused with another. |
| MCP authorisation extensions | MCP project | Enterprise-Managed Authorization: Stable. Client Credentials: Draft | Enterprise-Managed Authorization lets an MCP client obtain tokens through the enterprise identity provider using the Identity Assertion JWT Authorization Grant, giving administrators control over which MCP servers can be used. |
| Agent2Agent (A2A) | Linux Foundation; contributed by Google | Published; version 1.0.0 released 12 March 2026, patch 1.0.1 on 26 May 2026 (per the project changelog) | Agent discovery via Agent Cards at a well-known URI; declared security schemes (API key, HTTP, OAuth 2.0, OpenID Connect, mTLS); optional Agent Card signing with JWS after RFC 8785 canonicalisation. The specification states that an "auth required" task state is not, by itself, authorisation for any operation. See the Multi-Agent and A2A Security Guide. |
| Agentic AI Foundation (AAIF) | Linux Foundation | Initiative; formed 9 December 2025 | Neutral home for MCP, goose and AGENTS.md. Governance of MCP now sits here. |
What this means in practice: pin the MCP revision your clients and servers implement, check whether your authorisation server returns iss, and plan the move away from Dynamic Client Registration. For A2A, require signed Agent Cards from external agents.
OAuth and IETF
| Standard | Status (verified) | Relevance to agents |
|---|---|---|
| RFC 8693 OAuth 2.0 Token Exchange | Published | Per-hop token exchange and the act claim for recording who acts on whose behalf; the basis of most agent delegation patterns. See the OAuth Token Exchange and Delegation Guide. |
| RFC 8707 Resource Indicators and RFC 9728 Protected Resource Metadata | Published | Audience-bound tokens and resource discovery; both required by the MCP authorisation specification. |
| RFC 9207 Authorization Server Issuer Identification | Published | The iss response parameter that defends against mix-up attacks; now referenced by MCP. |
| RFC 9449 DPoP and RFC 8705 OAuth mTLS | Published | Sender-constrained tokens, so stolen agent tokens cannot be replayed. See the Token and Session Security Guide. |
| RFC 9396 Rich Authorization Requests | Published | Fine-grained, task-specific authorisation details instead of broad scopes. |
| RFC 9700 OAuth 2.0 Security Best Current Practice | Published; an update draft (-03) is a working group document | Baseline security requirements for any OAuth deployment involving agents. |
| OAuth 2.1 | Draft (-16, September 2026); working group milestone December 2026 | Consolidates OAuth 2.0 with current security practice; the base of MCP authorisation. |
| OAuth Client ID Metadata Document | Draft (-02, July 2026) | Lets a client use an HTTPS URL as its client ID; the registration method MCP recommends. |
| OAuth Identity and Authorization Chaining Across Domains | In publication (-17): submitted to the IESG as a Proposed Standard and in the RFC Editor queue | Preserves identity and authorisation across trust domains by combining token exchange with a JWT authorisation grant; the foundation for cross-domain agent delegation. |
| Identity Assertion JWT Authorization Grant | Draft (-04, May 2026) | Uses an SSO identity assertion, via the enterprise identity provider, to obtain a token for a third-party API (Cross-App Access); profiled by MCP Enterprise-Managed Authorization. |
| Transaction Tokens | Draft (-11, July 2026); working group consensus, waiting for write-up | Propagates user identity, workload identity and authorisation context through a call chain inside one trust domain, for example when an agent request fans out across internal services. |
| OAuth SPIFFE Client Authentication and attestation-based client authentication | Drafts (-02, June 2026; -12, October 2026, working group consensus) | Lets workloads and agents authenticate to authorisation servers with SPIFFE SVIDs or attestations instead of client secrets. |
| WIMSE working group (Workload Identity in Multi System Environments) | Drafts: architecture (-08), workload credentials, workload proof token, HTTP signatures and mutual TLS; workload identity practices (-07) is with the IESG as Informational | Workload identity and workload-to-workload authentication across platforms, the layer agent identity proposals build on. |
| AI Identity Management System | Draft (draft-ietf-wimse-aims-00, 15 September 2026); adopted as a WIMSE working group document, intended Informational | Best practice for authenticating and authorising AI agent interactions using WIMSE and the OAuth family, without new protocols, and identifying gaps for future standards. Many individual drafts on agent delegation chains have also been submitted; they have no standing until adopted (see the WIMSE documents list). |
What this means in practice: token exchange, resource indicators, sender-constrained tokens and RFC 9700 are safe foundations today. See the OAuth 2.0 and OpenID Connect Guide.
OpenID Foundation
| Standard | Status (verified) | Relevance to agents |
|---|---|---|
| AuthZEN Authorization API 1.0 | Published (Final Specification, approved January 2026) | Standard interface between policy enforcement points and policy decision points using a subject, action, resource and context model. See the AI Agent Authorisation Guide. |
| AuthZEN AARP and COAZ | Draft (approved as Working Group Drafts, June 2026); COAZ Framework and COAZ-MCP Binding drafts announced July 2026 | AARP defines how to request, track and satisfy prerequisites (approval, consent, delegated authority, attestation) before policy can authorise an action. COAZ maps MCP tool calls and other protocols into AuthZEN requests, so gateways can ask a policy engine whether a tool call is allowed. |
| AI Identity Management Community Group | Initiative | Use cases, taxonomy and threat modelling for agent identity, delegation, discovery and governance. Protocol work is out of scope and is passed to OpenID or liaison working groups. |
| CIBA Core 1.0 | Published (Final) | Decoupled, out-of-band user approval, usable for human approval of high-risk agent actions. |
| Shared Signals Framework, CAEP and RISC | Published: all three approved as Final Specifications, September 2025 | Pushing session revocation, credential change and risk events between services, supporting fast agent containment. NIST IR 8587 (September 2026) recommends SSF and CAEP, according to the OpenID Foundation. |
What this means in practice: externalising agent tool authorisation behind an AuthZEN-style decision point is now a standards-backed pattern; add CIBA or AARP-style approval for high-risk actions and CAEP events so a revoked user session also stops that user's agents.
Workload identity
| Standard | Status (verified) | Relevance to agents |
|---|---|---|
| SPIFFE and SPIRE | Published; graduated Cloud Native Computing Foundation projects | Strongly attested, cryptographic workload identities usable as the foundation for agent identity, and increasingly referenced by OAuth drafts (SPIFFE client authentication) and WIMSE. See the AI Infrastructure Workload Identity Guide. |
| Cloud workload identity federation | Vendor implementations | Keyless authentication for agents running in cloud and CI/CD. See the Workload Identity Federation Guide and the Cloud Workload Identity Guide. |
Agent authentication and commerce
| Standard or initiative | Status (verified) | Relevance |
|---|---|---|
| FIDO Alliance agentic working groups | Initiative (announced 28 April 2026); no draft specification found at this review | The Agentic Authentication Technical Working Group covers how users delegate actions to agents with phishing-resistant authentication and clear boundaries between user-initiated and agent-initiated actions. The Payments Technical Working Group covers agent-initiated commerce. |
| Agent Payments Protocol (AP2) | Contributed by Google to the FIDO Alliance (April 2026); Google published AP2 v0.2 on GitHub at the same time, according to coverage reproduced by the FIDO Alliance | Secure delegation, verifiable authorisation and transaction execution; v0.2 adds "Human Not Present" purchases made on pre-authorised instructions. |
| Verifiable Intent | Contributed by Mastercard to the FIDO Alliance (April 2026); developed with Google | A shared, tamper-evident record of user-approved actions that the payments ecosystem can rely on. |
| Agentic Commerce Protocol (ACP) and Universal Commerce Protocol (UCP) | Industry specifications (open source) | Checkout and commerce flows between buyers, agents and businesses. UCP states built-in support for AP2, A2A and MCP. Relevant where agents buy on behalf of users or customers. See the Agentic Commerce Identity Guide. |
| W3C Agent Identity Registry Protocol Community Group | Initiative (launched 24 April 2026); no reports published at this review | Scope includes a DID method for agent identity resolution, an agent credential format based on W3C Verifiable Credentials, cross-organisation trust negotiation, and profiles for MCP, A2A, OAuth/OIDC and SPIFFE. |
Government guidance and regulation
| Item | Status (verified) | Relevance |
|---|---|---|
| NIST NCCoE concept paper: Software and AI Agent Identity and Authorization | Initiative (concept paper published 5 February 2026; comments closed 2 April 2026); no draft project description found at this review | Proposed demonstration applying identity standards to enterprise agents: identification, authorisation, auditing, non-repudiation and prompt injection controls. |
| NIST CAISI AI Agent Standards Initiative | Initiative (launched 17 February 2026) | Pillars: industry-led agent standards, open-source protocols, and agent security and identity research. |
| NIST IR 8596 Cyber AI Profile | Draft (initial preliminary draft, 16 December 2025; comments closed 30 January 2026) | Maps AI considerations onto CSF 2.0 outcomes in three focus areas: Secure, Defend and Thwart. |
| NIST SP 800-53 Control Overlays for Securing AI Systems (COSAiS) | Draft (concept paper August 2025; annotated outline January 2026) | Planned overlays include single-agent and multi-agent AI agent systems. |
| NIST IR 8587 Protecting Tokens and Assertions | Published (September 2026) | Implementation recommendations against token and assertion forgery, theft and misuse. |
| NIST AI RMF 1.0 and AI 600-1 Generative AI Profile | Published (January 2023; July 2024) | Voluntary AI risk management framework and its generative AI profile. See the NIST AI RMF Guide. |
| EU AI Act (Regulation (EU) 2024/1689), as amended by the AI Omnibus | Law; staged application. The AI Omnibus entered into force on 27 July 2026 | Generally applicable from 2 August 2026, including transparency rules; high-risk obligations from 2 December 2027 (Annex III areas) and 2 August 2028 (Annex I products). The first harmonised standard supporting the Act was published in the Official Journal on 19 October 2026, according to the Commission. See the EU AI Act Compliance Guide. |
| ISO/IEC 42001:2023 | Published | Certifiable AI management system standard; accredited certification bodies certify against it. |
Security guidance
| Item | Status (verified) | Relevance |
|---|---|---|
| OWASP Top 10 for Agentic Applications (2026) | Guidance (published December 2025) | ASI01 Agent Goal Hijack to ASI10 Rogue Agents; ASI03 Identity and Privilege Abuse and ASI07 Insecure Inter-Agent Communication are the most identity-specific. See the Top 10 Agentic AI Identity Issues. |
| OWASP Non-Human Identities Top 10 (2025) | Guidance | Risks in the credentials agents rely on, from improper offboarding and secret leakage to long-lived secrets and NHI reuse. |
| OWASP Top 10 for LLM Applications 2026 | Guidance (published 3 August 2026) | Model-level risks with updated rankings, mapped to NIST, MITRE ATLAS, CWE and the Agentic Top 10. See the OWASP Top 10 for LLM Applications Guide. |
| OWASP Agent Control Standard (ACS) | Guidance (joined the OWASP GenAI Security Project, 1 September 2026) | Defines how agent platforms expose middleware hooks so safety policies can be enforced at runtime. |
| CSA MAESTRO | Guidance (2025) | Threat modelling framework for agentic AI built on a seven-layer reference architecture. See the AI Agent Threat Modelling Guide. |
| MITRE ATLAS | Guidance (knowledge base; data published on GitHub) | Adversary tactics and techniques against AI systems. |
What to watch next
- Identity chaining becomes an RFC: the cross-domain chaining draft is in the RFC Editor queue. Once published, expect identity providers and the Identity Assertion JWT Authorization Grant to build on it.
- Transaction tokens and OAuth 2.1: transaction tokens are awaiting write-up after working group consensus, and OAuth 2.1 carries a December 2026 milestone.
- Multi-hop delegation semantics: whether OAuth drafts, the new WIMSE AI identity management draft and AuthZEN AARP converge on one way to carry "user, via agent A, via agent B" with attenuated authority at each hop.
- WIMSE AI Identity Management System: now a working group document. Its gap list will shape the next round of agent identity standards.
- MCP after 2026-07-28: adoption of the stateless protocol and the issuer checks by SDKs and hosted servers; and whether the Client Credentials authorisation extension becomes stable.
- Agent registries and verifiable agent credentials: first reports from the W3C Agent Identity Registry Protocol Community Group and use cases from the OpenID AI Identity Management Community Group.
- AuthZEN for agents: progress of AARP and COAZ towards Implementer's Drafts,.
- FIDO agentic working groups: first drafts on agent authentication and payment intent, building on AP2 and Verifiable Intent.
- NIST: a draft project description from the NCCoE agent identity project, the initial public draft of the Cyber AI Profile, the first COSAiS agent overlays, and further CAISI deliverables.
- EU AI Act: more harmonised standards following the first one published in October 2026, Commission guidance ahead of the December 2027 and August 2028 high-risk dates, and the new prohibitions applying from 2 December 2026.
How to use this tracker
- Build on published standards now: they are unlikely to change materially.
- Prototype with drafts, behind interfaces: isolate draft-dependent code (identity chaining, transaction tokens, Client ID Metadata Documents, AP2) so a new revision means changing an adapter, not the architecture.
- Ask vendors which features depend on drafts and how they will follow changes (including MCP revision and OAuth draft numbers). See the AI Agent Identity Security Buyer's Guide.
- Use the security lists for threat modelling, not compliance: map agent designs to the OWASP Agentic and NHI Top 10s and MAESTRO, then choose controls. See the Agentic AI Compliance Guide for the regulatory side.
- Re-check the primary sources before audits, RFPs and architecture decisions.
Status information is based on the linked primary sources and public announcements as at the review date, and may have changed since. Related NHI Mgmt Group resources: Agentic AI Identity Guide · NHI Authentication Guide · Agentic AI Security Guide · Zero Trust for AI Agents Guide