Agents Got a Native Payment Rail This Month. The Wallet Is Where the Risk Moved.

The x402 Foundation went live under the Linux Foundation on July 14 with Visa, Mastercard, Stripe, and AWS on board, giving an agent a way to pay for a resource per request over plain HTTP, with no account, no API key, and no checkout page.

The wire protocol is the settled part. What an agent is allowed to spend, and whether the permission that lets it spend can be replayed by a different agent, is the wallet's job, and that part is not solved.

The spending cap has to live below the application, in a policy contract or the wallet itself, because the model that decides to pay is the same model an attacker can talk into paying. A limit written into the prompt is a limit the prompt can be argued past.

A dead status code woke up

HTTP 402 has sat in the spec since Tim Berners-Lee reserved it around 1991. "Payment Required," placeholder, never used. Every other 4xx code found a job. That one waited thirty-five years for a client that could pay a bill without a human clicking anything.

That client is now the agent. On July 14 the Linux Foundation stood up the x402 Foundation with about forty members, and the list is the interesting part: Visa, Mastercard, American Express, Stripe, Adyen, Shopify, Google, AWS, Cloudflare, Circle, Ripple, and the Solana and Stellar foundations. The card networks and the stablecoin world agreed on one standard for how software pays software. The activity did not stop at launch either. On July 25 Mastercard and Sunrate put out a white paper mapping sixteen pain points in cross-border B2B payments to agent use cases. The standard is young and the volume is small, roughly 75 million transactions worth about 24 million dollars in the thirty days around launch, almost all of them under a dollar. But convergence this fast, with these members, is the signal worth reading.

How the payment actually works

The flow is five steps and it rides on headers you already understand.

An agent requests a resource. The server answers with a 402 and a header listing what it accepts: the price, the chain, the destination address. The agent constructs a signed payment voucher matching one of those options and sends the request again with the signature attached. A facilitator, an optional service most servers lean on, verifies the voucher and settles it on-chain. The server returns the resource plus a confirmation. Settlement today runs mostly on USDC on Base, gasless, signed locally by the agent and submitted by the facilitator, which verifies and executes but never holds the funds.

No API key. No account creation. No monthly invoice to reconcile. For high-volume metered calls there is a batch mode where the buyer funds an escrow once and signs offline vouchers per request, so a fraction-of-a-cent call does not pay a full settlement fee.

I have agents wired to pay this way, and the first thing you notice is that the API-key drawer empties out. No provisioning, no rotation, no secret to leak. The agent hits an endpoint, gets told the price, pays it, moves on. That part genuinely feels like the future arriving on schedule.

The networks solved the boring half

The reason the standard converged in months instead of years is that settlement is a solved problem. A signed transfer, a facilitator, an on-chain confirmation. None of that is novel, which is exactly why forty competitors could agree on it. Nobody ships a competitive advantage in how a USDC voucher gets redeemed.

The wire was the eighty percent. The other twenty is not on the wire at all.

The spending limit is the hard half

x402 decides how a payment is priced, communicated, and settled once the wallet has already agreed to pay. It does not decide who the agent is, what it is allowed to spend, or whether this particular request should go through. Those live in the wallet layer, and the wallet layer is where the unsolved work sits.

Start with the authorization gap. The grant that says "this agent may spend up to this much, until this date" constrains scope and expiry, but it is not yet cryptographically bound to the agent's identity. A grant issued to one agent can be replayed by another agent with different authority. There is already an IETF draft on delegation binding aimed at closing exactly that hole, which tells you the hole is real and the people building this know it. Until that lands, a leaked permission is a permission anyone can use.

Then the harder problem, the one that does not go away with a spec revision. The thing deciding to spend is a model. The same model reads whatever text lands in its context, and some of that text is written by people who want it to spend. If your spending limit is a sentence in the system prompt, "never pay more than five dollars per call," that is a limit an injected instruction can walk right past. The model that can be persuaded to exfiltrate a file can be persuaded to approve a payment. Application-layer caps are caps the application's own reasoning can be talked out of.

Put the cap where the model cannot reach it

This is the same lesson the sandbox and the kill switch already taught, now wearing a wallet. The control that matters is the one enforced by something that does not read the prompt.

For payments that means the spending policy lives in a policy contract or the wallet, not in application code. A daily and weekly cap, an allowlist of destinations, a per-call ceiling, a threshold above which a human has to sign. Encoded one layer down, where the enforcing code has no opinion about how convincing the request was. When the limit is real, "send ten thousand dollars to this address" stops being a silent success and becomes a refused, logged event. That log is your recourse, because these payments do not reverse. There is no chargeback on a settled USDC transfer. The audit trail is the safety net, so every payment should be an event you can see after the fact.

What to do before you hand an agent a wallet

Put the spend cap in the wallet or a policy contract, never in the prompt or the app logic. Assume the app layer can be argued past, because it can.

Bind the delegation to the agent's identity, or track the delegation-binding work and treat any unbound grant as a bearer token that a compromised agent can hand off. Scope grants tightly and expire them fast.

Start where the model fits: sub-dollar metered calls, an API you were going to pay for anyway, batch settlement with a per-day ceiling small enough that a bad day is annoying and not catastrophic. This rail is built for many tiny payments, not for wiring a rent check.

Keep a human gate above a number you would be uncomfortable losing. Log every payment. When something goes wrong, and with autonomous spend something eventually will, the log is what tells you which agent, under which grant, paid whom.

The payment rail arriving is a real gift. It deletes the key-management and billing-dashboard tax the same way managed runtimes deleted the orchestration code nobody wanted to maintain. Just be clear about which half showed up. The networks shipped the easy part, the part they could all agree on. The part that decides whether your agent is safe to trust with money is the boundary underneath the prompt, and that one is still yours to build.