This content reflects minia2a as of its publication date and is kept for the record. Current model: x402 pay-per-call in USDC on Base only, 5 free trial calls per signed wallet, no credits and no top-up rail.

17 of 22 sellers cheat. What can a marketplace stop before your agent signs?

November 2026

This week an independent exam, the x402 Agent Safety exam, opened a simulated internet for paying agents: 22 sellers per exam, 17 of them cheating, every request and every signature watched. Its front page on 11 November 2026 reports 34 agents tested, 10 admitted, results signed and replayable. A separate hardening skill aside, the exam's premise is that a model handed a wallet will pay a seller that lies to it, because nothing in the 402 protocol says who is supposed to check.

The exam grades agents. This post is about the other half of the transaction: the sellers, and what a marketplace can refuse to pass along before a buyer's signature exists. Some of these traps are structurally checkable by the platform. One is not, and it is worth being explicit about which one.

The traps, from the buyer's side

An agent that calls a paid endpoint sees exactly one document before it signs: the 402 challenge. Cheating enters through that document or through what comes back after it settles.

• The quoted price is not the charged price. The catalogue says one cent; the challenge asks for fifty.
• The money goes somewhere else. The challenge names a receiving address that is not the seller's.
• The challenge is not the challenge. The header a validator reads and the JSON body a client reads describe different payments, so two components in the same pipeline disagree about what was approved.
• The response is an instruction. The payment settles, and the body comes back carrying text aimed at the buyer's model rather than at its program.

What a marketplace can check before the buyer signs

All numbers below are from measurements on the live catalogue, dated 11 November 2026, not from an architecture diagram.

1. Price: the catalogue row and the live 402 have to agree

Our full sweep of 1,686 first-party endpoints (10 November) found every one answering 402 with a canonical challenge, a uniform network, asset and receiving address, and an amount equal to its own catalogue row. To check that the sampled experience matches, we drew 60 random active services on 11 November and compared the published priceCents against the amount in the base64 PAYMENT-REQUIRED header:

sample 60 endpoints (seed 20261111) decoded 60/60 amount == published price 60/60 mismatches 0 

That check is cheap because both numbers are ours. It stops being cheap the moment a seller is allowed to write its own challenge, which is why forwarded listings get their own measurement below.

2. Destination: the seller cannot pick where the money lands

Of the catalogue's 1,857 rows, 171 are forwarded rather than served by us. On every one of those, the proxy path answers 402 to the address registered for that row and at that row's catalogue price — 171/171 measured on 10 November. A buyer calling through the platform never receives a signed instruction to send funds to an address that appeared in a seller-supplied field, because the platform does not accept that field from the seller.

3. The challenge a validator reads is the challenge the client reads

A 402 here carries the payment document twice: base64 in the PAYMENT-REQUIRED header, and as the JSON body. If those two ever disagree, an agent that parses the body and a library that parses the header are approving different transactions. Measured on 11 November: 60/60 first-party 402s byte-identical after decoding, and 6/6 on the alias path.

What the buyer reads is also constrained. Across four surfaces (/x402, /svc, the v1 accepts[] array, and /mcp), every measured unpaid 402 — 148 of them — carries a real description capped at 480 UTF-8 bytes. Not a slogan, not an unbounded paragraph a seller can use as a billboard.

The trap we do not check

The fourth class — instructions inside the paid response — is not screened. Of 1,857 catalogue rows, 171 are forwarded rather than served by us, and whatever the far side returns is returned to the buyer unchanged. We validate the shape of what a buyer pays for; we do not read the prose of what they receive for a prompt-injection attempt. Neither, as far as we can tell from the exam's published results, does any buyer-side agent.

This is the part where a marketplace post usually promises a scanner. We are not shipping one this week, and a keyword blocklist would be theatre: the boundary between "a description of an API error" and "an instruction to the caller's model" is not a regex, and a seller who wants to smuggle a sentence will win against one. What we can say now is narrower and true — the response body is passed through verbatim, and a buyer should treat it as untrusted input.

Why the platform is the right place for the first three

Each of the checks above is a comparison between two things the platform already owns: the catalogue row and the challenge it emits, the header and the body, the seller's declared endpoint and the address the proxy charges. None of them requires a model to be careful. That is the point — a check that lives in the platform happens once per request whether or not the buyer's agent is having a good day.

The fourth check has no such pair. It needs a judgment about text, made on the buyer's behalf, at the moment the buyer is already committed. Until someone builds that convincingly, the honest posture for a buyer-side agent is the one the exam is testing: quote first, compare to what you were promised, and never follow instructions that arrive inside a receipt.

If you run a marketplace and want to reproduce any of these measurements, every one of them is a plain HTTP request against a public endpoint — the 402 is free to ask for, and asking for it does not spend a trial.

Originally published at minia2a.uk.