Your agent can pay: six attacks on x402 payments (price swap, duplicate payment IDs, free shopping, cache, look-alike sellers, prompt injection) and the fix for each

How x402 works in the talk

Four parties: the buyer (an agent acting for you), the seller (returns 402 and the payment requirements), a facilitator (verifies the signature and settles) and a chain. Micropayments of 10 cents or a third of a cent are the point: a card fee would exceed the price. Her framing: payment is another action an agent can take, and it can lose money without being broken.

The six attacks and the guard for each

1. Price manipulation. The directory listed 5 cents but the 402 header asked 50. With no guard the buyer settled 50 cents. Fix: compare the listed price with the requested price in code before signing. Also check the wallet address and the network, because honest sellers rotate wallets and move between chains.
2. Duplicate payment number. Sending the same payment number five times: all five pass verification (the signature is valid) and the seller delivers data each time, but only one settles on chain. Fix: shared storage of payment numbers (done and in-progress) and refuse repeats. On the buyer side, reuse the same payment number across retries, or three retries become three charges.
3. Free shopping, three ways. (a) Data released after verification but before settlement, then the payment reverts for insufficient funds. Wait for settlement when the data is expensive, licensed, confidential or generated per request; releasing on the valid signal is a latency trade-off for cheap data. (b) An unpaywalled duplicate of a paid page: test by calling every endpoint that should be behind the paywall and expecting 402. (c) A seller cache on a public URL serving later buyers for free: put the cache behind the paywall with a price check, or send Cache-Control: no-store for data you generate each time.
4. Several paid pages sharing one payment. The same payment number fired at two pages that do not know about each other; both deliver, one settles. Fix: bind each payment number to the page it paid for in the shared store and return 409 Conflict on any other use.
5. Malicious discovery. Buyers find sellers in a directory (called Bazaar in the talk) that checks a service works, not who runs it or owns the wallet, so a look-alike seller with a cheaper price can win. Fix: allow list and block list, plus a probation list for newly discovered sellers with a time cap (4 or 24 hours) and later human review, since honest sellers also rotate domains and wallets.
6. Prompt injection in the seller's reply. A reply said the full version was at a premium summary; the agent fetched and paid again, so a 5-cent job cost 55 cents. Keyword filters ("premium", "tier") missed softer hints, and an LLM check mostly worked but not always. What brought attacks to zero was locking the plan so the buyer may make exactly one purchase in that turn, so a second payment is blocked even if the agent decides to make it.

The pattern

A payment can look right and the outcome still be wrong. Check before the buyer signs and before the seller releases data, and trace both sides. For rollout she used one payment ID across the logs of the whole run so a payment can be followed end to end.

Caveats

• Findings come from the speaker's own test setup with a small local model; frontier models may behave differently on the injection test.
• We did not check the x402 specification or any facilitator's documentation; field names and HTTP details here are as described in the talk.
• She presents six of 20 attacks; the rest are not covered.
• Do not point an agent with real funds at unfamiliar sellers on the strength of one talk. Use a test network first.