How an AI agent actually pays: x402, MCP, and agent wallets on Solana

The x402 flow is trivial when the caller is a script you wrote: catch the 402, sign a USDC transfer, retry. It gets interesting when the caller is an autonomous agent — because now three new questions appear that a script never had to answer: whose wallet, who decides to pay, and what stops it overspending?

This piece is the practical wiring for agent payments on Solana: how x402 plugs into the MCP tool loop, which client SDKs an agent uses, and the agent-wallet layer that turns "an agent with a private key" into "an agent with a budget and guardrails."

Two ways x402 meets MCP

MCP is how an agent calls tools. There are two distinct patterns for putting a payment in that loop:

• MCP server wraps a paid API. The MCP server is a bridge: the agent calls a tool, the server hits a paid HTTP endpoint, gets 402 back, the x402 client inside the server pays and retries, and the agent just receives the result. Coinbase ships a reference example of exactly this.
• The MCP tools themselves are paid. Vercel's x402-mcp package lets a server author declare a price per tool — the agent pays to call the tool directly, and the agent itself decides when to authorize.

The load-bearing detail in both: the 402 → pay → retry handshake runs in deterministic code below the model. The LLM picks which tool to call; it does not hand-craft a signature. That separation is what makes agent payments safe to reason about — and it's why your spend controls live in the wallet, not in the prompt.

// Pattern 2 — a paid MCP tool (Vercel x402-mcp, illustrative)
// Server: declare a price on the tool itself
server.paidTool(
  "premium-search",
  { price: 0.001 },          // $0.001 per call, settled in stablecoin
  inputSchema,
  async (args) => doSearch(args),
)

// Client: wrap the MCP client with a paying account
const paid = withPayment(mcpClient, { account: agentWallet })
// The agent calls the tool; payment happens under the hood.

One non-obvious gotcha the docs flag: you need an idempotency policy. Agents retry. Without an idempotency key, a retried tool call can pay twice. This is application-level, not something the protocol solves for you.

The client SDKs (mind the v2 rename)

x402 went through a v1→v2 rewrite in early 2026, and the package names changed. The old unscoped packages (x402-fetch, x402-axios) are deprecated — they get security patches only. The current packages are scoped under @x402/*, and crucially the chain logic is split out:

# Current (v2). Solana lives in @x402/svm.
npm install @x402/fetch @x402/svm

# Deprecated (v1) — don't start here:
# npm install x402-fetch

For the agent side you want @x402/fetch or @x402/axios (the HTTP wrapper that catches the 402 and pays) plus @x402/svm (the Solana exact scheme). There's also an official Python path — pip install "x402[svm]" — if your agent is in Python, including an x402[mcp] extra.

The real question: agent wallets and guardrails

A bare Keypair can sign x402 payments — that's all the facilitator needs. But a raw keypair has no spending limit, no allowlist, and no kill-switch. For anything touching real money you want an agent wallet: a wallet purpose-built to be operated by software within policy. The Solana-capable options, and the one distinction that actually matters:

• Coinbase Agentic Wallets / CDP — MPC wallet with native x402, programmable session caps, per-transaction limits, and time-bound limits ("$1.00, expires in 5 minutes").
• Crossmint — non-custodial smart-contract wallet that enforces per-tx limits, rolling caps, and recipient allowlists on-chain, in the contract itself.
• Privy (now Stripe-owned) — server wallets with an off-chain policy engine: transfer limits, approved-recipient lists, operating-time windows, evaluated per signing request. Has a documented x402 integration.
• SendAI Solana Agent Kit — 60+ Solana actions with a plugin architecture; pairs with a server-wallet provider for the policy layer. (See the solana.new toolkit from the same team.)

The distinction worth internalizing: Crossmint enforces the cap on-chain; Privy and Turnkey enforce it off-chain at signing time. On-chain enforcement means a compromised agent process still can't exceed the limit — the contract refuses. Off-chain enforcement is more flexible and cheaper but trusts the signing service. For a high-value autonomous agent, that's the security trade-off to decide deliberately.

The control stack, from prompt to chain

"What stops the agent overspending?" isn't one answer, it's a stack:

• Spend caps — per-call, per-session, and time-bound limits at the wallet layer. The first and most important line.
• Recipient allowlists — the agent can only pay addresses you approved (on-chain with Crossmint, off-chain with Privy).
• Human-in-the-loop approval — the agent requests a budget or a delegated payment method; a human approves once via a consent UI; the agent then operates autonomously within that grant.
• Mandates (AP2) — Google's Agent Payments Protocol adds cryptographically signed "mandates" as an authorization layer above any wallet, providing a non-repudiable record of who authorized what. x402 plugs into AP2 as the crypto settlement rail via the jointly-published A2A x402 extension.
• Idempotency — to stop retries double-paying, as above.

The honest read

The agent-payments stack is real and shippable today, but it's young, and the failure mode is financial, not a 500 error. Two things are worth being sober about. First, the wallet is your blast radius — fund agent wallets with working balances, not your treasury, and prefer on-chain-enforced caps for anything autonomous. Second, the standards are still moving: the v1→v2 rename already orphaned a generation of tutorials, AP2 and x402 are complementary-but-evolving, and the MCP payment patterns are weeks, not years, old. None of that is a reason to wait — Solana's sub-cent fees make agent micropayments genuinely work where card rails can't — but pin your versions and re-check the package names before you ship.

References

• x402 docs — MCP server with x402
• Vercel — x402-mcp: paid MCP tools
• SendAI — Solana Agent Kit
• x402 — the protocol, wire-level
• PayAI — the facilitator that verifies & settles
• Solana AI agents — the broader landscape

An agent with a wallet is just a liability. An agent with a wallet, a budget, an allowlist, and an idempotency key is a payment system. x402 on Solana gives you the rail; the agent-wallet layer is what makes it safe to point at the open internet.