An AI agent that can spend money is only as safe as the controls around the card it uses. Teams often start by writing the budget into the prompt — 'never spend more than €50' — and assume that holds. It does not. A model can misread, loop, get jailbroken, or simply do the wrong arithmetic. Real spend controls for AI agents live in the payment rail, where they are enforced regardless of what the model decides. This article covers the controls that actually contain an agent and how to wire them up.
Why a prompt limit is not a spend limit
A prompt instruction is a request, not a constraint. The model is free to ignore it. The failure modes are mundane and common:
- Loops: an agent retries a failing purchase dozens of times, each one a real charge.
- Misinterpretation: 'budget' is read as per-item rather than total, or per-day rather than per-month.
- Prompt injection: a malicious page or tool output tells the agent to buy something, and it complies.
- Tool errors: a quantity field is filled wrong and the order is 100x too large.
None of these are exotic. They are the ordinary behaviour of probabilistic systems acting in the world. The fix is not a better prompt; it is a hard boundary the agent cannot cross even when it tries.
Hard limits enforced at authorization
The single most important control is a per-card hard limit enforced at authorization. With 2card for AI agents, each card carries a spend ceiling checked by the issuer when the transaction is presented — not by your code, and certainly not by the model. If a charge would exceed the limit, it is declined at the network. The agent can attempt the purchase as many times as it likes; it will keep getting 'no'.
This matters because authorization-time enforcement is the only layer the agent has no access to. It cannot edit the limit, cannot argue with it, and cannot route around it. The worst-case loss on any card becomes a known, bounded number you set in advance.
Design every agent card around a simple question: if this agent went completely wrong right now, how much could it spend before a human stepped in? The hard limit is your answer, written down and enforced.
Merchant whitelists: where, not just how much
Limiting the amount is half the job. The other half is limiting where. Merchant whitelists let a card transact only with approved merchants or categories, so an agent tasked with buying cloud compute cannot suddenly pay an unrelated vendor. Combined with a hard limit, you constrain both the size and the destination of spend: a small ceiling at a short list of allowed merchants is a tight, well-understood box.
This is particularly valuable against prompt injection. Even if an agent is tricked into trying to pay an attacker, a card that can only reach your approved suppliers will decline the attempt outright.
One card per agent — contain the blast radius
Issuing one card per agent, or even one per task, turns a shared liability into isolated cells. If a single agent misbehaves, only its card is affected; freezing it stops that agent without touching the rest of your fleet. Because 2card's API creates cards in roughly sub-200ms, per-agent or per-task issuance is cheap enough to do by default rather than as a special case.
Per-agent cards also make spend legible. Every transaction is already attributed to a specific agent, so reconciliation, cost tracking and anomaly detection fall out naturally instead of requiring you to untangle a shared card statement. We cover the broader pattern in our piece on payments for AI agents.
Instant freeze and the kill-switch
When something does go wrong, speed is everything. Instant freeze is your kill-switch: one API call (or one click) stops a card immediately, and replace issues a fresh one when you are ready to resume. The right operational posture is to freeze first and investigate second — stop the bleeding, then read the logs.
Wire the kill-switch into your monitoring, not just your dashboard. If you detect a spike in authorizations, repeated declines, or spend velocity outside the normal envelope, your system should be able to freeze the offending card automatically via the API and alert a human. Webhooks on card and transaction events give you the real-time signal to drive that automation.
Containing the runaway loop
Put the controls together and a classic failure — the runaway loop — becomes a non-event. Suppose an agent gets stuck re-buying the same item:
- The hard limit caps total spend; once hit, every further attempt is declined at authorization.
- The merchant whitelist ensures even valid charges only reach approved vendors.
- The per-agent card confines the damage to one agent's bounded ceiling.
- Your webhook-driven monitoring spots the burst of declines and freezes the card automatically.
The loop still happens — models will be models — but it spends nothing beyond a small, known cap and is shut off in seconds. That is the difference between a controlled system and a hopeful one.
A short checklist before you let an agent pay
- Hard per-card limit set at authorization, sized to worst-case tolerance.
- Merchant whitelist restricting destinations to known suppliers.
- One card per agent (or per task) to isolate blast radius.
- Freeze/replace wired into automated monitoring as a kill-switch.
- Webhooks feeding anomaly detection on velocity and declines.
Treat the prompt as guidance and the card controls as law. The model proposes; the authorization layer disposes. That separation is what makes autonomous spending safe enough to run in production.