x401 and x402: How Your AI Agent Proves Who It Represents and Pays
Your agent can use x401 to present the credential evidence a service requests and x402 to pay for its purchase. A compatible application checks that evidence, enforces your purchase approval and completes the payment flow.
Your agent finds the report you need, checks the price and reaches checkout. The seller asks who the agent represents and whether you approved the purchase. Fair questions. You want to answer them and get on with the project, without becoming the agent’s checkout assistant.
Give the agent a maintained public name as well, and people and compatible software have somewhere familiar to find its operator information and official services as those connections grow.
A purchase with identity evidence attached
On October 19, Proof and Circle announced a Money20/20 demonstration combining an x401 credential presentation with an x402 payment from a Circle Agent Wallet. Their announced purchase flow brings a verified credential, signed purchase approval and USDC payment into the same transaction.
The merchant asks for the identity facts it requires and states its payment requirements. The wallet supplies a selectively disclosed credential and approval for the purchase. The merchant checks the evidence, and the agent pays in USDC. The demonstration describes retaining signed approval evidence for a later dispute without taking a full copy of the buyer's identity document.
You approve the purchase, the agent carries it through, and the seller gets evidence it can evaluate. The work keeps moving.
What x401 asks for, and what x402 collects
With x401, a service describes the credential evidence required for a particular endpoint. A credential manager, such as a wallet, obtains the holder's authorized presentation, and the service verifies the result before applying its access policy. Proof's x401 developer guide provides identity-verification and transaction-signing workflows.
The current x401 draft supports requirements beyond personal identity, including membership or organizational standing. It keeps credential proof separate from payment and lets implementations add caller authentication and delegation evidence. A successful identity presentation alone does not establish approval for an arbitrary purchase.
x402 gives a paid service an HTTP payment exchange. The server responds with 402 Payment Required and payment requirements; a compatible client supplies payment data, and the server processes it through the configured payment scheme. The x402 introduction covers paid APIs and content, while the chosen scheme determines verification and settlement behavior.
Your application brings the pieces together. It checks the required proof and purchase authority, completes payment, then lets the service deliver the work.
Follow one report purchase
Imagine your research agent has approval to buy one report from an agreed supplier within a set budget. The supplier requires a verified buyer before providing access. A compatible application can organize the work like this:
- Find the official service. Your agent starts from the supplier's maintained public records and reaches the report offer at its documented endpoint.
- Read the requirements. The supplier states the credential evidence it accepts and the price. Your application checks that the offer fits the approved purchase.
- Present the evidence. Your credential wallet handles the proof request and any required approval. The supplier verifies the returned presentation against its requirements.
- Complete payment. Once the required checks pass, the agent uses the supported x402 flow within its payment authority.
- Keep the result connected. Your application links the approval, payment outcome and report access under the same purchase reference.
Your application coordinates these steps according to the service and payment scheme it supports. For the records to retain afterward, continue to payment receipts, approval and delivery evidence.
Start with one protected endpoint
Proof's October 20 announcement adds a concrete deployment route. The Cloudflare Workers integration uses @proof.com/x401-workers to request a credential presentation before running a protected handler.
For a first sandbox endpoint, the Workers implementation guide calls for a domain served over HTTPS, an email address on that domain and Cloudflare D1 or KV storage. Follow its signing-key and verifier setup, then request the identity facts your operation needs. Add the purchase-approval and payment handling for the transaction you want to support.
x402 can also pay for the verification itself. Proof’s presentation-payment documentation describes a separate flow for verifiers without a card or bank account on file: the verifier pays in USDC to retrieve the signature material needed to verify a presentation. That payment buys verification material; the customer’s purchase remains a separate transaction.
Give the agent a public name people can return to
Your agent may use one wallet today, another tool next month and a new hosting provider later. Customers still need to find the service they’ve been using, without following every change in your stack.
A Headless Domain gives the agent a maintained public reference. Through HeadlessDomains.com and SkyInclude's API and command-line infrastructure, compatible agents can look up its identity records and discover linked manifests and service endpoints. The HeadlessDomains.com setup instructions describe those lookup and management workflows.
Put the name alongside your service description, setup instructions and current endpoint. Keep credentials and purchase approvals in the systems that manage them, and have the receiving application verify any association between the name, operator and authenticated caller. Proof supplies its credential and verification workflows; Circle supplies the wallet in the announced demonstration. Your application connects those systems to the named agent.
Start with one useful service and one purchase your application can account for. Give the agent a name, publish where its work happens and keep those records current as you build.
Give your agent the HeadlessDomains.com setup instructions and choose a name for its work.
Connect the name to your service with What to Do After Registering a Headless Domain: 7 Next Steps.