The HTTP 402 status code has been in the spec since 1992. Until now, no one built a standard way to actually use it for payments.
x402 is CAI Labs' implementation of HTTP 402 Payment Required for AI agents. It turns a status code into a checkout flow where the agent proposes the spend and a separate context authorizes it, keeping the signing key outside the tool call.
Why HTTP 402 matters for agents
When an AI agent calls an API, it needs to pay for the call. The standard approach is a pre-paid API key, which means the agent either has a static credential that authorizes unlimited spending until revoked, or the developer manually tops up an account. Neither scales well when agents are making thousands of autonomous decisions.
HTTP 402 was designed for exactly this case. The server responds with 402 and a payment challenge. The client resolves the challenge and retries the request. CAI's x402 flow follows this pattern:
- The agent calls a paid API and receives a 402 response with a payment challenge (recipient address, amount, chain, token)
- The agent calls x402_payment_prepare with the challenge details
- If the user has an active payment mandate covering this merchant and amount, the payment proceeds automatically within the mandate's limits
- If no mandate exists, the user sees a confirmation prompt in a secure hosted action page
- Once confirmed, x402_payment_execute initiates the custodial transfer
- The agent retries the original API call with the payment proof
The pattern is a propose-confirm split. The agent proposes the payment parameters, but the signing key that commits the transfer lives in a separate context the agent never accesses. This means a compromised agent cannot forge a payment any more than it can forge a transfer.
Payment mandates for delegated spending
For autonomous agents that need to operate without per-payment approval, CAI supports payment mandates. These are AP2-style limits the user creates ahead of time:
- A maximum amount per payment (e.g. $5)
- A daily cap (e.g. $200)
- An optional merchant domain or recipient filter
- An expiration window
When the agent encounters a 402 from a covered domain, x402_payment_prepare skips the user confirmation step and returns a ready-to-execute attempt. The agent can proceed immediately within the mandate's bounds.
How it fits together
The x402 flow is the same pattern as CAI's hosted action flow for transfers. In both cases:
- The agent proposes: it identifies what needs to happen and gathers the parameters
- A separate context confirms: the user or a mandate authorizes the action
- The signing key stays outside the tool scope: no credential touches the agent's runtime
This pattern applies to any side effect with durable cost, not just payments. An agent that proposes a file write, a credential rotation, or a deployment and then hands off confirmation to a separate context is more auditable and safer than one that holds unrestricted signing capability.
The current state
x402 is live and operational as a partial implementation (GAP_X402_V1). Payment mandates are also live as a partial implementation (GAP_PAYMENT_MANDATE_V1). Both support the core flow with automatic daily limits and new-recipient confirmation built in. The vault product that stores long-term site credentials is coming.
MCP servers and agent platforms that want to offer paid tiers can use the x402 pattern as a standard checkout flow. Users do not need to store a credit card on the server or manage a pre-funded API key. The agent encounters the 402, resolves it through CAI, and retries the call. The user sees a single confirmation or sets up a mandate and walks away.
The HTTP 402 status code finally has a real use case, and the agent economy is where it fits.
