How to Give an AI Agent a Wallet Without Ending Up Broke

Imagine you've tasked an AI assistant with ordering a rare book, paying for a server, or buying a conference ticket. The script reaches the payment form, and then—dead end. Handing over your main card details to an agent is terrifying: one hallucination or buggy parser, and the money goes somewhere it shouldn't. Forcing a person to manually fill out every checkout defeats the purpose of automation.

Stripe engineers have released an interesting utility called link-cli. It solves this problem through Link wallet by issuing single-use virtual cards or tokens for specific transactions only after owner confirmation.

In this article, we'll break down how the tool works, how to connect it to an LLM via the MCP protocol, and what pitfalls to watch out for.

How the Process Works

The entire workflow revolves around the spend request entity. The agent doesn't access your bank account and never sees saved cards.

The flow is straightforward:

1. The agent analyzes the store page, builds a cart, and gathers order parameters.
2. Via CLI, a purchase request is created specifying the merchant, amount, and detailed context explaining the purpose of the expense.
3. A push notification arrives on your phone in the Link app requesting confirmation.
4. After approval, the CLI receives a temporary virtual card or token.
5. The agent inserts the generated credentials into the payment form and completes the purchase.

The --context parameter isn't just for show. Stripe requires a detailed description of at least 100 characters so you know exactly what the charge is for in the push notification. Confirmation must be made within exactly 10 minutes, after which the request expires.

Credential Formats

The utility can return three types of payment data depending on where and how the agent is making the payment.

The first option is a standard single-use virtual card (PAN). It works with any online store using a standard HTML checkout form, even if the site has never heard of Stripe.

The second option is a Shared Payment Token (SPT). This is for scenarios where the merchant supports the Machine Payments Protocol (MPP). Here, payment goes through programmatically via HTTP 402 without emulating browser data entry.

The third option is a Link Pay Token (LPT). If checkout runs on Stripe and the page contains a special block for AI agents, the CLI generates a token directly linked to the merchant's account.

Log Security and Working with MCP

The main headache when handling payments in LLMs is credential leakage. If the utility outputs the full card number and CVC to stdout, this data will linger in the model's context, system prompts, terminal logs, and agent transcripts.

Stripe's developers worked around this with the --output-file argument. The command saves full card data to a local file with 0600 access permissions, while outputting masked JSON to standard output:

Agent takes the file path, passes it to an internal browser runner like Playwright, and only the card brand and last four digits remain in the logs.

For integration with frameworks like Claude Code or Cursor, the utility can run as an MCP (Model Context Protocol) server:

If the agent runs in an isolated container or on a remote server, the link-cli serve command starts a local HTTP endpoint for MCP.

By the way, for communicating with language models, the toon format is used by default. This is a compact text output without JSON syntax noise that saves tokens in the context window.

Limits and Restrictions

The tool is in early stages, so the Stripe team built in strict security boundaries:

• Maximum single purchase amount is limited to $500 (50,000 cents).
• Daily spending limit is also $500, with a monthly cap of $20,000.
• Issued cards or tokens are active for only 12 hours from the moment the request is created.
• No more than 10 confirmed active requests can exist simultaneously.

For local experiments and integration tests, there's the --test flag. It generates test card numbers (for example, 4000009990001984) and doesn't charge real funds from the Link account.

Where This Applies

The utility was created for a specific niche: autonomous scripts and assistants that periodically need to execute transactions on behalf of a person.

Typical use cases:

• Personal agents for purchasing consumables, booking tickets, or subscriptions.
• Automatic balance top-ups in cloud services and third-party APIs when limits are reached.
• Paying for premium endpoints via the Machine Payments Protocol (HTTP 402).
• Load testing and end-to-end testing of e-commerce checkouts.

After a charge attempt, the agent can send a result report via link-cli report, indicating the status (success, CAPTCHA, Cloudflare block, or bank decline). This helps collect failure statistics.

The link-cli project is narrowly specialized, but it addresses a real security gap in autonomous agents. Instead of sharing private keys and credentials, the developer gets a controlled gateway with confirmation of every step via smartphone.

The main downside right now: the tool only works with US-based Link accounts. If you have access to US Link, you can test the utility right now via npx @stripe/link-cli onboard. Everyone else will need to study the TypeScript source code in the repository and wait for geographic expansion.