The State of AI Agent Identity, 2026

Executive summary

The short version: agent identity moved from research papers to shipping products in 2025 and 2026, but the work split along several lines that do not yet connect. Request signing, naming, enterprise directories, payment networks and agent-to-agent protocols each identify something slightly different, and none of them on its own tells a stranger who authorized an agent to act. Which agent is acting is not the same question as what it is allowed to do, and most of the unresolved work sits in the gap between the two.

• Request-level bot and agent authentication is converging on HTTP Message Signatures (RFC 9421, February 2024). The IETF now has an active Web Bot Auth working group, and its first working-group draft is dated September 1, 2026 (IETF datatracker).
• Agent naming is being proposed at the IETF as individual submissions only: the Agent Name Service v2 draft, revision 01, dated April 13, 2026, lists a GoDaddy author and is not a working-group document (IETF datatracker).
• Agent-to-agent and agent-to-tool protocols moved to neutral foundations: A2A to the Linux Foundation on June 23, 2025 (Linux Foundation) and MCP to the new Agentic AI Foundation on December 9, 2025 (Linux Foundation). MCP's own specification still states that authorization is optional (MCP specification).
• Enterprise identity vendors now treat agents as their own identity type: Microsoft announced Entra Agent ID on May 19, 2025 (Microsoft Security blog), and Auth0 announced Auth0 for AI Agents on September 25, 2025 (Auth0).
• Payment networks each built their own agent trust layer in 2025: Mastercard Agent Pay (April 29), Google's AP2 (September 16) and Visa's Trusted Agent Protocol (October 14), the last built on HTTP Message Signatures and aligned with Web Bot Auth (Visa).
• Regulation arrived on disclosure, not identity: the EU AI Act's Article 50 transparency rules apply from August 2, 2026, according to the European Commission (European Commission). They require telling people they are dealing with an AI system; they do not define a portable agent identifier.
• The US federal standards body framed the open problems as questions rather than answers: NIST's NCCoE concept paper of February 5, 2026 asks how to handle key revocation, delegation for on-behalf-of scenarios, and binding agent identity to human identity (NIST CSRC).

Why agent identity became a question in 2025–2026

The first signal is the plumbing. Anthropic introduced the Model Context Protocol on November 25, 2024 as "an open standard for connecting AI assistants to the systems where data lives" (Anthropic). By the time MCP was contributed to the Linux Foundation's new Agentic AI Foundation on December 9, 2025, the foundation's announcement stated there were "more than 10,000 published MCP servers" (Linux Foundation). That figure is the foundation's own count, not an independent census, but it shows how many new endpoints an agent can now reach.

The second signal is agent-to-agent traffic. Google launched the Agent2Agent protocol on April 9, 2025 with, in its words, "support and contributions from more than 50 technology partners" (Google Developers Blog). When the Linux Foundation took the project on at Open Source Summit North America on June 23, 2025, its release cited "growing support from more than 100 leading technology companies" (Linux Foundation). Both counts are the sponsors' own.

The third signal is enterprise adoption, where the best available numbers are surveys and forecasts rather than measurements. McKinsey's "The state of AI in 2026" survey, with 1,719 respondents fielded May 4 to June 8, 2026, reports that 40 percent of respondents from organizations with more than $1 billion in annual revenue say they are scaling AI agents, up from 27 percent a year earlier, while the share at smaller organizations stayed at 22 percent (McKinsey). Gartner, in an August 26, 2025 forecast, predicted that 40 percent of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5 percent at the time of the release (Gartner). That is a prediction, not an observed figure.

The fourth signal is the web itself. Cloudflare argued on May 15, 2025 that user-agent strings and IP ranges were too weak to tell bots and agents apart, and proposed that "developers of bots and agents cryptographically sign requests originating from their service" (Cloudflare). By August 28, 2025 it had named an initial cohort of "signed agents" that included OpenAI's ChatGPT agent, Block's Goose, Browserbase and Anchor Browser (Cloudflare).

Researchers had framed the problem earlier. A June 2024 paper proposed identifiers for individual AI system instances, arguing that "IDs seem most warranted in settings where AI systems could have a large impact upon the world, such as in making financial transactions or contacting real humans" (Chan et al., arXiv). A January 2025 paper proposed extending OAuth 2.0 and OpenID Connect for "authenticated, authorized, and auditable delegation of authority to AI agents" (South et al., arXiv). The OpenID Foundation's October 7, 2025 whitepaper concluded that existing standards can secure many current agent use cases but warned that "the window for establishing robust, interoperable standards is now, before proprietary solutions fragment the ecosystem" (OpenID Foundation).

The standards landscape

Standards work is spread across at least five venues. They do not all identify the same thing: some identify a request, some a server, some a named service, some a credential holder. The table records each initiative's status as its own publisher states it on the date of research; the citations follow in the paragraphs below.

HTTP Message Signatures. RFC 9421, published February 2024 on the Standards Track, defines how to sign selected components of an HTTP message so the signature survives intermediaries. It is the base layer most request-signing proposals for agents build on, including Web Bot Auth and Visa's Trusted Agent Protocol.

Web Bot Auth. The IETF Web Bot Auth working group is active; its charter covers "cryptographically authenticating automated clients and providing additional information about their operators to Web sites" and lists search crawlers, archivers, link checkers and AI training crawlers as in scope (IETF webbotauth charter). The earlier individual drafts were replaced by the working-group draft draft-ietf-webbotauth-httpsig-protocol-00, dated September 1, 2026, which defines a Signature-Agent header for key discovery, a JWKS-based key directory and a well-known URI to serve it (IETF datatracker). Cloudflare announced on July 1, 2025 that it validates these signatures at its edge as part of its Verified Bots program (Cloudflare).

Agent Name Service. The first ANS draft (draft-narajala-ans-00, May 16, 2025) proposed a DNS-based directory for agent discovery using PKI certificates and is now expired (IETF datatracker). Its successor, ANS v2 (draft-narajala-courtney-ansv2-01, April 13, 2026), describes "a domain-anchored trust layer" that anchors each agent to a verified DNS domain, issues dual certificates and records lifecycle events in a transparency log; it is an individual submission with authors from GoDaddy, OWASP, DistributedApps.ai and Cisco (IETF datatracker). Individual drafts carry no IETF endorsement.

W3C Decentralized Identifiers and Verifiable Credentials. DID Core became a W3C Recommendation on July 19, 2022 and describes DIDs as identifiers that enable "verifiable, decentralized digital identity" without a central registry (W3C). Verifiable Credentials Data Model 2.0 became a W3C Recommendation on May 15, 2025 (W3C). Neither is agent-specific, but both are general tools that agent systems reuse; Google's AP2, for example, signs its payment mandates with verifiable credentials.

A2A Agent Cards. The A2A specification, at version 1.0.0 on its site, defines an Agent Card as "a JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements" and includes an AgentCardSignature object with canonicalization rules (A2A specification). Cards are discovered at /.well-known/agent-card.json on the agent server's domain (A2A discovery guide). An Agent Card describes a server; the protocol leaves client authentication to schemes the card declares, such as OAuth 2.0, OpenID Connect or mutual TLS.

MCP authorization. The current MCP specification revision (2026-07-28) provides authorization "at the transport level" for HTTP transports, built on the OAuth 2.1 draft, OAuth Protected Resource Metadata (RFC 9728), Resource Indicators (RFC 8707) and, newly, OAuth Client ID Metadata Documents; Dynamic Client Registration is now marked deprecated. It also states plainly: "Authorization is OPTIONAL for MCP implementations" (MCP specification). MCP authorization identifies an OAuth client acting for a resource owner; it does not give the agent a portable identity outside that authorization server.

OAuth and workload identity at the IETF. The WIMSE working group (Workload Identity in Multi System Environments) is active and works on identity for software workloads across platforms; its charter does not mention AI agents (IETF WIMSE). An individual draft proposing an on-behalf-of extension to OAuth for AI agents reached revision 02 on August 25, 2025 and has expired (IETF datatracker).

OpenID Foundation and NIST. The OpenID Foundation's AI Identity Management Community Group published "Identity Management for Agentic AI" on October 7, 2025, a whitepaper rather than a specification (OpenID Foundation). NIST launched an AI Agent Standards Initiative on February 17, 2026 that states it "conducts fundamental research into agent authentication and identity infrastructure" (NIST), and its NCCoE concept paper on agent identity and authorization closed its public comment period on April 2, 2026 (NIST CSRC).

Commercial approaches

Commercial work falls into four rough groups. They are listed here without ranking, in each owner's own terms; several of them are complementary rather than competing, because they identify different things at different layers.

Enterprise identity and access management. Microsoft announced Microsoft Entra Agent ID on May 19, 2025, describing it as extending "identity management and access capabilities to AI agents" and assigning identities automatically to agents built in Copilot Studio and Azure AI Foundry (Microsoft Security blog). Microsoft's current documentation, last updated June 15, 2026, calls agent identities "identity accounts within Microsoft Entra ID" and states that Agent ID "is available for all Microsoft Entra customers" (Microsoft Learn). Okta's Auth0 announced Auth0 for AI Agents on September 25, 2025 with user authentication, a Token Vault for calling third-party APIs on a user's behalf, asynchronous human approval, and fine-grained authorization for retrieval; the announcement said the product, then in developer preview, would leave preview in November 2025 (Auth0). Both identify an agent inside one organization's directory, where the relying party is usually that same organization.

Registrar and naming. GoDaddy opened public access to an ANS API and a standards site on November 20, 2025; its CTO for Product and AI described the aim as letting anyone "name an agent, verify it cryptographically" (GoDaddy). On December 18, 2025 it launched an ANS Marketplace with five demonstration agents and 20 agents generated from WooCommerce storefronts, plus "ANS-verified" badges (GoDaddy via PR Newswire). This approach ties agent identity to domain control, the same anchor web PKI uses.

Payment networks. Mastercard unveiled Agent Pay on April 29, 2025, built on Mastercard Agentic Tokens, and said "the program will require trusted AI agents to be registered and verified" before they can pay on a user's behalf (Mastercard). Google announced the Agent Payments Protocol (AP2) on September 16, 2025, with "more than 60 organizations" collaborating; AP2 records a user's instructions as cryptographically signed Intent and Cart Mandates signed by verifiable credentials, and can run as an extension of A2A and MCP (Google Cloud). Visa introduced the Trusted Agent Protocol on October 14, 2025, developed with Cloudflare, built on HTTP Message Signatures and aligned with Web Bot Auth, and published on the Visa Developer Center and GitHub (Visa). Coinbase introduced x402 on May 6, 2025, an open standard that uses the HTTP 402 status code to carry stablecoin payments inside web requests (Coinbase); as described by Coinbase, it settles a payment rather than identifying the agent that makes it. In each network scheme, the network or its issuers decide which agents are recognized.

Know Your Agent vendors. Skyfire launched KYAPay on June 26, 2025, describing it as "the Open Identity and Payments Protocol for AI agents"; per the release, it uses signed JSON Web Tokens that carry verified agent-owner information together with authorized spending (Skyfire via Business Wire). The "know your agent" framing borrows from financial-services know-your-customer checks: an intermediary checks the owner, then vouches for the agent to relying parties that accept that intermediary's tokens.

A pattern runs through all four groups. Each approach answers the identity question for relying parties that already trust a particular issuer: a tenant's directory, a registrar, a card network or a token vendor. That is a legitimate design, and for many deployments the right one. What none of them describes is how an unrelated party, with no account at that issuer, checks an agent's identity and re-derives the result independently.

Regulation touching agent disclosure and identity

This section is context, not legal advice. Consult counsel for how any of these rules applies to a specific deployment.

EU AI Act Article 50. Article 50(1) requires providers to ensure that "AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system" (AI Act Article 50 text). The European Commission states that the transparency rules "apply from 2 August 2026," with a grace period until December 2026 for the marking obligation on generative systems placed on the market before that date (European Commission). The Commission also records that the AI Omnibus amending regulation entered into force on July 27, 2026, and that its main timeline changes concern high-risk systems rather than the transparency obligations (European Commission). Article 50 is a disclosure duty: it requires telling a person that an AI system is involved, not proving to a machine which system it is.

Utah. Utah's S.B. 226 (2025 General Session), with sections effective May 7, 2025, requires a supplier using generative AI in a consumer transaction to disclose that the individual is interacting with generative AI and not a human if the individual asks with "a clear and unambiguous request," and requires prominent up-front disclosure in regulated occupations when the use is a high-risk interaction (Utah Legislature, enrolled S.B. 226). The bill provides a safe harbor for AI that discloses clearly at the outset and throughout.

United States, voice calls. The FCC's Declaratory Ruling FCC 24-17, adopted February 2, 2024 and released February 8, 2024, confirmed that the Telephone Consumer Protection Act's "artificial or prerecorded voice" restrictions cover AI technologies that generate human voices, and noted that its rules already require such messages to "provide certain identification and disclosure information for the entity responsible for initiating the call" (FCC). For voice agents, that makes the identity of the responsible operator a regulatory question, not only a technical one.

None of these texts defines an agent identifier, a verification level or a key format. They set obligations that an identity layer can help an operator evidence, and they leave the mechanism open. A signed self-declaration that an agent is an AI is evidence of what the operator declared; it is not a finding of compliance.

Open problems

The clearest public inventory of open problems is NIST's own list of questions. Its February 2026 concept paper asks, among other things: "How do we handle key management for agents? Issuance, update, and revocation?", "How do we handle delegation of authority for 'on behalf of' scenarios?", "How do we bind agent identity with human identity to support 'human-in-the-loop' authorizations?" and "How do we ensure non-repudiation for agent actions and binding back to human authorization?" (NIST NCCoE concept paper). Six problems stand out from the sources reviewed here.

• Portability across platforms. An Entra agent identity lives in an Entra tenant, an MCP client identity lives at one authorization server, and a payment-network registration lives with that network. The OpenID Foundation's warning about proprietary fragmentation describes the risk directly (OpenID Foundation). An agent that crosses organizational boundaries currently carries a different identity at each.
• Verification without trusting the issuer. Most commercial schemes ask the relying party to trust the issuer's answer. DIDs were designed to avoid a central registry (W3C), and Web Bot Auth lets a server verify a signature against a published key directory (IETF datatracker). Neither, by itself, says who the key belongs to in a way a third party can re-check.
• Delegation and authorization. Knowing which agent is acting says nothing about what it is allowed to do. Research proposals extend OAuth and OpenID Connect for delegated agent authority (South et al., arXiv), AP2 records user intent as signed mandates (Google Cloud), and an IETF on-behalf-of draft for agents expired without adoption (IETF datatracker). No cross-industry delegation object has emerged.
• Revocation propagation. NIST lists revocation as an open question for agent key management (NIST CSRC). When an identity lives in several places at once, a revocation at one issuer does not reach verifiers who checked a different one.
• Binding requests to identities. A registered identity and a live request are different objects. RFC 9421 and Web Bot Auth sign individual HTTP requests (RFC 9421); a manifest or card that describes an agent does not, by itself, prove that a given request came from it.
• Human and organization binding. The FCC's identification requirement for artificial-voice calls (FCC) and NIST's question about binding agent identity to human identity both point to the same need: tying an agent to an accountable legal person, in a form someone outside the operator can check. Domain control, as in the ANS v2 draft (IETF datatracker), is one proxy for that; it is evidence about a domain, not about the organization behind it.

Where AgenID sits and what it does not do yet

AgenID is an open identity and verification protocol for AI agents, published as a normative specification at github.com/AgenID-protocol/spec with an independent conformance suite under the MIT license at github.com/AgenID-protocol/conformance. Its focus is the second open problem above: letting a third party re-verify an agent's identity offline, without trusting the registry that stores it.

What works today. An agent gets an identifier of the form agenid:<ULID>; the spec's example is agenid:01J8Z3K3F2QZ9X6V7R4T8N2W5Y. The operator signs a ManifestProof with Ed25519 over RFC 8785 canonical JSON, binding the manifest by its SHA-256 digest. The reference registry at agenid.com resolves https://www.agenid.com/a/<agenid> to a Verification Card for browsers and to a canonical resolution envelope as JSON, which a verifier can re-check offline; the registry cannot forge an operator signature. Registration happens in the browser at /issue, where the key is generated locally and never sent to AgenID, and anyone can check an agent at /verify.

Two-path key discovery is deployed on the registry side: an operator key can be fetched from https://www.agenid.com/v1/keys/<key-ulid> and compared with the operator's own copy at https://<operator_domain>/.well-known/agenid/keys.json. The second path is published by the operator. Where the operator publishes no copy, a verifier has one source, not two.

The issuance ceiling. Protocol v1.1.1 defines the levels DECLARED, L1_REGISTERED, L2_DOMAIN_VERIFIED, L3_ORGANIZATION_VERIFIED and L4_DEPLOYMENT_VERIFIED; L5 is reserved and not issuable. The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L1 is a registration of a self-declaration; operator attestations in the manifest are self-declared and cannot be verified by anyone, including AgenID. Confirming a _agenid DNS TXT record at /verify/domain records evidence of domain control and raises nothing above L1.

What it does not do yet. There is no revocation flow deployed: agent status values exist in the schema, but nothing writes them, so no agent is revoked or suspended today. Retired keys stay resolvable so historical signatures remain checkable. v1.1.1 defines no signed authorization object; permissions and authorizations are reserved manifest keys, and a v1.2 authorization layer exists only as a draft in development. Nothing binds a live HTTP request to a registered agent. The partner documents for voice and agent platforms are integration patterns, not packages. In the terms of this report, AgenID addresses identity and offline re-verification; delegation, revocation and request binding remain open for AgenID as they do for the field. The trust model page describes these limits in more detail.

Methodology

This is a desk review, researched and written on September 23, 2026. We did not run surveys, interview vendors or test any third-party product. Each claim about a third party comes from a page we fetched on that date and is cited inline; the full list is below.

Source selection followed a fixed order of preference: standards bodies and their document trackers (IETF datatracker, RFC Editor, W3C), official project specifications (A2A, MCP), regulators and legislatures (European Commission, Utah Legislature, FCC), government standards programs (NIST), peer-reviewed or arXiv papers, and then vendors' own press releases, blogs and documentation for their own products. Where only a vendor source existed, the claim is attributed to that vendor. Survey figures give the publisher, sample size and fielding dates where the source states them; forecasts are labelled as forecasts.

Statuses change quickly. Internet-Drafts are revised or expire on a roughly six-month cycle, product pages are updated without notice, and the dates here reflect what each source said on the research date. We excluded claims we could not trace to a primary or first-party source, including widely repeated market-size estimates for which we found no underlying study.

Corrections are welcome. If a date, status or attribution here is wrong or out of date, open an issue on the public specification repository at github.com/AgenID-protocol/spec with the source that shows the correct value, and we will update this page and its updated date.