I put my crypto payment gateway behind an MCP server so an AI can run it but never spend from it

Giving an AI agent access to real money is the part everyone flinches at. And they should. If your payment stack has a "move funds" capability, then any agent you wire into it has a "drain the account" capability too. Tighter permissions do not fix that. They just make the drain slightly harder.

I build a crypto payment gateway called GriffNode, and we shipped an MCP server for it. A merchant can run the entire gateway from Claude, Cursor, or any MCP client, in plain language, with their own API key. Check payments, spin up a payment link, read the balance, upgrade the plan. All of it.

And the agent still cannot spend a cent. Not because we sandboxed it well. Because there is structurally nothing to spend.

Why that is safe by construction, not by policy

GriffNode is non-custodial. Merchants connect an xPub (an extended public key), and we derive a fresh receiving address for every payment. Funds go from the customer straight into the merchant's own wallet. We never hold a balance, and an xPub can only receive, it cannot authorize a spend.

So when you expose that gateway over MCP, the worst an agent can do with the money tools is read state and generate receive addresses. There is no send_funds tool because there is no send capability anywhere in the system, for a human or an AI. The dangerous verb does not exist.

This is the part I think agentic-commerce discussions get backwards. The answer is not a smarter permission model bolted onto a custodial rail. It is a rail where the account the agent operates and the funds themselves are two different things, and the agent can only touch the first.

What the MCP server actually exposes

The tools map to the safe half of the API:

• list_payments / get_payment reads payment and invoice state
• create_payment_link generates a hosted checkout for an amount
• get_supported_coins returns BTC, ETH, LTC, DOGE, DASH, plus USDT/USDC/DAI
• get_balance is read-only, derived from on-chain data
• get_plan / upgrade_plan for account management

Every call is authenticated with the merchant's own API key. The server is a thin, stateless proxy in front of the same REST API our SDKs use. Nothing in the tool surface can move a coin, because the underlying API has no endpoint that can either.

The mental model

If you are building anything that lets an AI act on money, ask one question before you argue about permission scopes: can the underlying system move funds at all? If yes, you are one prompt injection away from a bad day, no matter how careful your allow-list is. If no, the whole class of "the agent drained it" failures is off the table.

Non-custodial plus MCP is a clean demonstration of that. The account is fully operable by an AI, and the money is untouchable by design. Docs and the live MCP endpoint are at docs.griffnode.com if you want to poke at it.