September 8, 202610 min read

x402 now has a formal attack surface. Four flaw classes, and what they mean for anyone letting agents spend.

For most of its short life, x402's security has been discussed the way early crypto was: one vendor advisory at a time. That ended with Free-Riding the Agentic Web, a systematic analysis from researchers at City University of Hong Kong, Zhejiang University and CUHK, accepted to ACM SIGOPS. It formalises five security invariants, identifies four classes of flaw, and demonstrates them against official SDKs and a live production deployment with resource leakage reaching 100%. The findings were disclosed to Coinbase and ThirdWeb.

This is worth reading carefully rather than reacting to. The paper is not an argument that x402 is broken or that agentic payments are a bad idea. It is a precise account of what happens when you bolt a synchronous HTTP request onto asynchronous blockchain finality, and what an implementer has to do that the specification does not do for them.

The root cause: a gap between the request and the settlement

x402's shape is elegant. A client asks for a resource, the server answers 402 Payment Required with terms, the client returns a signed payment payload, the server verifies it, serves the resource and settles on chain. The whole appeal is that it fits inside one HTTP round trip.

But the HTTP exchange completes in milliseconds and settlement does not. Between the moment a server decides a payment is good and the moment value actually moves, there is a window. Every flaw in the paper lives in that window, or in what the signature failed to say about the request it was supposed to be paying for.

The four flaw classes

1. Cross-resource substitution

The paper calls this a semantic gap in signature design. A payment proof signed for one resource can, in affected implementations, be transplanted onto a different request. The signature authorises an amount and a recipient, but is not bound tightly enough to what was being bought. Pay two cents for a cheap endpoint, present the same proof at an expensive one.

For a buyer this looks like nothing at all, which is precisely the problem. Your agent's spend record and the thing it actually consumed can diverge, and no amount of reading the chain afterwards will reconnect them.

2. Duplicate-settlement race

A concurrency flaw, independently corroborated by later third-party reports. Fire enough simultaneous requests carrying the same payment proof and the server, which has not yet finished settling the first, serves several of them. The researchers describe it as probabilistic service duplication: you do not get a guaranteed free ride, you get a distribution of them.

3. Allowance overdraft

This one is specific to AI inference, and it is the ugliest. Pricing for a model call is not known up front — it depends on tokens produced, including hidden reasoning tokens the buyer never sees. So implementations authorise an allowance and reconcile afterwards. Exploit the synchronisation gap in that dynamic authorisation and the merchant ends up subsidising compute it was never paid for. That is where the 100% resource leakage figure against production middleware comes from.

The paper goes further and proves a structural limit: for output-only pricing there is no scheme that is both fair to honest users and bounded against inflation of hidden thinking tokens. Not a bug in someone's SDK. A property of the pricing model itself.

4. Denial of settlement

The resource is delivered and the payment never lands. From the seller's side this is the plain-language version of every other flaw in the list: goods out, money not in.

Why the fixes belong in more than one place

The researchers propose exactly the right protocol-level mitigations: request-bound signatures, so a proof cannot be moved to a context it was not signed for, and pessimistic state locking, so a proof cannot be spent twice while settlement is in flight. Their defense triple cuts per-call reasoning cost by 47% and flips attacker leverage from 8.7x to 0.9x at 2.8% overhead. Those belong in the SDKs and the spec, and they will get there.

What they do not do, and are not trying to do, is tell a company whether a payment should have happened. Those are different questions:

Protocol security asks: is this payment proof valid, bound to this request, and unspent?
Governance asks: should this agent be paying this merchant, this amount, right now, against whose budget, and who answers for it later?

A perfectly hardened x402 stack will still faithfully execute an agent stuck in a retry loop paying the same endpoint four hundred thousand times. It will still let a compromised agent pay an attacker's endpoint, because that payment is cryptographically impeccable. Fixing the flaw classes closes the free-riding hole. It does not create a spending control.

What this changes for buyers, practically

Do not treat settlement as your ledger

The paper is a demonstration that chain state and economic reality can come apart, through duplication, substitution or non-settlement. Attribution — which agent, which principal, which project, under which policy version — has to be captured at the moment of authorisation, by the party making the decision. Reconstructing it later from hashes was already hard. These flaws make it unsound.

Allowances are not budgets

Allowance overdraft is the sharpest example of something we have argued before about per-wallet spending caps: a limit attached to a single authorisation cannot see the aggregate. If the dynamic-pricing case can overshoot a single allowance, then the controls that actually bind have to sit above individual payments — rolling windows, velocity limits, org-wide budgets. We wrote about the same gap in Cloudflare gave agents a wallet.

Ask your providers which invariants they enforce

The paper's real contribution is the five invariants. They give buyers a vocabulary for a procurement question that previously had none: is your signature request-bound? How do you prevent duplicate settlement under concurrency? How is a dynamic allowance reconciled, and who absorbs the overshoot? A vendor who cannot answer those has not read the literature on the rail they are selling.

Pay-per-token pricing needs a second look

If output-only pricing is provably unfair or unbounded, then anyone buying model calls over x402 should expect pricing schemes to change — input-inclusive metering, capped reasoning budgets, or verifiable usage attestations. Do not architect around today's metering as if it is settled.

The maturity signal

It is easy to read a paper with "100% resource leakage" in the abstract as bad news for x402. It is the opposite. Protocols get formal security analyses when they matter enough for academics to spend a year on them, and the disclosure went to Coinbase and ThirdWeb rather than to a conference stage first. TLS, OAuth and EMV all went through exactly this phase. The uncomfortable years are the ones where nobody has looked yet.

Where Vayr Pay sits in this

We are a governance layer, not a facilitator, and this paper is a decent illustration of why we think those should be separate things. We do not hold funds and we do not settle payments — the wallet provider does that, and the protocol-level hardening the researchers propose belongs there. What we do is decide, before a payment goes out, whether it is inside the rules a human set: budget, merchant, amount, velocity, approval threshold. And we record that decision with its full context at the moment it is made, rather than inferring it from settlement afterwards.

Both layers have to be right. A hardened rail with no policy above it spends faithfully in the wrong direction. Policy above a leaky rail governs a record that does not match reality. This research is a strong step on the first of those. The second is still mostly unbuilt.

x402securityagentic-paymentsgovernancefree-riding

Building agents that need to pay for things?

Join the Vayr Pay waitlist for early access.

One email when we open early access. No spam, unsubscribe anytime.

Keep reading