x401 Protocol: How AI Agents Prove Identity and Pay in USDC

On 21 September, Amazon blocked Meta's Muse shopping agent, citing concerns that it didn't identify itself and moved through accounts without Amazon's consent, according to Proof's 15 October launch release. The x401 protocol is Proof's answer to that standoff: a way for any website to ask an AI agent who it's acting for before the agent pays.

Two days ago at Money20/20, Proof and Circle showed the full loop. An agent presented a verified Proof credential over x401, then paid the merchant in USDC over x402 from a Circle Agent Wallet, per the joint 19 October announcement.

This guide explains how x401 works at the HTTP level, what the demo actually proved, who pays whom in USDC, what it takes to deploy, and where the draft still falls short.

Key Takeaways

• x401 extends HTTP 401 so a site can demand verifiable identity from an agent (x401 spec).
• Payment stays separate: x401 must hand payment to HTTP 402 and a payment protocol (spec).
• Proof and Circle demoed x401 identity plus a USDC x402 payment on 19 October (release).
• Verifiers without a card on file pay Proof per presentation in USDC on Base (Proof docs).
• The spec is still a draft, version 0.2.0, co-edited by Proof and Circle (spec).

What the x401 protocol is

x401 is an open, HTTP-based protocol that lets a server require credential-based proof before it grants access to a route. The current specification describes it as a "route-scoped proof requirement protocol", and it reuses existing standards rather than inventing a new identity format.

Under the hood, the server's request is a W3C Digital Credentials API request carrying an OpenID for Verifiable Presentations query written in DCQL. OAuth 2.0 token exchange is optional, so an agent that proves itself once can swap the result for a reusable token, per the x401 spec.

The name is a deliberate echo of x402. Proof's June launch post frames it this way: x402 lets machines pay, AP2 and Verifiable Intent record what a person approved, and x401 supplies the missing proof of who is behind the agent.

Proof built it, but it isn't a Proof-only spec on paper. The draft lists Daniel Buchner of Proof and Bhushit Agarwal of Circle as editors, with reviewers from Lightspark, MATTR, Okta, OpenAI and Visa, according to the spec header.

That's the who. Here's the how.

How an x401 request works, step by step

Proof's developer guide walks the flow in eight moves. Stripped down, an agent hits a protected endpoint and the endpoint answers with a challenge instead of the resource.

• The agent calls the endpoint with no identity. The server replies 401 with a PROOF-REQUEST header holding a Digital Credentials presentation request (Proof).
• The agent passes that request to the person's wallet. The person authenticates and approves what gets shared (Proof).
• The agent retries with a PROOF-RESPONSE header carrying the presentation. The server verifies it cryptographically and returns the resource (spec).
• If verification fails, the server explains why in a PROOF-RESULT header, for example an expired credential, a replayed nonce or too low an assurance level (spec).

One detail matters for implementers. Proof's public x401 landing page still shows the older header names PROOF-REQUIRED and PROOF-PRESENTATION and labels the protocol v0.1.0, while the latest draft is version 0.2.0 with the three headers above. Build against the spec, not the marketing page.

What can a site ask for? The spec's examples include personhood, country of residence, membership or accreditation and organizational standing. Proof's launch release says basic claims such as verified age, country of residence and email can be requested with no sales process.

What the Proof and Circle demo showed at Money20/20

The 19 October demo is the first public example of x401 and a stablecoin payment in one checkout. According to the joint release, it runs in three beats.

• An identity request alongside a price. The merchant answers the agent with an x401 request (the fact it needs, the issuers it trusts, the assurance level) and an x402 payment request in USDC (release).
• A credential, disclosed selectively. Proof's wallet presents only the relevant facts plus a signed approval for that specific purchase, and the merchant checks the signature against Proof's published keys without calling Proof (release).
• Payment in USDC. The agent pays over x402 from a Circle Agent Wallet, the order completes, and the merchant keeps tamper-evident evidence of who approved it (release).

The wallet side is real product. Circle's Agent Wallets documentation describes 2-of-2 MPC key management where key shares are never exposed to the agent, USDC spending limits for transfers and x402 payments, and sanctions screening before any transfer goes onchain.

If you want to try that half yourself, Stablecoin Insider's guide to creating a Circle Agent Wallet for USDC covers the setup.

Coverage so far, including PYMNTS, has treated the demo as a partnership headline. The more useful reading is mechanical: it shows two HTTP status codes doing two separate jobs in one purchase.

x401 vs x402: who the agent is vs how it pays

The spec is blunt about the split. x401 "MUST NOT redefine payment semantics", and a proof artifact must never be treated as payment, nor payment as proof, per the x401 specification.

That separation is the design choice that makes x401 interesting for stablecoin rails. A merchant can keep its existing x402 setup, which Stablecoin Insider covered in how to accept x402 USDC payments from AI agents, and bolt the identity gate on in front of it, as Proof's developer docs describe.

If you're comparing the wider agent-payment stack, Stablecoin Insider's breakdown of x402 vs AP2 vs ACK-Pay maps where each protocol sits. x401 slots in above all of them as the identity question, not as another payment rail.

The two-way USDC flow: merchants paying for identity

Here's the part most coverage skipped. x402 doesn't just pay the merchant in this model. It can also pay the identity issuer.

Proof's x401 signatures documentation says verifiers whose Proof account has no card or bank account on file get the presentation with both signature segments removed. The claims are readable, but the proof isn't verifiable until the merchant buys the signatures back over x402.

• Network: Base mainnet (eip155:8453) in production, Base Sepolia testnet USDC in sandbox (Proof docs).
• Scheme: x402 version 2, exact scheme, USDC, signed as an EIP-3009 transferWithAuthorization (EIP-3009).
• Timing: the detached signatures stay available for one hour after the presentation is created, and payment is due once per presentation (Proof docs).

Put the two flows together and one checkout can move USDC in both directions. The joint release says it plainly: the shopper's agent pays the merchant, and the merchant pays the identity issuer.

Why should a stablecoin reader care? Because it turns identity into a metered, per-request cost. Proof's launch release argues that verifications costing cents never justified an enterprise contract, and that x402 lets a site pay per claim with no purchase order or minimum.

Identity becomes a line item, like bandwidth.

What it takes to put an endpoint behind x401

Proof shipped a Cloudflare Workers package on 20 October, the day after the demo, according to Proof's blog. The setup in the Workers guide is short, but it has real prerequisites.

• A domain you control served over HTTPS, and an email address on that same domain for enrollment (Proof docs).
• A D1 database or KV namespace to store nonces, because each nonce must be accepted only once (Proof docs).
• An ES256 key pair on P-256 whose public half sits in an OAuth Client ID Metadata Document you host (Proof docs).
• Enrollment as an x401 verifier with Proof, plus a list of trusted agents; Proof publishes its own agents trust list (Proof docs).

Outside Workers, Proof's Node guide uses the @proof.com/x401-node and @proof.com/proof-vc-server packages, and the launch release mentions guides for Python and Go. A sandbox environment exists for testing.

On the consumer side, Proof says its wallet works with Meta's Muse, ChatGPT, Grok, Claude and other MCP-compatible assistants, and that a person can enroll the first time a credential is requested, per the release.

Where x401 fits in a stablecoin payment stack

Not every agent payment needs a legal identity behind it. A one-cent API call doesn't. Proof's own Workers announcement aims x401 at checkout, account changes, regulated or age-restricted content and high-value API calls.

The KYA overlap is real. Stablecoin Insider's guide to Know Your Agent covers the broader practice of verifying agents; x401 is one concrete, HTTP-level way to do the human-delegation part of it.

It also changes the liability conversation. When an agent overspends, the question is who approved what, which Stablecoin Insider unpacked in who is liable when an AI agent overspends. Proof's release says a merchant can keep the signed evidence and validate it later if a transaction is disputed.

Know Your Agent (KYA) in 2026: The Practical Standard for Verifying AI Agent Identity

How businesses verify the AI agents that transact on their customers' behalf, and what a practical KYA program checks.

Stablecoin Insider

Where x401 still falls short

Let's be clear about the gaps, because a draft protocol has plenty.

• It's a draft. The spec is labeled Draft 0.2.0, and its open-questions section still lists fully autonomous delegation and agent authentication as future additions (spec).
• One issuer in practice. The protocol is issuer-neutral, but Proof is the only production issuer named in the launch materials, so "open" today mostly means "open to Proof credentials" (Proof).
• No public price. Proof says it prices claims individually, yet neither release nor the docs list a per-claim USDC amount (release).
• Delegation is early access. Proof's Delegate Authority product, which carries spending caps and allowed payees for agents, is still invite-only (Proof docs).
• Correlation risk. Reusing one credential across many routes can let services link a person's activity, which the spec itself flags (spec).
• Compliance doesn't move. A verified credential can support a bank's customer identification, but Proof notes existing Bank Secrecy Act requirements stay unchanged (release).

There's also a cost in friction. A first identity-gated purchase involves at least two round trips to the merchant plus a human approval on a device, per the flow in Proof's docs. That's fine for a wire. It's a lot for a sandwich.

Who should test x401 now, and who can wait

Test it now if you sell regulated, age-restricted or high-ticket goods to agents, or if you run an API where an agent's action has legal weight. The Workers package and sandbox make a pilot cheap, per Proof's guide.

Wait if your agent traffic is low-value pay-per-call usage. x402 alone already covers that, and adding a human approval step would cost you conversions.

FAQ

Forward look: watch for three things over the next quarter. A second credential issuer shipping x401-compatible credentials, a published per-claim price, and a payment network naming itself as the adopter Proof's x401 page describes anonymously. Any one of them would move x401 from an interesting draft to a default header in agentic USDC checkouts.

This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; it is not financial advice, and no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any asset or token. x401 is a draft specification and Proof's and Circle's products, prices and supported networks can change; check the live spec and developer docs before you put an endpoint behind it. Nothing here is a solicitation to buy or sell.