Short answer: give an AI agent four limits and enforce them where the payment is authorized, not in the prompt. Cap each purchase, cap the total for the task, restrict who it can pay, and set an end date. A purchase that breaks any limit should be declined or paused for a person. This is the practical core of AI agent spend controls.
Why limits alone are not a control
Most teams start by giving an agent a card with a credit limit. That is a single number: the most the agent could ever spend. It does not say what the agent may buy, from whom, or by when. If the agent misreads a task, or follows text planted on a web page, every purchase under the limit still goes through. Good limits are specific to the task and are checked on every payment.
The limits worth setting
1. Per-purchase cap
The largest single payment the agent may make. It stops one bad quote or one wrong product page from consuming the whole budget. Set it near the expected price of the task, not near the budget.
2. Total budget for the task
The most the agent may spend across all purchases for one job, such as a trip or a research subscription. Track the remaining balance so a later purchase is compared with what is left, not with the original figure.
3. Merchant and category limits
An allow-list of merchants, or a clear category, narrows the damage if the agent is steered somewhere unexpected. Category codes on cards are coarse, so a merchant list tied to the task is stronger. See why card limits and MCC blocks aren't enough.
4. Time window
A start and end date. Purchases after the window closes are declined. An agent that finishes its task should not keep a live spending ability.
5. Velocity
A cap on how many purchases can happen in a short period. Many small payments in minutes is a pattern worth pausing, even when each one is under the per-purchase cap.
Per-transaction, daily and monthly limits compared
| Limit | What it bounds | What it misses |
|---|---|---|
| Per transaction | Size of one payment | Many payments, wrong merchant |
| Daily or monthly | Worst-case spend in a period | What was bought and why |
| Total task budget | Overall cost of a job | Merchant, timing |
| Merchant allow-list | Who can be paid | Amount within an allowed merchant |
| End date | How long the ability lasts | Anything inside the window |
No single row is enough. The limits work as a set, which is why a mandate that combines them is a better unit than a number on a card. See one-time virtual cards vs spend mandates.
Where the limits must be enforced
There are three places a limit can live. In the prompt, it is a request the agent may ignore. In the agent's own code or tool wrapper, it is only as reliable as the agent and its libraries. At card authorization, it is a check the payment must pass before money can move. Only the last holds when the agent is confused or manipulated.
Authorization-time enforcement also gives you a record. Each approve or decline can be tied to the mandate that allowed or refused it, which is what finance and audit teams ask for. For more on the approval side, read human-in-the-loop approval for AI agent purchases.
A worked example
Suppose an agent is asked to book a conference trip. A person approves a mandate: travel and lodging merchants only, up to 1,800 in total, no single purchase above 900, valid for ten days. The agent books a flight for 620 and a hotel for 740. Both pass. It then tries a 400 purchase at an unrelated electronics store. The merchant is outside the list, so the payment is declined, and the decline is recorded against the mandate. A 950 hotel quote would exceed the per-purchase cap and could pause for a person instead.
Choosing the numbers
- Start tight. Raising a limit after a good run is easy; recovering from a bad one is not.
- Base caps on the task's expected cost plus a margin, not on the card's credit line.
- Review declines. A pattern of declines on a legitimate merchant means the mandate needs updating, not that the limits are wrong.
- Keep approvals for exceptions so people read them.
How Levee fits
Levee is the authorization layer for AI agent spend. Levee lets a human approve what an agent may spend, enforces it at the moment of card authorization, outside the agent, and keeps tamper-evident proof of every decision. Cards issued through Airwallex are the first live rail, and Levee never holds or moves money. Authorization declines purchases outside the mandate, which bounds the damage if an agent is misled; it does not claim to stop every attack. Read the full guide to AI agent spend controls or see levee.dev.
Frequently asked questions
What spending limits should an AI agent have?
At minimum a cap per purchase, a total budget for the task, an allowed merchant list and an end date. Add a limit on how many purchases can happen in a short window, and a rule that anything outside these pauses for a person or is declined.
Is a daily limit enough for an AI agent?
No. A daily limit bounds the worst day but says nothing about what was bought, from whom, or for what purpose. Pair it with merchant and purpose limits so a purchase inside the cap can still be refused.
Where should AI agent spend limits be enforced?
At the moment of card authorization, outside the agent. Limits written into a prompt or checked by the agent's own code depend on the agent behaving. A check the payment must pass does not.
What happens when an agent hits its limit?
The purchase should be declined, or paused for a person to approve when it is a close call. Declining by default is the safe behavior if nobody responds.
Does Levee set the limits?
A human approves a mandate with the limits above, and Levee checks each payment against it at card authorization. Levee is the authorization layer; Airwallex is the card issuer, and Levee never holds or moves money.
Related
Levee is running a free design partner pilot for platforms putting AI agents in charge of spend.
Become a design partner