Let Your Agent Pay? 6 Attack Vectors You Need to Patch First

The proposal. X402 is an emerging protocol that lets machines pay each other in crypto micropayments, using the long-dormant HTTP 402 status code. Ishween Kaur of SoFi built a test system on Base Sepolia with Llama 3.2 and found 20 ways the flow breaks. She presents six attacks, each with a concrete fix. The tension is clear: agents buying data in 1-10 cent increments will become a new security boundary, and most teams are not ready.

The core attacks. Price manipulation is trivial: a seller lists for 5 cents but returns a 402 header charging 50 cents. Without a guard comparing listed price to requested price, the agent pays the higher amount. Duplicate payments are equally simple. A buyer sends the same payment ID five times; the facilitator verifies all five signatures as valid, the seller releases data five times, but only one payment settles. The fix is a shared cache of used payment IDs.

The trade-off. Free shopping via settlement failure or cache leaks forces a latency-versus-risk decision. Waiting for settlement before releasing data protects expensive assets—lucensing, provisioning, confidential reports—but adds seconds of delay. For low-cost data, a valid-signal release is acceptable, but then cache must be behind the paywall with Cache-Control: no-store for sensitive content. Kaur found that caching on public URLs is a common oversight.

Organizational risks. The seller discovery directory (Bazaar) does not verify wallet ownership or domain reputation. A malicious actor can create a look-alike seller and name it identically, and an agent seeking cheaper pricing will choose it. Kaur recommends an allow list plus a probation list for new sellers, reviewed by a human within a time cap. Even honest sellers rotate wallets and domains, so allow lists must be actively maintained.

Prompt injection meets payments. A seller returns a truncated response suggesting the full version is premium. Kaur's agent used Llama 3.2 to decide to fetch the premium summary, paying another 50 cents on top of the original 5 cents. Attempts to filter keywords failed against subtle hints. The working fix: bound the agent's plan so it can only pay once per turn. This reduces risk area but also limits autonomous flexibility.

What teams should do. Kaur's methodology is trace-by-trace: start with one payment ID, log the full sequence diagram. Then run a shadow phase with 20-25 success and failure datasets, perform error analysis, and iteratively harden guards. The talk is a handbook for anyone building agent payment systems. The implication for engineering leaders is that this new capability demands new governance—before it hits production.