The latest articles on DEV Community by Emil Dabrowski (@griffnode). https://dev.to/griffnode https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4033577%2F929dfbdc-fa4a-4da3-8004-21ac5e23774c.jpg https://dev.to/griffnode en Emil Dabrowski Fri, 17 Jul 2026 09:59:50 +0000 https://dev.to/griffnode/i-put-my-crypto-payment-gateway-behind-an-mcp-server-so-an-ai-can-run-it-but-never-spend-from-it-51c4 https://dev.to/griffnode/i-put-my-crypto-payment-gateway-behind-an-mcp-server-so-an-ai-can-run-it-but-never-spend-from-it-51c4 <p>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.</p> <p>I build a crypto payment gateway called <a href="https://griffnode.com" rel="noopener noreferrer">GriffNode</a>, 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.</p> <p>And the agent still cannot spend a cent. Not because we sandboxed it well. Because there is structurally nothing to spend.</p> <h2> Why that is safe by construction, not by policy </h2> <p>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.</p> <p>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 <code>send_funds</code> tool because there is no send capability anywhere in the system, for a human or an AI. The dangerous verb does not exist.</p> <p>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.</p> <h2> What the MCP server actually exposes </h2> <p>The tools map to the safe half of the API:</p> <ul> <li> <code>list_payments</code> / <code>get_payment</code> reads payment and invoice state</li> <li> <code>create_payment_link</code> generates a hosted checkout for an amount</li> <li> <code>get_supported_coins</code> returns BTC, ETH, LTC, DOGE, DASH, plus USDT/USDC/DAI</li> <li> <code>get_balance</code> is read-only, derived from on-chain data</li> <li> <code>get_plan</code> / <code>upgrade_plan</code> for account management</li> </ul> <p>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.</p> <h2> The mental model </h2> <p>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.</p> <p>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 <a href="https://docs.griffnode.com" rel="noopener noreferrer">docs.griffnode.com</a> if you want to poke at it.</p> ai crypto mcp showdev