I-A / finality
Grant before finality
A server can release access while a payment is still optimistic, reorg-prone, or only reserved. The launch proof should show exactly when access is granted.
patch order
tate@programs
~/notes/x402-attack-map-2026
payment-agent controls
x402 attack map / may 2026
Map the new x402 failure modes before an agent pays.
A May 2026 x402 security preprint puts names on the practical risks payment-agent builders now need to prove away: premature grants, caller-unbound settlement, replay, header and cache confusion, and manipulated discovery metadata. This page turns those attack classes into launch controls for x402, MPP, Pay.sh, and pay-skills providers.
- scope
- x402 / MPP
- mode
- no payment
- output
- patch order
attack classes
Convert the research into controls a buyer can see.
I-B / settlement
Caller-unbound settlement
Payment verification should be bound to the intended caller, facilitator, amount, chain, token, and resource. Otherwise a settlement proof can drift across contexts.
build policyII / replay
One payment, many grants
Every paid grant needs an atomic idempotency record. The reliable key is not just a transaction hash; it is the payment intent plus the exact resource being bought.
open checklistIII / headers
Proxy and cache confusion
Payment headers should not be merged, duplicated, cached, or exposed through shared layers. Every paid route should send no-store/private cache policy.
run checkIV / discovery
Discovery steering
Agent-readable registries and manifests can steer wallets toward the wrong provider, price, or resource. Discovery metadata needs validation and owner-controlled canonical URLs.
watch queueprivacy / metadata
Payment-request leakage
Resource names, receipts, prompts, user IDs, and query context can leak through payment metadata. Keep the pay envelope minimal and move private detail to internal logs.
filter metadatapatch order
The shortest credible hardening pass.
This is the review order I would use for a live x402 or MPP launch surface before public promotion, especially if agents can trigger real spend.
1. Sign the canonical payment intent
Bind pay_id, resource_id, facilitator, amount, token, chain ID, expiry, and allowed method into the payment challenge or policy object. Do not let clients infer those fields from mutable UI copy.
2. Verify the resource scope before granting
A successful payment should unlock only the endpoint, file, dataset row, API call, or compute job named in the challenge. Wildcard resources are a launch blocker unless the cap and audit trail are very clear.
3. Claim once, atomically
Create an idempotency record before work starts. Use a key that combines payment intent and resource, then reject duplicates, expired challenges, and already-claimed receipts with a visible error path.
4. Pick a release policy
Either reserve funds before execution or wait for enough finality before releasing the paid result. The public docs should say which path is used for demos, production, refunds, and failed settlement.
5. Harden HTTP boundaries
Paid routes should use Cache-Control: no-store, private, avoid shared proxy caching, reject duplicate payment headers, and document which browser headers are required for MPP or x402 clients.
6. Treat discovery as a security surface
Manifests, registry PRs, SKILL files, and docs should point to canonical HTTPS origins, stable owner identities, current prices, and exact networks. Agents should not have to guess which provider is real.
tool coverage
What the public checker can catch now.
endpoint
No-payment 402 probes
Direct endpoint mode checks whether a paid route returns a structured 402 challenge before any payment header is sent.
mpp
MPP header shape
The checker parses pasted WWW-Authenticate: Payment headers and scores amount, network, currency, expiry, and request metadata shape.
cors
Browser payment surface
CORS and allowed headers reveal whether browser agents can send the expected payment fields or whether the integration will fail at launch.
metadata
Leak-prone fields
Manifest, challenge, and pasted JSON review flags prompts, private IDs, token-like values, staging rails, placeholder payees, and broad resources.
source trail
Why this page exists now.
The trigger is the May 12, 2026 preprint Five Attacks on x402 Agentic Payment Protocol. The useful move is not to amplify panic. It is to make each failure mode inspectable in launch docs, route behavior, policy files, and sample transactions.
This field note is intentionally practical: no private probing, no signed payments, no exploit publication. Owner-authorized review should start from public manifests, no-payment challenges, endpoint headers, and repo docs, then move to private patching only with scope.
private pass
Need one x402 or MPP surface mapped against these controls?
Send the manifest, PR, docs, endpoint list, and allowed scope. The pass returns a spend map, attack-control gaps, and patch order before any public write-up.