A spending limit exists in one place: the moment a merchant asks whether to approve a charge, and something answers. The number in your system prompt, the constant in your purchasing service, the threshold on your finance dashboard, none of those are in that conversation. They describe what you'd like to happen. The merchant reads none of them, and the charge clears or it doesn't on an answer that came from somewhere else.
Here's how to tell which kind of limit you've got, and what you're left holding when an agent goes past it.
What's the difference between a checked limit and an enforced one?
A checked limit is read by something inside your own stack before it decides whether to attempt a purchase. An enforced limit is applied by whatever answers the merchant's authorization request, outside the agent's reach. The first one works when your agent behaves the way you expected. The second one works when it doesn't.
That distinction sounds academic until you write down who is doing the checking. In most agent deployments, the party reading the budget and the party spending the money are the same process. You've asked the thing you're constraining to constrain itself, and you find out whether it agreed when the statement arrives.
Where does your spending limit live?
In one of four places: the system prompt, your application code, a monitoring threshold, or the authorization decision on the card itself. All four look alike in a design document and behave nothing alike the first time an agent goes past the number. Only the last one is in the path of the money while the money is still yours.
| Where the limit lives | What it is | What happens when your agent exceeds it |
|---|---|---|
| The system prompt | An instruction the model weighs against everything else in its context | The purchase clears. You learn about it from the statement. |
| Application code | A check on the purchase paths you wrote | Blocked on those paths. A merchant reached another way clears. |
| A dashboard threshold | A read of transactions that already settled | An email, minutes or days later. The money left before it was sent. |
| The authorization decision | Your policy applied while the merchant is waiting | Blocked or escalated to a person for approval before the charge clears |
Three of those rows produce a record. One of them produces a decision.
Why does a budget in the prompt come apart?
Because a prompt is one instruction among everything else the model is reading, including the page it just fetched, the tool result it just got back, and a user asking for something urgent. The budget line carries no standing above any of them. And the model holds no running total of what it has already spent unless you build one.
The case that costs you money looks reasonable from the inside. Your agent finds the vendor you approved is out of stock, finds the same item at a supplier charging four times as much, and buys it, because buying it satisfies the task you gave it. Nothing was jailbroken. Every step is defensible and the total is wrong. That's a different failure from a model acting on information it made up, which [hallucinated purchases](/blog/ai-agent-hallucinated-purchases) covers, and a budget written into a prompt stops neither.
Application code is stronger, and it's bounded by your ability to predict every route to a merchant. An agent that checks out through a browser tool, or through a server someone connected last Tuesday, never touches the purchasing service where your check lives. [The mechanisms agents use to authorize payments](/blog/five-ways-ai-agents-authorize-payments) keep multiplying, and each one is a path your code doesn't cover.
What does a limit that only reports cost you?
The difference between a decision and a recovery. A dashboard tells you the number was passed and can't unpass it. What you're left with is a chargeback you may not win, a conversation with a vendor who did nothing wrong and owes you nothing, or a write-off. Each one takes a person days.
Timing is the whole argument. [Authorization-time control and reconciliation](/blog/authorization-time-control-vs-reconciliation) answer different questions, and reconciliation answers a question about the past.
The charge that hurts is usually small. An agent signs up for an annual plan on a service it needed once, the vendor's refund window is fourteen days, and nobody opens the report until the month closes. No threshold built for large amounts catches it, and it renews next year unless a person remembers.
What has to be true for a limit to bind?
Two properties, and neither one is about the agent. The limit has to be applied by a party the agent can't edit or route around. And it has to be applied while the merchant's authorization request is still open, because that's the only window in which the answer changes anything. Get both and the number is a control.
Shatale issues agent-scoped virtual cards with your policy enforced at the authorization moment, human approval workflows above the thresholds you set, and an immutable per-agent record of every decision. A purchase outside policy is blocked or escalated to a person for approval while the merchant is still waiting on the answer, rather than found in next month's reconciliation.
The four rows above aren't ranked by effort. Writing the number into a prompt takes a minute, and it covers you until the day it doesn't.
What to ask
- Where is our spending policy stored, and can the agent read or edit it?
- At what moment in the transaction is that policy evaluated?
- If an agent reaches a merchant through a tool we didn't build, does the limit still apply?
- When a purchase goes past the threshold, is it blocked, escalated to a person, or recorded for us to find later?
- Who gets asked for approval above the threshold, and what happens to the purchase while they decide?
FAQ
How do you enforce a spending limit on an AI agent?
Put the limit on the purchasing instrument rather than in the agent's instructions, so a party the agent can't edit applies it. A limit evaluated at the authorization moment can block a charge or route it to a person while the merchant is still waiting. A limit in a prompt gets read after the decision.
Can you set an AI agent's budget in the system prompt?
You can, and it will work most of the time. A prompt is one instruction among everything else in the model's context, including the page it just read and the tool result it just received, and it carries no standing above them. A prompt budget is guidance. The account keeps whatever limit you gave the account.
What's the difference between a spending limit and a spending alert?
An alert reads transactions that already settled. A limit applied at the authorization moment answers the merchant while the charge is still pending, so a purchase outside policy is blocked or escalated for approval. Both produce a record. Only one changes what happens to the money.
Why isn't a limit in application code enough?
It covers the purchase paths you wrote. An agent that reaches a checkout through a browser tool, a partner API, or a server someone connected last week never passes through your purchasing service, so your check never runs. Code-level limits are worth having, and they're bounded by the routes you managed to predict.
---
[Cutting an agent off in one move](/blog/revoke-agent-spending-kill-switch) is the same argument at the other end of the incident. Early access is free for publishers.
Shatale is the control layer for AI-agent payments. Its authorization architecture is the subject of European patent application EP26194994.5 (filed; priority 28 July 2026).