Ishween Kaur on Securing Agent Payments with x402

I am Ishween Kaur, and I work on AI evaluation and autonomous systems. I became interested in agent payments and explored x402 by attacking a controlled environment. Imagine paying for one movie without subscribing, or an agent paying a few cents for a market data point: before paying, it should check the seller, budget and whether the purchase is actually authorized.

HTTP has long reserved status 402 for payment required. x402 builds a way for software to handle a payment in that request flow. I describe four parties: the buyer agent, seller, facilitator and chain. The seller returns payment requirements, the buyer signs, and the facilitator verifies the request and can settle the payment.

On-chain payments are attractive for very small amounts where ordinary transaction fees could exceed the price. But tiny purchases add up: ten cents across 10,000 calls is $1,000. An agent does not need to be broken to lose money, so I tested 20 ways to disrupt the flow and focus here on six.

The first issue is a price change. A directory can list a service at five cents, while the seller’s 402 payment requirements ask for 50 cents. In my unguarded test the buyer signed and settled the higher amount. A guard comparing the expected and requested amounts blocked that run.

A price check alone does not cover every substitution. The wallet address or network can change too, whether because of an attack or a legitimate rotation. The buyer needs to check the relevant fields together so it pays the intended seller on the intended network for the intended amount.

The second issue is repeated use of one payment. In my example, a seller accepts five copies of the same authorization. Verification can report each as valid before settlement; only one payment settles, but the seller may already have delivered five times. The verification and settlement stages have different consequences.

I suggest shared storage for payment identifiers and their in-progress or completed state, so a duplicate request can receive the saved result rather than trigger a new delivery. This matters when the response contains costly or confidential data, or activates a license. The buyer has a related retry risk: issuing a new payment identifier on each timeout can cause multiple charges for one result.

A third problem is delivery without successful settlement. Verification may pass, but settlement can later fail, for example because the buyer lacks funds. Waiting for settlement before releasing expensive, confidential or newly generated data reduces that risk, at the cost of added latency. A business may make a different choice for low-value data.

Free access can also come from ordinary application design. If one endpoint protects a report but another serves it without the paywall, the buyer can reach the latter. Test every endpoint intended to require payment and confirm that it returns the payment requirement.

Caching introduces another path. If a shared cache stores a paid response at a public URL, a later request can retrieve it without passing the paywall. Keep cached data behind the seller’s payment check, and avoid caching sensitive or expensive responses where appropriate. Cache configuration also needs to honor the intended no-store policy.

The fourth issue is replay across resources. Two protected pages may each accept the same payment if they maintain separate records. Shared state can bind the payment identifier to the resource already delivered and reject a conflicting claim, rather than treating each page as an independent purchase.

The fifth issue is malicious discovery. A directory may indicate that a service works without establishing who controls its domain and wallet. A lookalike seller can use a familiar name and a lower price; an agent choosing only by price might send payment to the wrong party.

A conservative enterprise can restrict purchases to approved sellers. For workflows that need to discover new sellers, I suggest approved, blocked and probation lists, with human review and limits on probation. Legitimate sellers also rotate domains, wallets, networks and prices, so the approved list needs ongoing maintenance.

The sixth issue is prompt injection through a seller’s response. A result can suggest that a fuller version is available elsewhere without directly ordering a purchase. In my Base Sepolia test using Llama 3.2, the agent fetched and paid for a premium summary: a five-cent request became a 55-cent total.

Simple keyword filters can miss subtle suggestions, and a model-based judge can also miss an attack. In this particular workflow I knew the buyer should make only one call, so I locked the execution plan to that limit. The agent still decided to fetch the extra summary, but the guard blocked the additional payment in my test.

Across these cases, the payment can look valid while the outcome is wrong. Checks belong before the buyer signs and before the seller delivers. Traces should show the buyer’s intent, the seller’s response, the service called and the transaction outcome.

For a rollout, I start with one payment identifier and log the sequence end to end. In a shadow phase, I suggest a dataset of roughly 20 to 25 successful and failed cases and error analysis to identify where alerts, blocking or other guards are needed.

Then enforce the selected controls and repeat the trace-by-trace tests. The results help decide whether controls are too aggressive, too lenient or need adjustment for the actual business workflow. Agents can pay, but the important question is when we should allow them to do so.