5.18%
Optimistic grant risk
The preprint reports revert-grant exposure when access is released before durable settlement. The control is a named release policy: reserve, wait for confirmations, or explicitly cap the loss.
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.
AWS pushed agent payments into preview on May 7, 2026, and a May 12 x402 security preprint put numbers 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 AgentCore Payments, x402, MPP, Pay.sh, and pay-skills providers.
run surface check
scope private review
read map
build policy
launch checklist
batch checklist
source
- scope
- x402 / MPP
- mode
- no payment
- output
- patch order
may 2026 update
The paper is useful because it measured the failures.
248 grants
Replay over-granting
A live replay test produced many grants from one payment. The launch control is a pre-grant claim keyed by payment intent and exact resource, not raw header bytes alone.
100%
Cache leakage condition
The proxy tests show paid content can leak when shared caching is allowed. x402 Surface Check 0.2.38 makes cache posture, payment-enforcement header drift, resource binding, freshness metadata, payment-metadata privacy, and credential-like registry URLs part of the report.
71.8%
Discovery steering
Metadata manipulation can win an agent's provider choice before payment begins. Registry listings need owner-controlled canonical URLs, exact prices, and low-hype descriptions.
attack classes
Convert the research into controls a buyer can see.
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 orderI-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 metadataresearch deltas
The useful signal is measurable failure, not abstract risk.
replay
Duplicate grants
The paper frames replay as a payment-service correspondence failure: one payment proof should not unlock many resource grants. Treat pay_id + resource_id as a pre-grant claim key.
cache
Paid-content reuse
Shared caches and payment-gated content do not mix. x402 Surface Check 0.2.38 prints a Cache Policy Map, flags explicitly cacheable challenge responses as P1, catches payment-enforcement headers on 200 responses, checks accept-leg resource binding and freshness metadata, redacts sensitive payment-metadata query context, flags credential-like public registry URLs with redacted values, and links the relevant implementation guide when cache, registry, metadata, or CORS findings appear. The Worker starter shows a minimal no-store/private payment gate.
open checker worker guidesettle
Grant timing
Builders need a named release policy: reserve before work, wait for enough finality, or state why optimistic release is acceptable for the value at risk.
discovery
Agent steering
Registry copy, manifest metadata, owner identity, and canonical URLs affect which paid endpoint an agent chooses before any protocol-level payment check begins.
patch 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.
cache
Challenge cache policy
The CLI reports observed Cache-Control on no-payment challenge responses, warns on explicitly cacheable payment gates, and can flag missing cache policy in strict mode.
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.
The market reason to care is equally current: AWS announced AgentCore Payments preview on May 7, 2026, with x402 negotiation, Coinbase and Stripe wallet connections, session spending limits, observability, paid MCP/API access, and the Coinbase x402 Bazaar MCP server available through AgentCore Gateway.
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.