Your AI agent needs to buy things. Maybe it's purchasing API credits, paying for a SaaS subscription, buying domain names, or acquiring data. The obvious solution is to give it your credit card number. The obvious solution is also a terrible idea.

When you hand an AI agent your personal or corporate credit card, you are giving non-deterministic software unlimited access to your full credit line. There is no structural ceiling on what it can charge. There is no isolation between the agent's spending and your own. And if the agent is compromised via prompt injection or makes a mistake due to misinterpretation, the blast radius is your entire credit limit.

The alternative is straightforward: give the agent its own budget on its own card. A virtual debit, funded with exactly what the task requires, with a hard spending limit enforced at the payment network level. The agent gets payment capability. You keep your credit card in your wallet.

The Problem: Agents Need Money, But Your Card Is Not the Answer

The moment you give an AI agent the ability to interact with the web autonomously, it encounters paywalls, checkout forms, and payment-gated APIs. This is the reality of agentic workflows in 2026 -- useful tasks often cost money.

Developers typically solve this one of three ways, all of which have serious problems:

Option 1: Share your credit card number directly

You paste your card number into a prompt, an environment variable, or a config file. The agent uses it to make purchases. This is the most common approach and the most dangerous. Your card number is now stored in plaintext wherever the agent's context is stored -- prompt logs, conversation history, model provider databases. The agent has access to your full credit line with no upper bound. If the agent enters a retry loop or misinterprets a purchase instruction, the charges hit your personal card with no structural limit.

Option 2: Set up API keys with spending caps

Some services let you create API keys with soft spending limits. This works for a single service, but it doesn't generalize. Your agent probably needs to interact with multiple services, and not all of them offer API-level spend caps. Even when they do, the limits are advisory -- they are enforced by application code, not by the payment network. A bug, a race condition, or an API change can cause the limit to be bypassed.

Option 3: Manually approve every purchase

You put yourself in the loop for every transaction. The agent requests permission, you approve it, the purchase goes through. This works but defeats the purpose of autonomous agents. If you're approving every purchase, the agent isn't autonomous -- it's a fancy shopping assistant that still requires your attention for every decision. This doesn't scale.

Each of these approaches fails because they don't solve the fundamental problem: the agent needs its own budget, structurally separated from your finances, with a hard ceiling that cannot be exceeded regardless of what the agent does.

For a deeper examination of the risks of sharing your credit card with AI agents, see Should You Give Your AI Agent a Credit Card?

The Solution: Prepaid Cards With Hard Limits

A virtual debit card solves all three problems at once. The card is a separate financial instrument -- it is not connected to your credit card, your bank account, or any other funding source. It is loaded with a specific dollar amount at creation time. That amount is the hard ceiling.

The key properties that make this work for agent budgets:

  • Structural isolation. The card has its own number, its own CVV, its own expiry. It shares nothing with your personal or corporate cards. A compromise of the agent card does not expose your other accounts.
  • Hard spending limit. The card's funded balance is the maximum it can ever spend. This is not a soft cap enforced by code -- it is enforced at the Mastercard network level. No application bug, no prompt injection, no agent error can cause the card to spend more than its loaded amount.
  • Single-use design. The card is created for a specific task, used for that task, and then revoked. No persistent card numbers sitting in config files. No long-lived credentials that accumulate risk over time.
  • Human-in-the-loop funding. The card is funded via Stripe Checkout, which requires human payment approval. The agent cannot create money -- it can only spend what a human has explicitly authorized.

This is the model AgentCard implements. The mechanics are straightforward.

Step-by-Step: Setting Up an Agent Budget

Step 1: Install the CLI

$ npm install -g agent-cards

This installs the agent-cards CLI globally. It handles account management, card creation, balance checking, and card revocation.

Step 2: Create your account

$ agent-cards signup

Follow the prompts to create an account and authenticate. This is a one-time setup.

Step 3: Create a card with a specific budget

# Create a $15 budget for a research task
$ agent-cards cards create --amount 15

Card created: card_abc123
Amount: $15.00
Status: active

The --amount flag sets the budget in USD. This is the hard ceiling. The card is now a live virtual debit card that can be used anywhere Mastercard is accepted online. It has exactly $15.00 on it and will decline any transaction that would push the total charges above that amount.

Step 4: Connect via MCP

Add the AgentCard MCP server to your AI tool's configuration. For Claude Code, add it to your MCP settings. For Cursor, add it to your MCP configuration file. The MCP server exposes six tools:

  • create_card -- issue a new card with a specified amount
  • get_card_details -- retrieve card number, CVV, and expiry
  • list_cards -- list all cards on the account
  • check_balance -- check remaining balance on a card
  • get_funding_status -- check if a card has been funded
  • close_card -- revoke a card immediately

Once connected, your agent can create cards, check balances, and use card credentials for purchases -- all through MCP tool calls, with no card numbers in prompts or environment variables.

Step 5: Monitor and revoke

# Check remaining budget
$ agent-cards balance card_abc123
Remaining: $11.53 of $15.00

# Revoke the card when done
$ agent-cards cards close card_abc123
Card closed: card_abc123

When the task completes, revoke the card. Any remaining balance is no longer accessible. This is the correct default -- don't leave cards active after their task is done.

Budget Patterns for Different Workflows

How you structure agent budgets depends on how your agents work. There are three common patterns, each with different tradeoffs. For a full treatment, see How to Set Spending Limits on AI Agents.

Per-task budgets

One card per task. The most secure and easiest to audit. Each task gets a card funded with exactly what it should cost, and you can see the actual spend for each task by checking the card balance when it completes.

# Task: purchase a domain name (~$12)
$ agent-cards cards create --amount 15

# Task: buy an API subscription (~$29/mo)
$ agent-cards cards create --amount 35

# Task: purchase a dataset ($5)
$ agent-cards cards create --amount 7

Notice the amounts are slightly above the expected cost. This accounts for taxes, processing fees, and minor price variations. The goal is to give the agent enough room to complete the task without giving it a blank check. A $15 card for a $12 domain purchase means the maximum exposure from a mistake is $15, not your entire credit line.

Per-session budgets

One card for a multi-step agent session. The agent makes multiple purchases across the session, drawing from a single budget pool. Less granular than per-task, but simpler to manage when the agent's workflow involves many small, unpredictable purchases.

# Multi-step research session with various small purchases
$ agent-cards cards create --amount 50

The tradeoff here is clear: you lose per-step cost attribution in exchange for operational simplicity. The total session cost is still capped, but you can't see which purchase was for which step without reviewing the transaction history.

Recurring budgets

For agents that run regularly on a schedule (daily scrapers, weekly report generators, monitoring agents), create a new card for each run. Don't reuse cards across runs. Each run gets a fresh card with a fresh budget, and you can compare actual spend across runs to catch anomalies.

# Daily monitoring agent -- $5 budget per run
$ agent-cards cards create --amount 5

If yesterday's run cost $2.30 and today's run cost $4.90, that is useful signal. If you use a single persistent card, that signal disappears into the aggregate balance.

Why Soft Limits Don't Work

A soft limit is a number in a database or a variable in code that gets checked before authorizing a transaction. It looks like security. It is not security. It is a suggestion that your code follows -- until it doesn't.

Soft limits fail for AI agents in several specific ways:

  • Code bugs bypass them. A race condition, an off-by-one error, or a missed check in an edge case means the limit is not enforced for that transaction.
  • Agents can route around them. If the soft limit is implemented in a middleware layer, the agent might find a path to the payment API that doesn't go through that middleware.
  • They don't survive restarts. If the running total is stored in memory and the process restarts, the counter resets. The agent gets a fresh budget it shouldn't have.
  • They are advisory, not structural. The credit card underlying the soft limit still has its full credit line available. The soft limit is just a filter in front of it. Remove the filter -- through a bug, a configuration change, or a deployment error -- and the full credit line is exposed.

A debit card's balance is not a soft limit. It is the actual amount of money available. There is no underlying credit line to fall through to. The Mastercard network enforces the limit at the transaction level, completely independent of your application code. Your code can have any number of bugs and the card still cannot spend more than its loaded amount.

For a detailed look at how single-use card isolation works as a security model, see Single-Use Virtual Cards for AI: How the Security Model Works.

What About Credential Security?

Giving the agent a card is only half the problem. The other half is making sure the card credentials are handled securely. A few rules:

  • Never put card numbers in environment variables. Env vars are logged, inherited by subprocesses, and exported to observability tools. CARD_NUMBER=4xxx in your shell is a credential leak.
  • Never put card numbers in prompts. The agent should receive a card ID (opaque reference), not a card number. The MCP get_card_details tool retrieves credentials at runtime when needed, through an authenticated channel.
  • AgentCard encrypts credentials at rest with AES-256-GCM. This provides both confidentiality and integrity verification. Card numbers are never stored in plaintext.
  • Revoke cards when tasks complete. Don't leave active card credentials sitting in the system after the task is done. Revoke immediately via close_card.

The Budget Conversation Your Agent Should Have

A well-designed agent should be budget-aware. Before making a purchase, it should check its remaining balance using the check_balance MCP tool. If the balance is insufficient, it should report that to the caller rather than attempting a transaction that will be declined.

// Agent checks budget before purchasing
const balance = await mcp.call("check_balance", { card_id });

if (balance.remaining < estimatedCost) {
  return {
    status: "insufficient_budget",
    remaining: balance.remaining,
    needed: estimatedCost,
    message: "Task requires more budget than currently available on card."
  };
}

This is a better failure mode than a hard decline mid-checkout. The agent fails gracefully with useful context, and the human operator can decide whether to fund a new card with a larger amount or adjust the task scope.

Frequently Asked Questions

How do I give an AI agent a budget without giving it my credit card?

Create a virtual debit card with AgentCard, funded with exactly the budget you want to allow. The agent gets its own card number, completely separate from your personal or corporate credit card. Run agent-cards cards create --amount <n> to issue the card, then connect it via MCP. The agent can spend up to the loaded amount and no more.

What's the safest way to let an AI agent make purchases?

The safest way is a virtual debit card with a hard spending limit enforced at the payment network level. The card is funded with a specific amount before the agent runs, and the Mastercard network declines any transaction that would exceed the balance. This is safer than sharing a credit card, setting soft limits in code, or using API keys with spending caps that can be bypassed.

Can I set a hard spending limit on an AI agent?

Yes. AgentCard virtual debit cards enforce hard spending limits at the payment network level. When you create a card with --amount 25, the card can process charges up to $25.00 total. Any transaction that would exceed the remaining balance is automatically declined by the Mastercard network. No application logic or soft cap is involved.

What happens if my AI agent tries to spend more than its budget?

The transaction is declined by the Mastercard network. The agent receives a payment failure response and cannot complete that purchase. There is no overdraft, no grace period, and no way for the agent to override the decline. The card's loaded balance is an absolute ceiling.