AI agent identity: the standards that actually ship

There is no AI agent identity standard. There are four layers of them, they answer different questions, they compose only partly, and of the four the Model Context Protocol has shipped exactly one.

Dates and document revisions were captured on 17 August 2026, and several of them move monthly. The OAuth flow underneath all of it is assumed background here; if you need it, MCP authorization covers OAuth 2.1, RFC 9728 discovery, the deprecation of dynamic client registration and step-up auth in detail.

What is an AI agent identity?

An agent identity is a first-class identity for an autonomous process, distinct from both the human who deployed it and the shared service account that a traditional workload would have used. Four properties separate it from the service account it replaces: it is not shared between workloads, so an action can be attributed; it cannot be impersonated, so a chain of delegation does not collapse; it has no exportable long-lived key to outlive the workload and leak into a repository; and it is created and destroyed on the timescale of a process rather than the timescale of a support ticket.

Governance is where that breaks down today. A Cloud Security Alliance and Oasis Security survey of 383 IT and security professionals, fielded across August and September 2025 and published on 27 January 2026, found that “92% of respondents are not confident that their legacy IAM solutions can effectively manage the risks associated with AI and NHIs”, and that “78% of organizations don’t have documented and formally adopted policies for creating or removing AI identities”. Read both figures for exactly what they say: the first is about legacy IAM tooling rather than IAM in general, and the second is about AI identities rather than agent identities specifically. It is a vendor-co-sponsored survey of self-reported confidence, which is the weakest kind of evidence on this page, and it is the only survey number I quote.

What are the four layers of agent identity?

Four layers, four questions, four different bodies of work.

Layer	Question it answers	Where it lives
Workload identity	What process is this?	SPIFFE/SPIRE, cloud workload identity federation, IETF WIMSE
Delegation	Whose authority is it exercising?	OAuth token exchange, identity chaining, transaction tokens
Per-request proof	Which key signed this specific call?	HTTP message signatures, mTLS, DPoP, Web Bot Auth
Governance	Who owns it, and who retires it?	IAM tooling, vendor control planes, and mostly nothing

Note what a layer cannot do for the one above it. A workload identity is a name; it says nothing about a user. A delegation token names a user; it says nothing about which binary is holding it. A per-request signature proves possession of a key; it carries neither a user nor a scope. Governance is the only layer with no protocol at all, which is why it is the layer the survey above finds missing.

The only architecture document any standards body has taken to working-group level across these layers is draft-ietf-wimse-arch (revision -08, posted 6 July 2026), from the IETF’s Workload Identity in Multi System Environments working group. Its companion draft-ietf-wimse-workload-identity-practices went to the IESG on 30 June 2026 and is in AD evaluation, with revision -06 posted on 11 August 2026 in answer to it. Everything else in this post is either an existing RFC being reused, or an individual submission.

Where does SPIFFE stop and OAuth start?

SPIFFE stops at the name.

SPIFFE, the Secure Production Identity Framework For Everyone, gives a workload a cryptographically verifiable name. Its own documentation defines that name as “a string that uniquely and specifically identifies a workload”, carried in a document it calls an SVID, “the document with which a workload proves its identity to a resource or caller”, issued as either an X.509 certificate or a JWT. SPIRE is “a production-ready implementation of the SPIFFE APIs that performs node and workload attestation in order to securely issue SVIDs to workloads”. Both projects graduated from the CNCF in a single announcement dated 20 September 2022, so this half of the problem has been production-grade for nearly four years. It is worth knowing that it predates the agent conversation entirely: across the SPIFFE homepage, project overview and concepts pages, the framing is “distributed systems” and “micro-services”, and AI agents are not mentioned.

What an SVID is not is a permission. A name is not an entitlement, and an SVID carries no user. A service that receives a valid X.509-SVID knows which workload connected and knows nothing about who that workload is acting for, or what it may do. Turning a verified name into a scoped access token is OAuth’s job, and the join between the two was left to each deployment to build.

That bridge now has a document number. draft-ietf-oauth-spiffe-client-auth (revision -02, 15 June 2026), adopted by the OAuth working group, defines how a workload presents an SVID to an authorization server as a client credential. X.509-SVID authentication “uses mutual TLS as defined in OAuth 2.0 Mutual-TLS Client Authentication [RFC8705], with specific adaptations for SPIFFE X.509-SVIDs”. JWT-SVID authentication “naturally follows the JWT Profile for OAuth 2.0 Client Authentication [RFC7523]”, carried with the assertion type urn:ietf:params:oauth:client-assertion-type:jwt-spiffe. The workload identity you already run becomes the thing that gets you a token, with no shared secret anywhere in the path.

A vendor claiming to have solved agent identity with SPIFFE has answered the first question of four.

How does an agent prove it is acting for a specific person?

By exchanging tokens, using two RFCs that both predate the current agent wave: RFC 8693 Token Exchange (January 2020) and RFC 7523 JWT bearer assertions (May 2015). An agent holding its own credential presents a token representing the user and receives a new token whose subject is the user and whose actor is the agent, recorded in the act claim.

RFC 8693 §4.1 describes nested act claims as “a history trail” and states plainly that “Prior actors identified by any nested act claims are informational only and are not to be considered in access control decisions.”

In terms of an agent chain: if a user delegates to an orchestrator, which delegates to a sub-agent, which calls your MCP server, the full chain is in the token and the specification forbids you from making an access decision on any link except the immediate actor. The delegation chain is a log, not a policy input. Any design that grants access because the chain shows the request originated with an approved orchestrator is doing what the specification tells you not to do.

Two working-group documents address the resulting gap. draft-ietf-oauth-transaction-tokens (revision -11, 30 July 2026, in working group last call) handles the in-domain case, preserving the original call context across internal hops. draft-ietf-oauth-identity-chaining (revision -17, 19 July 2026, in the RFC Editor queue) handles the cross-domain case, where the token has to cross a trust boundary between organisations. Both are real working-group output, and the second is close to being an RFC.

What does Cross App Access add on top of plain OAuth?

It moves the access decision to the enterprise identity provider, and it removes the consent screen.

Cross App Access, as Okta implements it, is draft-ietf-oauth-identity-assertion-authz-grant (revision -04, 21 May 2026). The flow: a client authenticated to the enterprise identity provider asks it for an identity assertion authorization grant, receiving an ID-JAG. The draft defines the requested token type plainly: “The value urn:ietf:params:oauth:token-type:id-jag indicates that an Identity Assertion JWT Authorization Grant is being requested.” That grant names both the user and the target resource. The client then spends the ID-JAG at the MCP server’s own authorization server as a jwt-bearer grant, and gets back an audience-restricted access token for that server alone.

No new cryptography is involved. Every primitive here already existed. What changes is who decides. In a plain OAuth flow, the user personally approves each connection at a consent screen, and the identity provider learns nothing about it. Under Cross App Access, the identity provider mints the grant, so an administrator can allow or deny an agent’s access to a given MCP server centrally, revoke it centrally, and see it in one place. The user is never asked, because the organisation already answered.

Okta’s press release of 18 June 2026 describes Cross App Access as “an open protocol led by Okta that extends OAuth to secure agent-to-app and app-to-app access and is an official authorization extension within MCP listed under the name ‘Enterprise Managed Auth.’” Okta’s Cross App Access product page claims “25+ early adopters including Anthropic, Zoom, and Slack”; that page carries no publication date, so treat the count as a current vendor claim rather than a dated one. One clarification that is easy to get wrong: this is an optional, independently versioned extension living in a separate repository, not part of the core MCP specification.

Which identity standards has MCP actually adopted?

One is stable. Several are open. One is dead. The audit, captured on 17 August 2026:

Stable. The extension known as Enterprise-Managed Authorization, proposed as SEP-990 (“Enable enterprise IdP policy controls during MCP OAuth flows”, accepted and closed on 3 November 2025). It lives in the ext-auth repository, and the commit promoting it to stable landed on 17 June 2026, with review follow-ups merging the next day. SDK support followed: python-sdk#2988 merged on 26 June 2026 and ruby-sdk#454, opened 13 July, merged on 15 July 2026. The reverse-DNS id io.modelcontextprotocol/enterprise-managed-authorization is not in the spec text itself; it is declared in the conformance suite. This is the Cross App Access flow above, and it is the single agent identity mechanism MCP has actually shipped.

Draft. oauth-client-credentials, for machine-to-machine agents with no user in the loop, marked “Protocol Revision: draft”. It offers two client authentication methods, private_key_jwt marked RECOMMENDED and client_secret_basic alongside it, so the better path does avoid a shared secret. What it does not do is attest anything: the words SPIFFE, SPIRE, workload and federation appear nowhere in it. An agent using this extension is an OAuth client holding a credential, not a workload whose identity was established by anything outside itself.

Open since 5 December 2025. SEP-1932 proposes a DPoP profile, binding tokens to a proof key so a stolen bearer token is not enough. SEP-1933 proposes workload identity federation, noting that workloads “in environments such as Kubernetes, SPIFFE/SPIRE, and cloud-native runtimes already receive short-lived, cryptographically verifiable JWTs”. Both are still open pull requests. The client conformance issue for SEP-1933 was opened on 10 April 2026 and is also still open.

Dead. SEP-1415 would have brought HTTP message signing to MCP client authentication. It was closed on 26 January 2026 with the maintainer’s note that “this proposal has been open for over 5 months without finding a sponsor from the core maintainer team”. A successor, SEP-2752, was opened on 19 May 2026 and has not landed either.

Adjacent. The OpenID Foundation announced on 15 June 2026 that “The AuthZEN Working Group has approved the AuthZEN Access Request and Approval Profile (AARP) and AuthZEN Profile for Model Context Protocol Tool Authorization (COAZ) official Working Group Drafts.” COAZ has since been split in two: a protocol-neutral framework, which “does not define a mapping for any specific protocol”, and a separate MCP binding that “defines how MCP JSON-RPC messages are mapped into requests to the OpenID AuthZEN Authorization API”. So COAZ is the framework; the MCP binding is the part that touches MCP. Both are still labelled Draft 1.

So: delegation shipped, workload identity is an unmerged proposal, per-request proof was abandoned, governance was never in scope. One layer of four.

Does Web Bot Auth solve agent identity?

No. It is the most visible thing in this space and it answers the narrowest of the four questions.

Web Bot Auth has an automated client sign each outbound HTTP request with an RFC 9421 message signature. A Signature-Agent header names the directory where the signer’s public keys live, published at /.well-known/http-message-signatures-directory; Cloudflare’s implementation notes tell an operator to “Host a key directory at /.well-known/http-message-signatures-directory” and that “Cloudflare accepts all valid Ed25519 keys found in your key directory”. The receiving site fetches that directory, verifies the signature, and now knows which software sent the request. Cloudflare launched Signed Agents on 28 August 2025 and proposed a registry format on 30 October 2025. On the same day, AWS put Web Bot Auth into AgentCore Browser in preview only.

The specification work is draft-meunier-webbotauth-httpsig-protocol (revision -01, 6 August 2026), plus draft-meunier-webbotauth-httpsig-directory (-00) and draft-meunier-webbotauth-registry (-03), both dated 26 June 2026. Note the surname in each name: these are individual submissions.

What a Web Bot Auth signature contains is a key and nothing else. No user, no scope, no expiry tied to a session. It can tell you which vendor’s crawler is at the door. It cannot tell you whether that crawler may read a named user’s calendar. Those are different questions asked by different parties, which is why the two mechanisms compose rather than compete: a single request can carry a Web Bot Auth signature proving which software is calling and an OAuth access token proving whose authority it holds, and a server can require both.

If you are the site being crawled, Web Bot Auth is what you want.

Do Microsoft, AWS and Google agree on what an agent identity is?

No. Three vendors have shipped agent identity into general availability, and they have shipped three different objects with three different wire formats.

Microsoft models an agent identity as a special service principal that “doesn’t have credentials on its own”. The genuinely new object is the agent identity blueprint, a Graph resource (agentIdentityBlueprint, in v1.0 and beta) that “serves as a template for creating agent identities” and holds the credentials the identities themselves lack. An optional agent user account is “a specialized subtype of user identity”, receiving “tokens with idtyp=user claims”, in a relationship the Entra documentation calls “immutable” and “a one-to-one (1:1) mapping”, and which “can’t have credentials like passwords or passkeys” and “can’t be assigned privileged administrator roles”. Protocol support is “OAuth 2.0 protocols with specialized token exchange patterns enabled by Federated Identity Credentials (FIC)”, across client_credentials, jwt-bearer and refresh_token; “Agents aren’t supported for interactive (/authorize) flows” and “Public client capabilities aren’t available”, so every Entra agent is a confidential client by construction. The Entra release notes record the Agent ID platform reaching general availability in April 2026, with no day given. Agent 365 followed: “As of May 1, 2026, Microsoft Agent 365 is generally available for the Commercial segment on a per user basis.” Its pricing page lists the standalone SKU at “$15.00 user/month, paid yearly (Annual commitment)”, so the charge is per user on an annual commitment rather than per agent. Conditional Access for agents “requires Microsoft Entra ID P1 or P2 and a Microsoft Agent 365 license for each user”, though that same page adds that “Enforcement of Agent 365 licensing is coming soon”.

AWS implements agent identities as workload identities: “Agent identities are implemented as workload identities with specialized attributes that enable agent-specific capabilities”, per the AgentCore Identity documentation. They are paired with a token vault that “ensures credentials can only be accessed by the specific agent and user combination that originally obtained them”, encrypted with AWS owned keys by default and customer managed keys optionally. On inbound authentication, AWS is explicit that a runtime “can support either IAM SigV4 or JWT Bearer Token based inbound auth, but not both simultaneously”. AgentCore Identity became generally available as part of AgentCore’s overall GA on 13 October 2025; there was no Identity-only GA.

Google builds on SPIFFE without exposing a SPIFFE URI. Its Agent Runtime documentation says “Agent identity is based on SPIFFE” and gives agents a name of the form principal://TRUST_DOMAIN/NAMESPACE/AGENT_NAME, adding: “We also auto-provision and manage an x509 certificate on the agent with the same identity for secure authentication.” The IAM overview puts the object in the negative, “Unlike service accounts, agent identities are not shared by multiple workloads by default, can’t be impersonated, and don’t allow developers to generate long-lived service account keys”, and supplies the rotation period, “Each X.509 certificate is valid for 24 hours, and Google Cloud automatically keeps it current to maintain security”, and the transport rules: agents “use mutual TLS (mTLS) with X.509 certificates when communicating directly with Google Cloud APIs”, and “When agents interact across the Agent Gateway, they also use Demonstrating Proof of Possession (DPoP), creating double-bound credentials”. The platform was announced at Cloud Next ‘26 on 22 April 2026, and Google announced general availability on 30 July 2026: “some of our most popular capabilities are available for everyone, from Agent Runtime to Agent Identity.”

Three vendors, three formats: a directory object, a workload identity with a vault, and a SPIFFE-derived principal:// name. An MCP server that wants to accept agents from all three writes three integrations.

How do you verify the identity of the MCP server itself?

This is the direction nobody is standardising, and it is the one we spend our time on.

Every mechanism above answers a question about the client. The reverse question, how a server proves it is what it claims to be, has one partial answer and one absence. A2A’s Agent Card can carry signatures: §8.4 of the specification says “Agent Cards MAY be digitally signed using JSON Web Signature (JWS) as defined in RFC 7515 to ensure authenticity and integrity”, with an AgentCardSignature object, JCS canonicalisation, and a MutualTlsSecurityScheme alongside it. Note the MAY: this is a capability, not a requirement. A2A reached 1.0.0 on 12 March 2026 and 1.0.1 on 28 May 2026.

MCP’s Server Card has none of that. SEP-2127, “MCP Server Cards - HTTP Server Discovery”, was opened on 21 January 2026 and is still an open pull request labelled in-review, with a reference implementation in experimental-ext-server-card. Its schema.json defines exactly seven types, Icon, Input, KeyValueInput, MetaObject, Remote, Repository and ServerCard, and contains no signature, JWS, JWKS, X.509 or attestation field of any kind. The schema says so itself: the fields a card declares are “advisory, not authoritative”, and “clients must not treat them as authoritative for security decisions”. The ambition was scaled back visibly. SEP-2267, “MCP Server Identity and Tool Attestation”, was closed unmerged on 21 February 2026 with the maintainer’s note that it “would be better suited for the Auth Extensions”, and its follow-up in ext-auth is still open. The group itself was renamed from the Server Identity WG to the Server Card WG in a pull request opened on 31 May and merged on 1 June 2026.

A server card is a set of self-assertions with nothing binding them to a signer, so a client reading one learns what the server says about itself. When a protocol declines to let a server prove who it is, something outside the protocol has to observe it instead: probing the endpoint, checking the package that claims to implement it, and recording what was true at a given moment. That is the work our directory exists to do.

What is still unsolved in agent identity?

Almost all of it. One measurement makes the point.

On 17 August 2026 the IETF datatracker held 158 active Internet-Drafts with “agent” in the document name, by this API query. Widen that to drafts matching “agent” in the name or title and keep only those about identity, delegation, authorization or attestation, and the count is roughly 170. Both figures move week to week, so re-run the query rather than trusting mine. What does not move is the composition: not one of those proposals is an adopted draft-ietf-* working-group document. Every draft-ietf-* name containing “agent” is either expired or already an RFC, and they concern SNMP subagents, DHCP relay agents, SSH agents and Diameter agent overload rather than AI. From draft-sharif-openid-agent-identity (-00, 26 March 2026) to draft-fane-opena2a-aip (-02, 6 August 2026), draft-mcguinness-oauth-ai-agent-instance (-00, 5 July 2026), draft-sweeney-wimse-credential-delegation (-00, 28 July 2026) and draft-reece-wimse-cross-org-delegation (-01, 30 July 2026), every one is an individual submission.

The picture at Web Bot Auth is the same. The IETF webbotauth working group is properly chartered, with David Schinazi and Rifaat Shekh-Yusef as chairs, and on 17 August 2026 it had adopted zero documents against ten active individual drafts.

Elsewhere the artefacts are earlier still. NIST’s NCCoE published a concept paper, “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization”, on 5 February 2026, with comments closing on 2 April 2026. That is an open question rather than an answer. The Cloud Security Alliance’s “Agentic AI Identity and Access Management: A New Approach” of 18 August 2025 proposes decentralised identifiers, verifiable credentials and zero-knowledge proofs, describing verifiable credentials as “digitally signed attestations about an agent, issued by a trusted entity”. It is a recommendation, not a shipping standard, and MCP implements none of it.

The organisational picture is younger than it looks. The Agentic AI Foundation was formed on 9 December 2025 “with founding contributions of leading technical projects including Anthropic’s Model Context Protocol (MCP), Block’s goose, and OpenAI’s AGENTS.md”. On 23 June 2026 the Linux Foundation “announced the intent to launch the Agent Name Service (ANS)”, building on research originating in OWASP. Intent, not launch. The OpenID Foundation’s whitepaper of 7 October 2025, “Identity Management for Agentic AI”, was “researched and compiled by the OpenID Foundation’s Artificial Intelligence Identity Management Community Group”, a Community Group rather than a working group; the protocol work there sits in AuthZEN.

If you are building now, build on the two RFCs and the one shipped extension, and treat everything with a surname in its draft name as a signal of where the industry is looking rather than what it has agreed.

Where to go next

• The OAuth flow underneath all of this: MCP authorization covers OAuth 2.1, RFC 9728 discovery, resource indicators and why dynamic client registration is deprecated.
• The failure modes delegation is meant to prevent: MCP security best practices covers the confused deputy problem and token passthrough, which are what a missing delegation layer looks like in production.
• Where delegation actually gets enforced: MCP gateway covers the component that usually ends up holding the tokens, and what it hides about the servers behind it.
• What a specific server does today: browse the directory and read the evidence for the endpoint you are about to connect an agent to.

The layer framing is the thing to keep. When something is described as agent identity, ask which of the four questions it answers, and assume it answers exactly one.