AI agents are crossing from "draft me an email" to "go do the thing" — and increasingly the thing costs money: buying API credits, booking compute, subscribing to a data source, purchasing ads. The moment an agent needs to pay, you hit an uncomfortable question: how do you give software a budget without giving it your company card number and hoping for the best?
The answer is the same principle that secures any risky system — least privilege, enforced at the point of action. Applied to money, that means a card whose limits live in the payment authorization itself, not in a prompt you hope the model respects.
Why a prompt limit is not a spend limit
Telling an agent "do not spend more than €100" in its system prompt is a suggestion, not a control. Models drift, get jailbroken, loop, or simply miscount. If the only thing standing between your balance and a runaway loop is the model's good behavior, you do not have a spending control — you have a hope. Real controls have to be enforced outside the model, at authorization time, where the agent cannot argue with them.
The safe pattern: a card per agent, with hard limits
1. Issue a dedicated virtual card per agent or task
Give each agent (or each job) its own virtual Visa card. The blast radius of anything going wrong is then capped at that one card, and you get per-agent attribution for free — every charge is tagged to the agent that made it.
2. Set hard limits that authorization enforces
Daily and per-transaction caps should be evaluated by the issuer at authorization. Once a card hits its cap, every further transaction is declined automatically — no human in the loop, no model cooperation required. That single property is what turns "autonomous spending" from reckless into routine.
3. Constrain where it can spend
Merchant whitelists (and category controls) mean an agent provisioned to buy OpenAI credits and cloud compute physically cannot pay an unrelated merchant, even if it is tricked into trying.
4. Keep an instant kill-switch
If an agent misbehaves, you freeze its card with one API call. Spend stops immediately; you investigate; you replace the card if needed. No "cancel the company card and reissue to everyone" fire drill.
Design for the bad day. Assume an agent will, at some point, loop or be manipulated — and make sure the worst case is "one capped card hit its daily limit," not "the account drained."
How agents actually transact
In practice the agent calls an API to request a card or a charge; the issuer evaluates the request against policy — limits, merchant rules, balance — and either authorizes or declines. For in-loop workflows the latency matters: card creation in the low hundreds of milliseconds and authorization decisions under ~100ms keep the agent responsive instead of blocking on payments. Webhooks then stream each authorization back so your system has a real-time ledger of what every agent spent.
What about runaway loops?
This is the failure everyone worries about, and it is exactly what hard limits neutralize. An agent stuck in a loop will hammer the card — and once the daily cap is reached, each attempt is simply declined at authorization. The loop burns retries, not your balance. Add the merchant whitelist and the kill-switch, and a "runaway agent" becomes a log entry rather than an incident.
Auditing every euro an agent spends
Autonomy without an audit trail is a liability. Because each agent has its own card and every authorization streams back over webhooks, you get a per-agent ledger by construction: which agent spent, where, how much, and whether the request was authorized or declined. Month-end reconciliation becomes a query rather than a forensic exercise — and an anomaly, like an agent suddenly spending at three times its usual rate, is visible in real time instead of in next month's statement.
How this compares to the alternatives
Teams usually arrive here after trying one of two things:
- The shared corporate card. Fast to start, impossible to govern: no per-agent limits, no attribution, and one compromised agent exposes the whole card. Fine for a demo, dangerous in production.
- Enterprise card-issuing platforms. Powerful, but access for non-platform companies is often sales-led and US-centric, and EU-native, self-serve, agent-shaped issuing is rarely the default — you can wait weeks before issuing a single card.
The pattern that holds up in production is the boring one: a dedicated card per agent, hard limits at authorization, merchant rules, instant freeze, and an EU IBAN underneath — self-serve, so you ship this week rather than next quarter.
A reference setup
A minimal, safe deployment looks like this: provision one virtual card per agent at startup via API; set a conservative daily cap and a per-transaction cap; whitelist the handful of merchants the agent legitimately needs; subscribe to authorization webhooks into your logging and alerting; and wire a one-call freeze into your incident runbook. Start the caps low, watch real spend for a week, then raise them deliberately. You can always loosen a limit; you cannot un-spend money.
Why EU-native matters here
If your agents and customers are in Europe, paying euro-billed merchants from an EU IBAN avoids FX drag, and a self-serve, EU-licensed issuer means you are not stuck in sales-led onboarding to get programmatic card issuing. 2card is built for exactly this: API-issued virtual Visa cards your agent can use autonomously, with hard limits, merchant whitelists and instant freeze, all behind one EU IBAN via myTU. See the cards for AI agents page for the API details.
Early access is open. Get a card and limit setup tailored to your spend profile — KYB by myTU is fully online.
Explore cards for AI agents