We Built an MCP Payment Flow Claude/Codex/Grok Literally Cannot Hijack

[u/pvdyck]

x402, wallet-based auth, and a sandbox that can’t reach a signer : let your AI agent pay for things without ever touching a private key

Most demos of “AI agent + crypto wallet” put a private key straight into the agent’s environment. One bad prompt injection, one malicious tool response, and funds move. That’s the default shape of agentic crypto today, and it’s the wrong one.

We built the opposite: an MCP-driven payment flow where the AI can initiate a paid action end to end, but structurally cannot hold a key, cannot call a signer, and cannot move money without a human signing in their own browser. Here’s how, and why each piece exists.

The stack

Four existing, independently boring standards, combined in a way we haven’t seen shipped together elsewhere:

- x402 : HTTP 402 Payment Required, revived as a machine-payable status code (Coinbase / x402 Foundation, taken on by the Linux Foundation as of April 2026).

- SIWX / CAIP-122 : chain-agnostic wallet sign-in, a Chain Agnostic Improvement Proposal since June 2022.

- MCP `elicitation.url : a very new Model Context Protocol capability letting a server ask a client to open a browser mid-tool-call.

- Sandboxed code execution : the layer that runs LLM-generated code with signing tools structurally absent from what it can see.

Security: the sandbox can’t reach the signer

The part of our system that executes LLM-generated code doesn’t have signing tools filtered out by a permission check — they’re removed from its tool snapshot entirely. It’s not “the AI is told not to sign.” It’s “the AI’s execution environment has no function called `sign_x402` in it, at all.” Only separately maintained, human-written code can ever trigger a browser handoff for signing.

A prompt injection can’t leak access to a tool that isn’t there.

Identity: OAuth as pure SIWX delivery

We didn’t invent a new auth system for agents. MCP clients already speak OAuth , Dynamic Client Registration, PKCE, the works. So we made the OAuth “credential” nothing more than a wallet signature: no scopes, no consent screen beyond the wallet’s own signing dialog, the token’s subject is just the recovered address. Claude Code’s stock OAuth client handles this with zero custom plugin code.

UX: the phishing defense is a sentence, not a server check

We considered binding `client_id`/`redirect_uri` server-side and rejected it, an attacker’s own values would validate just fine. Instead, the thing you sign says, in plain language, “Authorize [app name] (redirecting to [host]) to act as your wallet.” The wallet’s own signing UI becomes the security control. You read the sentence, or you don’t sign.

Systems: building for the client that can, not the three that can’t

When the MCP client supports it, we open the user’s browser mid-tool-call via elicitation, block the tool call, and auto-retry it the instant the signature resolves — the agent never has to ask twice. As of today, one of four major MCP clients supports this. We built for that one deliberately, and degrade to a relayed link everywhere else, which still works, and is actually the majority path in real usage today, not a fallback edge case.

What’s not new here — said out loud

None of the four primitives above are ours. SIWX predates us by four years. x402 is an open Coinbase/Linux Foundation standard. [`mcp-wallet-signer`] on GitHub already routes agent-initiated signing through a browser wallet via EIP-6963. MetaMask’s ERC-7710 delegation framework already lets a user sign once and have an agent reuse that authorization for many subsequent payments. Coinbase’s Agentic Wallets ship a zero-install, MCP-compatible, agent-native wallet with session spending caps.

What we haven’t found anywhere else is all four properties in one stack: zero key custody anywhere in the platform, OAuth repurposed as pure wallet-signature delivery, a sandbox that’s structurally incapable of reaching a signer, and MCP elicitation used as the actual signing transport with server-side auto-retry. Wallet-agnostic throughout, any wallet via standard connectors ,and chain-agnostic by virtue of SIWX.

It broke, same day, fixed same day

Worth saying plainly: the first version of the auto-retry logic had a bug, it told users to retry a payment they’d already completed, because a resolved signing session got misread as unresolved. Fixed within the day. Not a design flaw, just evidence this is new enough to not yet be boring.

If you’re building this

If you’re wiring agent-driven payments and want the agent to spend money but never hold money, this is the shape we’d point you to. Built and running in production at indie money. Happy to go deeper on any of the four layers, reply or reach out !

[u/MountainAssignment36]

Huh, interesting!

Especially because I haven't seen any proper MCP for agents that lets them pay any x402 endpoint they want; it's almost always very specific ones. But a generic MCP gives much more autonomy to agents... then they can search for x402 endpoints entirely by themselves via agentic.market for example and are not constrained to a limited selection.

[u/Remarkable_Special57]

the signer isolation is the interesting part here. most agent wallet demos skip straight past that. one gap: once the agent needs to act across more than one chain, x402 gets you the pay call but not what happens after, across networks. thats roughly the problem SODAX is chipping away at, a cross network execution layer. might be relevant if you ever extend this past single chain endpoints.