A2X

Concepts

Threat model

A monetized, publicly reachable agent is a larger attack surface than an internal tool. This page lists the trust boundaries A2X assumes, the attacks it handles, and the attacks it explicitly does not.

Trust boundaries

┌────────────────────────────────────────────────────────┐
│  Anonymous caller (any agent, any human, any script)   │
└──────────────────────────┬─────────────────────────────┘
                           │  HTTP + JSON-RPC
                           ▼
┌────────────────────────────────────────────────────────┐
│  x402 middleware      ← verifies payment signature     │
│  A2A handler          ← parses JSON-RPC                │
│  Agent runtime        ← LLM call, tool use, storage    │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│  LLM provider / tools / your backend systems           │
│  (trusted, operator-controlled)                        │
└────────────────────────────────────────────────────────┘

Everything above the first boundary is untrusted input. The SDK validates shape; you must validate intent.

Attacks A2X handles

  • Unpaid calls. The x402 middleware returns 402 until a valid signed payment arrives. No payment, no agent execution.
  • Replay of the same payment. Payment schemes include a nonce; the middleware rejects duplicates.
  • Malformed JSON-RPC. The A2A handler rejects structurally invalid requests before they reach your agent code.
  • Version drift. A2X serves both v0.3 and v1.0 AgentCards from the same instance — clients on either spec can call you.

Attacks you must handle

The SDK cannot see inside your agent. These are on you:

  • Prompt injection. A caller controls the message body. Treat every user part as hostile input. Keep tool permissions narrow; never pipe user text into privileged shell commands, SQL, or unguarded HTTP requests.
  • Tool misuse. If a tool can delete data, charge a credit card, or send email, the payment check does not authorize the tool — it only authorizes a call. Gate sensitive tools with your own checks.
  • Secret exfiltration. process.env is accessible to tools you ship. Scope secrets per tool; never include raw provider API keys in tool descriptions.
  • Cost amplification. One paid call can trigger expensive downstream LLM usage. Cap per-call model tokens, recursion depth, and external fan-out.
  • Denial of wallet. An attacker who floods you with cheap calls costs you LLM tokens faster than they pay for them. Size your x402 price above your worst-case LLM cost with margin.

Attacks out of scope (v0.x)

  • Sybil resistance at the wallet level. x402 doesn't know who a wallet belongs to. If you need per-identity rate limits, layer your own signal (attestations, allowlists) on top.
  • Post-payment content guarantees. x402 proves payment; it does not prove the response was "correct." Content quality remains a product concern.
  • Cross-agent orchestration auth. If your agent calls other paid agents, you pay them. The SDK will ship helpers for delegated spend caps; today that is your responsibility.

Operational hygiene

  • Rotate the wallet that receives x402 settlements if a machine holding its key is ever online.
  • Serve behind HTTPS in production. x402 relies on integrity of the X-PAYMENT header.
  • Log the payment nonce with every call. Replay attempts should be observable.
  • Rate-limit by IP or caller wallet even with x402 — attackers can still burn your LLM budget faster than they pay.

Next