How to Give an AI Agent a Spending Limit With a Virtual Card
Prompt rules are not spending limits. Learn how a virtual card with a weekly cap, category and country locks, expiry and webhooks constrains an AI agent.
How do you give an AI agent a spending limit with a virtual card?
Issue the agent its own virtual card through your bank's or card provider's API, and set the limits on the card itself. A typical setup is a $50 weekly cap, a lock to software purchases, a lock to US merchants, and an expiry at the end of the month. Add a webhook so every charge notifies your system. The card network enforces the limits, so the agent cannot talk its way around them.
TL;DR
- Prompt instructions are not a control. A line like "never spend more than $50" lives in text the model can misread, forget, or be manipulated out of.
- Put the guardrails on the card. Spend cap, merchant category, country and expiry are enforced by the issuer, not by your agent's code or prompt.
- One card per agent keeps blast radius small and makes spending easy to attribute.
- Webhooks replace monitoring. The card provider calls your service on each transaction, so you can log, alert, or reconcile without watching the agent.
- A declined payment is the intended failure mode. If the agent tries to pay $60 on a $50 card, the charge fails, and that is the design working.
- Short-lived cards (for example, expiring monthly) limit how long a leaked or misused card number stays useful.
Why are spending limits in the prompt not good enough?
A prompt is a request. The model reads it and usually follows it, but "usually" is a weak property when money is involved. Several things can go wrong:
- The model misreads a price, a currency, or a billing period.
- A long session pushes the original instruction out of effective attention.
- A tool result, web page, or email contains text that nudges the agent toward a purchase. This is prompt injection, and it is a known attack on agents that browse or read untrusted content.
- A bug in your own wrapper code skips the check entirely.
Code-level limits are better than prompts, but they still depend on your code being correct and on the agent not having a path around it. If the agent holds a real card number with the full account behind it, any failure upstream becomes a real charge.
The pattern in this article moves enforcement out of both places. The creator who demonstrated it put it plainly: the limits are not in the code and not in the prompts, they are on the card.
What does an agent-specific virtual card look like?
The example shown used the Revolut Business API. One API call opened a virtual card for the creator's "second brain" agent, and the response described a card with these properties:
| Control | Value in the example | What it prevents |
|---|---|---|
| Spend limit | $50 per week | Runaway or repeated purchases |
| Merchant type | Software only | Buying anything outside the agent's job |
| Geography | US only | Charges from unexpected foreign merchants |
| Expiry | End of the month | Long-lived credentials sitting around |
| Notifications | Webhook on each use | Finding out about charges after the fact |
The same card was visible in the Revolut Business app, so a human can inspect it like any other card. The key test: if the agent tried to buy something for $60, the card would decline. There is no setting for the agent to change and no instruction for it to override.
Other business card and banking providers offer similar controls, though the exact options, field names and limits vary. Check your provider's documentation before assuming a given lock exists.
How does the pattern work step by step?
- Decide the agent's budget. Start from what the agent legitimately needs to buy in a week, then set the cap near that number, not far above it.
- Create a dedicated virtual card via API. Do this from a trusted service, not from inside the agent. Request the limit, category restriction, country restriction and expiry at creation time.
- Hand the agent only the card details. It never sees your API credentials, your main account, or your company card.
- Register a webhook endpoint. The provider sends an event to your service whenever the card is used.
- Handle events. Log each charge, post an alert to chat, write a record for bookkeeping, or flag anything odd.
- Rotate on a schedule. When the card expires, issue a new one with fresh limits. Treat renewal as a deliberate checkpoint.
Step 2 matters most. The component that creates the card should be separate from the component that spends with it. If the agent could also call the issuing API, it could mint itself a bigger card.
How do category and country locks help?
Card networks tag merchants with category codes, and issuers can allow or block spending by those categories. A software-only lock means an agent that has been tricked into buying electronics, gift cards or travel hits a decline at the point of sale. The merchant's own category decides, not the agent's description of the purchase.
A country lock works the same way. If every vendor the agent should use is a US company, a US-only restriction removes a whole class of odd or fraudulent charges.
These locks are blunt, and that is the appeal. They do not try to judge intent. They narrow the set of possible transactions to something you have already decided is acceptable.
One caveat: category locks depend on how a merchant is classified. A legitimate software vendor may be coded differently than you expect, so test the card with a small known purchase before relying on it.
What do webhooks add?
A cap limits damage, but you still want to know what happened. Without notifications, you would have to check statements or poll an API on a timer.
With a webhook, the provider pushes an event to your service on each card use. From there you can:
- Send a message to yourself when the agent spends anything.
- Save the transaction next to the task that triggered it.
- Alert on patterns, such as several small charges in a row or a declined attempt.
- Feed the data into your accounting workflow.
This is what lets you stop babysitting. The creator described it as the missing piece: a budget for the agent without access to the whole account, and visibility without constant monitoring.
Treat incoming webhooks like any other external input. Verify the signature or secret your provider supplies, so a forged request cannot trigger your downstream actions.
Is a virtual card enough on its own?
No. It handles the money side well, but it does not cover everything.
- Within-limit misuse is still possible. An agent can spend $50 on the wrong software subscription. The cap bounds the loss, it does not prevent a bad choice.
- Recurring charges need attention. A subscription bought on a card that later expires may fail to renew, or may renew on a new card. Decide which behavior you want.
- Data exposure is separate. A card that cannot overspend can still be given to a site you would rather not trust with it.
- Approvals may still belong in the loop. For larger or unusual purchases, a human approval step before the agent receives card details is a reasonable extra layer.
Think of the card as the hard floor under softer controls. Prompts and approval flows reduce how often the agent tries something bad. The card guarantees what happens when it does.
Is this worth setting up for a small agent project?
If the agent never needs to pay for anything, skip it. If it does, the effort is small compared with the alternative of sharing a company card. In the creator's example, the card was created with a real call to the Revolut Business API, and Revolut Business then fired a webhook to the creator's service.
The strongest argument is the failure case. When a prompt-based limit fails, you learn about it on a statement. When a card-based limit fails, the transaction declines and the webhook tells you the agent tried.
Frequently Asked Questions
Can I just tell my agent a budget in the system prompt?
You can, but treat it as guidance, not protection. The model can misread amounts, lose the instruction in a long session, or be steered by untrusted content it reads. A limit enforced by the card issuer holds regardless of what the model decides.
Should the agent be able to create its own cards?
Generally no. Keep card creation in a separate trusted service and give the agent only the resulting card details. If the agent can call the issuing API, it can raise its own limits and the guardrail disappears.
What happens when the agent exceeds the limit?
The card declines the payment. In the example demonstrated, a $60 purchase on a card with a $50 weekly limit would fail. Your webhook and logs can then show you the attempt so you can decide whether to raise the budget.
Do I need Revolut Business to do this?
No. The example used the Revolut Business API, but the pattern applies to any provider that lets you issue virtual cards programmatically with spend limits, restrictions and transaction notifications. Features differ between providers, so confirm what yours supports.
How often should the card expire?
The example used an end-of-month expiry. Pick a period that matches how often you want to review the agent's budget. Shorter lives reduce exposure, but they mean more renewals and more chances for a subscription to lapse.
How we source, write, and correct our articles. Editorial standards
