# Your Agent Just Paid for Nothing: 6 Attacks on x402 Payments

Ishween Kaur, SoFi | AI Engineer NYC 2026 | 16:44

Source: https://www.youtube.com/watch?v=YU1uD_YkpjU
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/your-agent-just-paid-for-nothing-6-attacks-on-x402-payments
Published: 2026-10-30
Tags: observability, security, testing, tool-use, tracing

## TL;DR
- x402 lets an agent pay for small amounts of data over HTTP, but the agent needs checks for the seller, amount, network, wallet, and approved data before signing.
- Six attacks can make an agent overpay, pay twice, receive data before a payment settles, access unpaid pages, pay an impostor, or pay again after prompt injection.
- Ishween Kaur recommends tracing each payment through the full workflow, testing success and failure cases, then adding guards, alerts, and blocking rules for the specific business use case.

## Summary
Ishween Kaur explains x402 as a way for software to buy data and API responses with small on-chain payments. She maps the protocol across a buyer, seller, facilitator, and blockchain, then shows six attacks she tested in a safe environment. A seller can change the price in the payment header, duplicate requests can release data more than once, and a seller can release data before settlement fails. Unprotected endpoints and public caches can provide data for free. Separate pages can accept the same payment, while a directory can lead an agent to a look-alike seller. Seller text can also prompt an agent to pay again. The defenses include checking every payment field, sharing payment state, waiting for settlement when the data is costly, protecting every endpoint and cache, using seller lists, and limiting each workflow turn to one payment. Kaur recommends tracing one payment ID through the system, testing 20 to 25 success and failure cases, and then adding enforcement gradually.

## Key ideas
### x402 gives agents a machine-readable way to buy small amounts of data
[01:33](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=93s)
HTTP status code 402 had indicated that payment was required without explaining how a machine could pay. x402 fills in that missing protocol detail. The buyer requests data, the seller returns payment requirements, and the buyer signs the payment. A facilitator verifies the signature and handles settlement on a chain before, or as part of, releasing the data. Kaur explains why on-chain payments fit small purchases such as 10 cents, 1 cent, or one third of a cent, where a credit card fee could cost more than the item.

### The payment header must be checked against the buyer's approved request
[04:05](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=245s)
A seller may list a service at 5 cents in a directory, then put a 50-cent price in the later 402 payment header. In Kaur's test, an unguarded buyer paid and settled the higher amount. Comparing the listed and requested prices stopped that attack. The check also has to cover the wallet, network, coin, and other payment fields. A seller can change from Base to Ethereum or Solana, rotate its wallet, or alter the destination while the request still appears valid.

### Payment verification is not the same as settlement
[05:24](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=324s)
A payment number is unique on-chain, so sending the same payment five times can lead to one settlement and four rejections. The dangerous part is that verification can mark all five requests as valid before settlement finishes, allowing the seller to release the same expensive or confidential data repeatedly. Kaur recommends shared storage for payment numbers, with states such as completed or in progress. Buyers need similar care on retries. If each retry uses a new payment number, one timed-out request can become several charges.

### Free access comes from releasing data too early or leaving an endpoint exposed
[07:03](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=423s)
A facilitator can return a valid signal and the seller can release data before settlement later fails because of insufficient funds or inconsistent state. Waiting for settlement reduces that risk, especially for licensing, activation, provisioning, confidential, or expensive data. Cheaper data may justify releasing it after verification to reduce latency. Kaur also checks every endpoint that should be paid and expects a 402 response. Public caches create another path to free data, so paid responses should stay behind the seller's paywall, and generated or confidential data should use a no-store cache setting.

### Shared payment state prevents one payment from unlocking multiple pages
[09:13](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=553s)
A seller with several paid pages can accidentally accept one payment on each page because the pages do not share state. Each page sees a valid request, releases its data, and only later does the chain reject the duplicate settlement. Shared storage can bind the payment claim to the page that delivered the data. A later attempt to use the same payment for another page can then return a 409 conflict instead of releasing more content.

### Seller discovery needs identity controls as well as service checks
[10:04](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=604s)
The Bazaar directory in x402 can check whether a service works, but Kaur says it does not check who operates the service or owns its wallet. An attacker can create a look-alike seller with a similar name, a different domain, wallet, price, or network. Enterprises can use an allow list for approved sellers. Workflows that need discovery can also use block and probation lists. New sellers can remain on probation while a human reviews the buyer's intent, the seller response, and the seller called. Kaur notes that honest sellers can also rotate domains, wallets, prices, networks, and coins, so the allow list needs ongoing checks.

### A seller's text can persuade an agent to make a second payment
[11:43](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=703s)
Seller responses are text, so a message that points to a premium version can influence the agent's next action. In Kaur's Llama 3.2 test on Base Sepolia with a local x402 facilitator, a request that should have cost 5 cents became 55 cents after the agent fetched the premium summary. Keyword filters can catch words such as pay, tiers, or premium, but indirect suggestions can avoid them. A model-based detector works in many cases but can miss attacks. Kaur instead locked that workflow turn to one seller call, which blocked the second payment even when the agent chose to make it.

### Payment traces should drive a gradual rollout
[14:10](https://www.youtube.com/watch?v=YU1uD_YkpjU&t=850s)
Kaur recommends starting with one payment ID and tracing it through the entire workflow. The trace should show the buyer's intent, the seller response, and the seller that was called. If it does not, the system needs more tracing. The next phase uses 20 to 25 success and failure cases for error analysis. Those cases show where to add guards, alerts, or blocking. The same cases can then test whether enforcement is too strict, too weak, or ready for release. Her conclusion is that a payment can look correct while producing the wrong result, so checks belong before signing and before data release.

## Notable quotes
- "An agent is trying to create a report for you, and it needs one market data point that is available on this API that says, "Hey, pay me 5 cents." Should your agent just pay? Probably not." (01:11)
- "The payment can look right like most of the cases my payments look right, but I got the wrong outcome." (14:17)
- "Start with one payment ID and trace it throughout that system." (14:37)
- "Can our agents pay? Yes, but the real question is should we let them pay?" (16:16)

## Tools & references mentioned
- x402
- HTTP 402
- Cloudflare
- Bazaar
- Llama 3.2
- Base Sepolia
- Ethereum
- Solana

## Who should watch
- You are building an agent that can buy APIs, data, reports, or other digital goods and need to understand where payment state can fail.
- Your seller releases paid content, licenses, activations, or confidential results and you need concrete checks for duplicate, unpaid, or cross-page access.
- You want a rollout plan for agent payments based on traces and failure cases rather than a single approval step.

## Editor's note

Ishween Kaur recommends tracing one payment ID through the full workflow, then testing 20 to 25 success and failure cases before adding enforcement. Kitaru records each model call and tool result from a real agent run, so the failed payment flow can be replayed with a changed prompt, model, or code against the same recorded responses. Those replays make the payment guards repeatable tests before release.

Written by the AIE Talks editors (the Kitaru team), not by the speaker.

## Related talks

- [x402 Isn't Good (Yet)](https://aietalks.com/talks/x402-isnt-good-yet) (Jan Curn, Apify, 20:48)
- [When AI Agents Pay and Sellers Monetize: Building x402 Apps on AWS](https://aietalks.com/talks/when-ai-agents-pay-and-sellers-monetize-building-x402-apps-on-aws) (Anil Nadiminti, AWS, 20:41)
- [Why AI Agents Still Won't Pay for Anything](https://aietalks.com/talks/why-ai-agents-still-wont-pay-for-anything) (Jan Curn, Apify, 20:37)
- [Why AI Agents Will Need Their Own Bank Accounts](https://aietalks.com/talks/why-ai-agents-will-need-their-own-bank-accounts) (Lincoln Murr, Coinbase, 16:58)
- [Agent Spending Without Controls](https://aietalks.com/talks/agent-spending-without-controls) (Rodrigo Coelho & Pranav Maheshwari, Edge & Node, 20:48)