Proof's new identity protocol slots in beside x402, AP2, and ERC-8004. What x401 verifies, who vouches for its issuers, and the one job it hands to others.
On 25 June 2026, Proof introduced x401, an open protocol that lets an HTTP service request cryptographically verifiable credentials before granting access. Those credentials can establish the identity or attributes behind an AI Agent's request, and paired with delegation evidence, can show that a verified person authorised the agent to act. It is the identity counterpart to x402, the payment protocol Coinbase released in May 2025 and has since contributed to the Linux Foundation: one negotiates how an agent pays, the other what an agent must prove before it acts. x401 does not mandate an identity for the agent itself, which leaves runtime identity to platforms such as Google Agent Identity, and persistent agent identity to registries such as ERC-8004 and Concordium's Agent Registry. The pieces of the agentic trust stack are now arriving weeks apart, not years apart.
What x401 Actually Does
When a client requests a protected resource, a server may answer with HTTP 401: unauthorized, challenging it to provide credentials. Those credentials have usually authenticated an account or a session.
x401 adds something different: a machine-readable way for the server to request verifiable proof about the caller before granting access, built for machines acting on behalf of people. In outline, the flow runs as follows:
- The AI Agent makes a request to a protected endpoint, such as a call to initiate a payment.
- The server answers with a proof requirement, carried in a response header that spells out which credentials the agent must present. A 401 response is the usual case, though the current draft lets other status codes carry the requirement too.
- The agent assembles a presentation of Verifiable Credentials that meets those requirements, usually working with an identity wallet that holds the user's credentials and signing keys. This is the step that matters most: the presentation can carry signed proof not only of who the human is, but that the human authorised this agent to act within a defined scope.
- The agent retries the request with that presentation attached in a dedicated x401 header.
- The server checks that the credentials carry the right values and are signed by the issuers they claim to come from, then serves the request.
The credential exchange does not require the service and agent to share a password or API key, and no photograph of a driving licence travels across the internet to prove an age. It can still sit alongside a service's existing authentication, and a successful proof can optionally be exchanged for a short-lived access token. A nonce and verifier binding help stop a captured presentation from being reused, provided the verifier checks its expiry and replay state correctly. Cryptographic validation is deterministic: signatures, expiry, and request binding either check out or they do not. Whether the proof is accepted also depends on the verifier's policies, including which issuers and assurance levels it trusts.
The issuer signs the credential, so a verifier can check its authenticity and detect any alteration. Encryption is a separate choice that x401 neither requires nor prohibits. x401 does not prescribe a single credential format, and the formats it can carry, such as SD-JWT VC, support selective disclosure. With one of those, an agent presents only the fields a service asks for, an over-18 flag the issuer included, say, while the rest of the credential stays behind. How much privacy that buys depends on the format and on what the service chooses to request. The proof travels while the data stays put.
That principle will sound familiar to anyone who has followed Concordium's identity work. Verify Once. Prove Everywhere. Reveal Nothing. It was designed for human users years before AI Agents became a market category, and x401 is now carrying the same logic into HTTP itself.
The Stack Is Assembling
In May 2025, Coinbase released x402, reviving HTTP's long-dormant 402 "Payment Required" status code so that agents could pay for resources per request. Google followed with AP2, an agentic commerce protocol launched in September 2025 with more than 60 partners including Mastercard, PayPal, and American Express. In January 2026, Ethereum's ERC-8004 standard reached mainnet, and close to 39,000 agent registrations followed across 15 chains in its first 90 days.
The payment standard has since crossed a milestone that matters for everything built on top of it: Coinbase contributed x402 to the Linux Foundation, and the newly operational x402 Foundation now stewards it under neutral governance with 40 member organisations, from AWS and American Express to Stripe and Visa, so no single vendor controls the payment standard the rest of the stack builds on.
Now Proof, the identity company formerly known as Notarize, has filled in the 401 side of the ledger, developing the protocol with technical contributors from payments, identity, and AI organisations, Visa, OpenAI, Okta, MATTR, and Lightspark among them, and with Circle as a core contributor and co-editor of the specification, and committing to submit x401 to the FIDO Alliance's agentic authentication working group. The pace since launch suggests this is not a paper exercise: live demos and an MCP server were available from day one, and on 9 July 2026 Proof announced a Verified Business Identity partnership with Enigma that extends the same verification logic to the businesses agents transact with.
The Human Behind the Agent
The design choice that matters most is easy to miss: x401 is built to check what a caller can prove, not to hand the agent an identity. Proof's own deployment points that capability at one thing in particular, the human behind the agent.
Agent binding is an optional part of the protocol, which deliberately leaves persistent agent identity to other systems. What Proof's deployment adds on top is the human: a credential carrying signed proof that a real, verified person authorised the agent to act, with a mandate that scopes that authority, what the agent may buy, how much it may spend, which services it may reach, and for how long. Proof argues that a signed, scoped mandate can serve as technical evidence toward legal attribution under frameworks such as the ESIGN Act and UETA, which allow contracts formed by electronic agents provided the action is legally attributable to the person to be bound, though whether it is enough depends on the transaction, the implementation, and the applicable law. In that deployment, a merchant can verify that an accepted issuer has attested to a verified human and that the presented mandate covers the action.
That accountability can survive while the merchant sees very little. Where the deployment uses selective disclosure, the service may receive only the attribute a transaction needs rather than the person's full identity. x401 itself defines no disclosure procedure. If a disclosed attribute later had to be connected to a person, the issuer that did the original verification would normally be one of the parties involved, and the exact process would depend on its records, its jurisdiction, and its legal obligations.
By itself, proof of human authority does not tell the merchant whether this is the same agent that behaved reliably last month, or whether its operator has any track record. It establishes authority for the interaction, not persistent identity or reputation for the agent.
Five Functions, Five Questions
Seen together, the emerging protocols divide the trust problem cleanly:
The first three functions attach primarily to a transaction or request. Google Agent Identity lasts longer: it identifies and governs a deployed agent throughout its runtime lifecycle, but remains tied to the environment hosting it. The fifth function is different again. CIS-8004 provides a portable registry record that can follow an agent across services and platforms, allowing it to accumulate history, reputation and revocable standing over time.
ERC-8004 gives AI Agents a persistent on-chain anchor: a registry entry, metadata, service endpoints, and mechanisms for reputation and validation. What its baseline specification does not require is a verified connection between the agent and the person or organisation controlling it. Anyone who controls a wallet can register an agent; the link between that wallet and a verified real-world identity remains optional.
Where Concordium Fits
Concordium has built that fifth function with the connection the others leave out. Its Agent Registry, live since May 2026 and built on CIS-8004, its own implementation of ERC-8004, anchors each AI Agent to a verified human identity at the protocol level. A Verified by Concordium badge makes that status visible wherever the agent operates, and agents on Ethereum, Solana, and other chains can earn it without migrating, each linked back to a verified Concordium account.
This is extension, not reinvention. AI Agents get what humans on Concordium have had since day one, because every Concordium account is tied to a verified identity, managed through Zero-Knowledge Proofs (ZKPs). This is where the approaches differ. x401 does not prescribe one privacy model; it can carry formats that minimise disclosure, and each deployment chooses. Concordium's distinction is that zero-knowledge identity proofs and accountable identity are built into its protocol and account model rather than selected separately each time, so an account can prove it belongs to a verified adult without the underlying birthdate, name, or document being disclosed.
Concordium does not place plaintext identity documents or personal attributes on-chain; routine verification runs on ZKPs and encrypted identity records, so routine proofs need not disclose the underlying identity attributes. The link between an account and a person still exists, and by design opening it requires the prescribed legal process and the cooperation of designated parties. In an issuer-held identity model such as Proof's, a lawful identity request would normally involve the issuer holding the underlying records. Concordium's design instead divides the disclosure process between the Identity Provider and designated Privacy Guardians, so no single party can unmask a user alone. Privacy with accountability, not anonymity.
Identity is also what makes those payment rails trustworthy rather than merely functional, a conclusion the card networks have reached too, with Mastercard binding an agentic token to a specific agent and consent policy and Visa giving each agent a verifiable identity that merchants can check. Concordium's bet is to put verified humans and verified AI Agents on the same identity layer, beneath both the payment and the proof.
Who Vouches for the Issuer?
To be fair to x401, the protocol is not naive about trust. Its specification lets each service declare which authorities it accepts, pointing at an OpenID Federation or Europe's ETSI trusted lists, the machinery behind eIDAS, and the verifier enforces that itself rather than taking the agent's word for it. x401 does not skip the issuer question; it gives every service a standard way to answer it.
What x401 cannot decide is which authorities a service ought to trust. That remains a governance choice. A verifier might rely on an identity provider such as Proof, which operates a WebTrust-audited certificate authority; on a regulated framework such as Europe's trusted lists under eIDAS; or on another issuer whose verification process it accepts. None is trusted automatically: the verifier still decides which authorities satisfy its policy. Concordium addresses a related but different question: not merely whether a credential issuer is recognised, but whether an agent can be persistently connected to a verified person or organisation. In a combined deployment, Concordium could provide that identity anchor while x401 carries the proof requirement at the point of access.
Reading the Stack
Two months is not a track record, and honest analysis should say so in both directions. x401 has a specification, notable contributors, and a reference implementation, but no adoption data, no independent implementations at scale, and no finished standards process. The spec is still a draft (v0.2.0), and Proof's own product page and the protocol site both still show v0.1.0 and the pre-rename header names, a sign of how early this is. The registry is young too. Concordium's Agent Registry showed 1,694 agents registered on mainnet as of 26 August 2026 on its public live counter, a fraction of ERC-8004's tally, though each Concordium entry is tied to a verified identity, the link ERC-8004 leaves optional. Registries do not solve per-request authority any more than x401 solves persistent identity. The two need each other.
That is why x401 is good news for anyone building agent infrastructure. Five efforts are converging on one conclusion: agents can already act, pay, and transact, and what is still scarce is proof of who stands behind them, at the moment of the request and over time.
Per-request proof is getting its answer. The question that remains is who holds the anchor.
Join the Concordium Community, follow us on X.