Security research → guardrails

Threat Model: x402 Agentic Payment Attacks + Preflight Mitigations

x402 makes spending an HTTP concern. That also creates a cross-layer attack surface: HTTP authorization happens synchronously, while settlement finality is asynchronous. This page translates known failure modes into concrete pre-payment checks agents can enforce before they sign or send a PAYMENT-SIGNATURE.

Commands

Preflight: can this agent pay this endpoint (strict budget/policy)?

curl -X POST https://ontarioprotocol.com/api/agent/can-pay \
  -H "Content-Type: application/json" \
  -d '{"endpoint":"https://example.com/api/paid-endpoint","agent_policy":"strict","max_spend_usdc":"0.01"}'

Evidence: store a public readiness report (no wallet signature required)

curl -X POST https://ontarioprotocol.com/api/verify/x402-readiness \
  -H "Content-Type: application/json" \
  -d '{"target_url":"https://example.com/api/paid-endpoint"}'

Requirement tampering + downgrade (agent signs the wrong thing)

If the agent does not strictly validate the decoded PAYMENT-REQUIRED requirements, it can be coerced into paying an unexpected asset/network/amount or paying for a different resource than intended.

Evidence: x402 defines that unpaid requests return HTTP 402 with a base64 PAYMENT-REQUIRED object describing scheme, asset, network, amount, and receiver details. If clients accept ambiguous requirements, they can be tricked into signing outside policy.

Fix: Agents should enforce allowlists (network + asset), a max spend cap, and an endpoint binding check (requirements must match the requested URL/method). Treat any mismatch as a deny/review outcome and re-verify via /verify before paying.

Replay + idempotency failures (double-spend / repeated execution)

If an endpoint accepts replayed PAYMENT-SIGNATURE payloads or cannot guarantee idempotent execution, agents can be charged multiple times for the same call or receive inconsistent results after payment.

Evidence: x402 requirements include anti-replay primitives (nonce/expiry patterns) and relies on clients and servers correctly binding authorization to a single execution. Research has highlighted replay/idempotency as a common cross-layer weakness in agentic payment protocols.

Fix: Endpoint builders should enforce one-time use of authorizations and make paid execution idempotent. Agents should set strict retry policies, use unique request ids, and deny endpoints whose verifier report flags missing expiry/nonce or inconsistent payment metadata.

Settlement latency + finality ambiguity ("paid" ≠ "final")

Because settlement is asynchronous, a server can claim success before settlement is final, or a client can treat a tx hash as final too early. That window is where security/latency tradeoffs show up.

Evidence: x402 returns a PAYMENT-RESPONSE header that may include a settlement receipt/tx hash. Treating that as final without on-chain verification can be unsafe, especially under reorg/congestion conditions described in recent research.

Fix: Agents should treat PAYMENT-RESPONSE as a receipt pointer, not as finality. Verify settlement status on-chain (or via an independently trusted indexer) when the spend is material; enforce timeouts and a max-confirmation wait policy; prefer endpoints with consistent receipt semantics across reports.

PII leakage in payment metadata (agents overshare)

Some x402 flows include metadata strings that can inadvertently contain user prompts, identifiers, or sensitive context. That metadata can leak to facilitators, logs, or third parties.

Evidence: Security research on hardening x402 has highlighted that payment metadata (URLs, descriptions, reason strings) can carry PII and recommends filtering before execution or signing.

Fix: Agents should sanitize metadata before signing (no user PII, no secrets, no full prompts). Endpoint builders should avoid requiring or echoing sensitive metadata, and document what metadata is logged or stored. Treat unknown metadata handling as review/deny for autonomous spend.

Discovery poisoning (listing ≠ readiness evidence)

A third-party listing can be honest marketing copy but still point to a broken or malicious endpoint. Discovery needs strict filters to remain agent-safe.

Evidence: Ontario separates /listings (may contain pending) from /discover (strict agent catalog). /discover is positioned as readiness-backed (grade/score + report evidence links), but it is not a safety guarantee.

Fix: Agents should only use /discover as a shortlist, then always run /verify (or validate a recent signed report + integrity endpoint) before paying. Prefer endpoints with a service profile and repeated signed history; deny pending/unknown listings for autonomous spend.

Sources

Open the Trust Standard