The x402 pattern (HTTP 402, pay and retry) is finally letting AI agents pay for APIs without accounts, keys, or human-in-the-loop. That is a good thing for adoption, and a bad thing for everyone who wrote the receiving side. I audit LLM systems for a living, and the payment layer is where I now find the most unreviewed security code, because it was written by people who knew how to build agents but had never owned an attack surface that accepts money.
The threat model nobody writes down
A payment endpoint for agents differs from a normal API in one way that changes everything: the caller is autonomous and the caller's instructions are untrusted. Three things follow.
1. The 402 challenge is an instruction channel. When your endpoint returns a payment challenge, an agent reads it and acts on it: which address to pay, which amount, what to send back. If a man-in-the-middle or a poisoned directory can rewrite that challenge, they can redirect payment or inject parameters into the retry. Treat the challenge exactly like you treat model output: as untrusted input your own code must validate, not as a command. Bind the retry to the original request (an order id or nonce you issued) and verify the payment landed on the address you named, not on an address the client echoed back.
2. The retry endpoint is your authorization surface. After payment, the agent calls your retry URL. If the retry just re-checks "was a payment seen for this order id", you need to handle: double-delivery on retry, the payment arriving after your verify call (you must not 500), and a partial amount. The classic bug is treating payment confirmation as at-most-once while the client retries until success. Idempotency is not optional on this path; it is the entire security property.
3. The free tier is the probe. Agents will hit your free or sample endpoint to test your system before paying. That traffic is adversarial by construction. If your free endpoint shares a code path with the paid one (and it should, to be honest), you are effectively running a free vulnerability scanner against your own payment logic, on your own clock. The 402 challenge itself leaks nothing to a human, but to an agent it is a full spec dump: your address format, your amount, your verify flow. Read your challenge response as if an attacker pasted it into a README.
A 30-second check
Before you ship a paying endpoint, answer three questions: What exactly does my retry endpoint trust from the client? What happens if the same order id is retried five times? And if the payment lands one second after my verification call, do I fail or retry? If you cannot answer the third one, you will find out in production at 3am.
I package a free scan of agent system prompts and tool specs that checks the surrounding surface (prompt injection, tool abuse, the untrusted-instruction problem above): point it at your agent spec and it returns a short risk report with the specific field it flagged. Run it here: https://llmrt-companion.manhliemcn4euwlu.workers.dev/agent-scan . The report is deterministic and a self-scan hash is published so you can verify the same input gives the same output.
The deeper rule is simple: the payment layer is the first place an LLM system touches untrusted callers with real-world consequences. Give it the same review rigor you would give an external-facing database. Most teams have not.
Top comments (0)