An AI agent can now look for a supplier, compare offers, fill in an order form and reach the checkout page. Often, it lacks only one thing to finish the task: a way to pay. Handing it the company card would be reckless. Refusing every payment means a human has to step in for each purchase, which cancels much of the point of automation.

Virtual cards dedicated to agents offer a middle path: the agent pays on its own, but within a frame you set in advance. This guide explains how to build that frame.

The risks specific to agents

An agent is neither an employee nor a simple script. It makes decisions from instructions and from what it reads online, which creates particular risks:

• Loops. An agent that believes it failed may repeat the same action, and therefore the same purchase.
• Manipulation. A web page can contain hidden instructions meant to hijack the agent, for example to make it buy something else, or pay more.
• Misreading. An ambiguous instruction can lead to an unexpected amount or merchant.
• Exposure. If a card’s details leak, everything that card can reach is exposed.

No instruction written into a prompt fully protects against these risks. Protection has to come from the card itself: what it can spend, how many times, and how long it exists.

The principle: the card is the limit

The safest rule fits in one sentence: an agent’s card never holds more than you are prepared to lose. Whatever the agent is told, it cannot spend beyond its card’s balance or beyond the limit you set. The worst case is known in advance, and it is small.

At Monerails, agent cards are virtual Visa or Mastercard cards in US dollars, funded from a cards balance kept separate from your collections. Card spending never touches the money your customers pay you.

Choosing the right card

The single-use card is the default choice for an agent that buys: it can be charged only once, cannot be funded or emptied, and closes automatically 30 days after issue if you have not terminated it before. What is left then returns to your cards balance.

Issuing an agent card through the API

An agent card has no human cardholder: it carries the agent’s name. Here is a card with a $50 daily limit and $60 of initial funding (amounts are in cents).

curl https://api.monerails.com/v1/cards \
  -H "Authorization: Bearer $MONERAIL_KEY" \
  -H "Idempotency-Key: card-agent-research-1" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "agent",
    "agent_name": "research",
    "label": "API credits",
    "amount": 6000,
    "spending_limit": { "amount": 5000, "interval": "daily" }
  }'

For a one-off purchase, replace the limit with "single_use": true and load the exact amount. The two do not combine: on a single-use card, the loaded amount is the limit. Your business’s very first agent card is issued by an Owner from the dashboard; later ones can be issued through the API.

Staying in control in real time

Handing out a card does not mean losing sight of what it does. Four mechanisms keep you informed and let you act:

1. Webhooks. Every payment triggers card.transaction, every decline card.authorization_declined. Route them to an alert: repeated declines are often the first sign of an agent stuck in a loop.
2. Instant freeze. POST /v1/cards/{id}/freeze blocks every payment in one call; unfreeze restores it.
3. Termination. POST /v1/cards/{id}/terminate closes the card for good and returns its balance to your cards balance.
4. Idempotency. Every card creation or funding carries an Idempotency-Key: if the agent or your orchestrator repeats the same request, it runs only once.

A simple, safe architecture

For most teams, this pattern is enough:

1. The agent makes a request: amount, merchant, reason.
2. Your service applies your rules: maximum amount per task, list of allowed merchants, human approval above a threshold.
3. If the request passes, your service issues a single-use card for the approved amount and makes it available to the agent for that task.
4. The agent pays. The card.transaction webhook confirms the spend, which you attach to the task.
5. Your service terminates the card, or lets it close on its own.

That service’s API key should have only the rights it needs and stay out of the agent’s reach: the agent never talks to the payment API directly.

Keep a record of every decision

When a person spends, you can ask them why. With an agent, you have to plan for it. For every card issued, keep in your service: the task, the agent’s request (amount, merchant, reason), the rule that accepted it and, where relevant, the person who approved it. Then attach the card.transaction webhook to that entry using the card ID.

This log serves three purposes: understanding an incident, tuning your rules (a limit so low that it blocks legitimate tasks, a merchant to add to the list), and accounting, which finds every expense with its justification.

Common questions

Can an agent go over its limit?

No. Beyond the card’s limit or balance, the payment is declined and you receive card.authorization_declined.

What if the agent is manipulated?

It may attempt an unwanted purchase, but it stays bounded by its card. That is why the limit belongs on the card, not in the agent’s instructions.

One card per agent or per task?

Per task for one-off purchases, per agent for recurring, budgeted spend. Many teams combine both.

What it costs

A Monerails virtual card costs $1 to issue, with no monthly account subscription. Funding a card from the cards balance is free; withdrawing a card’s balance back to the cards balance costs 1.5%. For an agent making one-off purchases, single-use cards loaded with the exact amount avoid those withdrawals. Details are on the pricing page.

Test before you trust

In test mode, cards are issued in a test environment and merchant payments are simulated through the API, approved or declined. Use it to check the hard cases before going live: an agent repeating the same request, an amount above the limit, a freeze in the middle of a task. If your system behaves well in those cases, it will behave well in production.

For the integration, the cards documentation and the llms.txt file are written to be read by your developers and your agents alike. For human uses of the same cards, see our article on virtual USD cards for businesses, and for the full offer, the cards page.