Agent payments crossed from prototype to infrastructure faster than the security work did. The x402 protocol now carries more than 130 million transactions and sits inside Google Cloud, Cloudflare, and Stripe. Last week two papers put that infrastructure under a microscope, and one of them is a peer-reviewed conference result, not a preprint.
"Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments" (arXiv:2605.30998), accepted at ACM SIGOPS ATC '26, reports resource-leakage ratios up to 100 percent against official x402 SDKs and production deployments. A companion architecture paper, "Agent-to-Agent Finance" (arXiv:2607.00245), makes wallet risk a first-class channel and states it plainly: "a malicious service description can trigger prompt injection, which leads the agent to misinterpret the payment purpose, which causes wallet authorisation to approve an unintended transfer."
These are not one-vendor bugs. They come from something structural.
The gap: synchronous request, asynchronous finality
x402 bridges an HTTP request, which is synchronous and returns in milliseconds, to a blockchain settlement, which is final only after confirmations. Between "the client says it paid" and "the network agrees it paid" there is a window. Everything in that window is attack surface, and anything that settles on top of x402 inherits it.
The ATC '26 paper organizes the exploitable surface into four attack primitives. Each one lives in that gap.
The four primitives
Cross-resource substitution. A payment proof generated for one resource is replayed against a different resource. The payment is real; the binding between payment and thing-paid-for is missing.
Duplicate-settlement race. In the window between payment broadcast and on-chain finality, the same payment pulls the resource more than once. One payment, many deliveries.
Allowance overdraft. An approved token allowance is drained beyond the transaction it was scoped to. This is where session keys with over-broad approvals turn one authorized action into an open tab.
Denial of settlement. The attacker consumes the resource, then blocks or delays finality so the payment never lands. This one is not about extracting money. It is about taking the service for free while withholding settlement.
The paper also proves an impossibility result: no output-only pricing can be both fair to honest users and bounded against inflation of hidden computational tokens. Reasoning-token stuffing cannot be solved at the pricing layer alone. That is a design boundary, not a bug to patch.
What a conformance suite catches
Three of the four primitives are testable today, and they map onto existing vectors in the open-source agent-security-harness (532 tests across the agentic-payments stack):
Cross-resource substitution is caught by binding a payment to exactly one target: FB-015 (Voucher Resource-Hash Binding), X4-044 (Payment Replay Against Different Endpoint), and AP2-007 (Mandate Chain Link, which ties a payment mandate to a specific checkout hash).
Duplicate-settlement race is caught by refusing a second delivery on one authorization: X4-038 (Double-Spend Detection), AP2-013 (Double-Spend on Open Mandate), FB-017 (Escrow Over-Redemption), and FB-014 (Batch Voucher Replay and Monotonicity).
Allowance overdraft is caught by bounding what an approval can spend: CTK-003 and CTK-004 (Per-Transaction Amount Cap and Cumulative Velocity Cap), FB-011 and FB-012 (Amount Cap and Velocity Budget), and AP2-015 (Funding-Instrument Scope Binding).
Every one runs as a tamper-then-reject differential. You mutate the input the way the attack does, and a conformant implementation rejects it:
PASS AP2-013: Double-Spend on Open Mandate
PASS FB-017: Escrow Over-Redemption
PASS CTK-004: Cumulative Velocity Cap
What it does not catch
Denial of settlement has no test in the suite. It is a liveness attack, not an integrity one: the malicious move is withholding finality, not tampering with a payload. Rate-limiting vectors are adjacent but not equivalent, and pretending otherwise would be the coverage theater that makes a green test run lie. The honest state is that this attack class is named, understood, and currently untested. It is the next vector to build.
The impossibility result sits even further outside a conformance suite's reach. You cannot write a pass-or-fail vector for a pricing model that is provably unsolvable at its own layer. That belongs in protocol design, not test coverage.
The one decision that closes the race
Most of the duplicate-settlement race collapses to a single architectural choice: what is the authoritative point at which your stack treats a payment as final before it releases the resource?
If the answer is "the facilitator's callback," the race is wide open, because the callback fires before the chain agrees. If the answer is "N on-chain confirmations" or "a signed settlement receipt," the window closes, at the cost of latency you design for.
Test coverage tells you whether your verifier rejects a tampered payment. It cannot tell you where you drew your finality line. That line is where agent payments are won or lost.
If you build on x402, ship the tests for the three primitives you can catch, and write down your finality point for the one you cannot.
Full test-ID mapping and discussion: harness thread #231
Top comments (0)