x401

Every time an AI agent calls a paid API, books a ticket, or moves money, the service on the other end faces a question it historically had no good way to ask: who is actually behind this request? API keys prove possession of a secret. Session tokens prove a logged-in browser. Neither proves that a verified human authorized this specific action. x401 answers that question at the HTTP layer.

How the x401 Challenge Works

The mechanics piggyback on a status code that has existed since the earliest days of the web. When an agent hits a protected route, the server replies with HTTP 401 Unauthorized — but instead of a bare error, the response carries a signed proof requirement in a standard header. That requirement names exactly what the verifier needs: a verified-identity credential, an age claim, an organizational membership, or a signed transaction mandate.

The agent decodes the requirement, asks the user’s credential wallet to fulfill it, and retries the same request with the proof attached in a second header. The verifier checks the signature against published issuer keys and returns HTTP 200 when everything lines up. If any signed detail has been altered (an amount, a recipient, a scope boundary), verification fails.

Under the hood, x401 does not invent new cryptography. It routes existing standards through a single HTTP exchange: OpenID4VP for presenting credentials, DCQL (Digital Credentials Query Language) for naming the exact claims required, and standard credential formats like SD-JWT and JWT-VC for the credential body itself. A satisfied proof can be exchanged for a short-lived bearer token, so subsequent requests skip the challenge entirely.

What Makes x401 Different

Two distinctions matter most.

vs. x402 (payment): x402 answers "can you pay?" by activating the HTTP 402 Payment Required status. x401 answers "who are you?" by activating 401. The two are designed to run side by side: prove identity first, then settle payment — or run both in parallel. Neither protocol’s artifact substitutes for the other.

vs. persistent agent identity: Many approaches try to give each agent its own long-lived digital passport. x401 takes a different route: it verifies the human principal behind the agent on a per-request basis. The delegation chain has four links — a human verified at NIST’s IAL2 assurance level, a signed scoped mandate defining what the agent may do, the agent presenting that mandate at the point of action, and the merchant independently confirming every element. Remove any link and the transaction cannot proceed.

In the broader Know Your Agent landscape, x401 occupies the identity-and-authorization slot: permission tokens define spending limits, agentic commerce protocols carry the purchase intent, and payment rails move the money. x401 supplies the verified-human proof that sits underneath all of them.

Where It Stands

x401 is an open draft specification, licensed under Apache-2.0, and has not been adopted by any formal standards body. The draft number itself is unsettled — the protocol’s own site reads Standard Draft 0.2.0, while Proof’s page still shows v0.1.0. It was created by Proof (formerly Notarize) with technical contributors from Circle, Lightspark, MATTR, Okta, OpenAI, and Visa. Proof maintains the reference implementation, and the spec, reference implementation, and trust-list registry are all publicly available. Whether x401 becomes the industry’s shared identity layer — or one option among several competing approaches — remains an open question in a field where no single standard has yet been ratified.