An approval queue that fires on every purchase gets approved on every purchase. Give a person enough of them and they start clicking without reading the amount, which leaves you a record saying a human consented to something nobody read. That is weaker than no approval step at all, because the record now carries a name. Require approval nowhere instead, and the first surprise purchase is also the first anyone hears about it.
Approval is a budget, and what you spend is one person's attention. Here is how to spend it where a person changes the outcome.
What does an approval step cost?
An approval step costs two things. The agent stops until someone answers, and a person spends attention that does not grow when your agent count does. The second cost is the one that breaks. Attention is fixed, approval volume rises with every agent you deploy, and the queue turns into a stamp long before anyone decides that it should.
Latency is the visible cost and the smaller one. An agent waiting nine minutes on a $30 purchase is an irritation, and on every purchase it is a workflow nobody keeps. The stamp is the expensive failure: once a reviewer stops reading, every approval in your record becomes weaker evidence.
When should an AI agent purchase require human approval?
When a person could plausibly answer no. Four conditions make that likely: the amount sits outside the range this agent normally spends, the merchant is one this agent has never paid before, the purchase is hard to reverse, and it starts a recurring charge rather than a single one. A purchase that trips none of them rarely improves with a second pair of eyes.
Amount only means something relative to the agent spending it. Four hundred dollars is unremarkable for an agent buying compute and alarming for one that books meeting rooms, so the range belongs on the agent rather than the account.
A first payment to a merchant this agent has never used is where a wrong destination shows up. An agent that invents a vendor or follows a manipulated instruction has to pay someone new to do damage, and [hallucinated purchases](/blog/ai-agent-hallucinated-purchases) land where the agent has no history.
Reversibility decides what the approval is worth. A monthly seat you can cancel next week is a mistake with a cheap undo. A non-refundable booking or a prepaid data balance is where the yes does the work.
Recurring charges deserve approval well below your one-off threshold. A $40 monthly subscription is a $480 decision an agent makes once and never revisits.
Which purchases get allowed, escalated, or blocked?
There are three outcomes, and most purchases belong in the first. Auto-allow the routine spending that sits inside the pattern this agent has already established. Escalate the purchases where a person answering yes or no changes what happens next. Block the ones you would refuse every time, since routing an unapprovable purchase to a queue wastes the reviewer and trains them to skim.
| Purchase situation | Control |
|---|---|
| Repeat charge, merchant already used, amount in the agent's usual range | Auto-allow |
| First payment to a merchant this agent has never used | Escalate for approval |
| Amount well above this agent's normal range | Escalate for approval |
| Non-refundable or hard to cancel, any amount | Escalate for approval |
| New recurring charge, any amount | Escalate for approval |
| Merchant category ruled out for this agent | Block |
| Past this agent's budget for the period | Block |
The blocked rows are where teams lose reviewer goodwill. A purchase you would refuse every time does not need a person, and sending it up lengthens the queue for everything else.
What does a person need to see to decide in under a minute?
Four facts, carried in the request itself: which agent is asking, how much, which merchant, and why now. If the reviewer has to open a dashboard, find the agent and reconstruct what it was working on, the request already costs more than most purchases are worth. A request that fits in a phone notification gets a considered answer.
Why now is the field most often missing, and the one that makes the decision fast. "Research agent, $180, first payment to this vendor, needs the API tier to finish a sweep due today" can be answered while walking. "$180 pending approval" cannot.
Settle in advance what silence means. A request nobody answers should not become a purchase by default, and approval that expires into a yes is the rubber stamp again with the person removed.
Where the thresholds come from
Your finance team, not your vendor. The first number is what this function already spends in a month. The second is what one mistake can cost before it has to be explained upward. Both move once you have watched an agent spend for a month, and the escalation line can then sit just above the range you observed.
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 that carries the approvals alongside the purchases. A purchase outside policy is blocked or escalated for approval while the merchant is still waiting on the authorization. Whether [a control sits at authorization or in reconciliation](/blog/authorization-time-control-vs-reconciliation) decides if the person's answer can still change anything.
What to ask
- Can I set thresholds per agent, or one threshold for the whole account?
- What does the approval request show, and can a person decide without opening a dashboard?
- What happens when nobody answers in time, and can I choose that behaviour?
- Does the record name who approved each purchase, or only that approval happened?
- Can I change a threshold without a deploy, and who is allowed to?
FAQ
When should an AI agent purchase require human approval?
When a person could plausibly say no. Four conditions make that likely: the amount is outside this agent's normal range, the merchant is new to this agent, the purchase is hard to reverse, and it starts a recurring charge instead of a one-off. Purchases meeting none of those are better auto-allowed inside a per-agent budget.
Does requiring approval on every purchase make agent spending safer?
No. A reviewer facing every purchase stops reading and starts clicking, which produces a record of consent nobody examined. That is weaker evidence than an empty record, because it carries a name against each purchase. Approval works when it stays rare enough to get read.
What should a human approval request contain?
Which agent is asking, how much, which merchant, and why now. Those four facts let a person answer from a phone notification. Omit why now and the reviewer has to open a dashboard and reconstruct the agent's task, which is where queues cost more than the purchases they cover.
What happens if nobody approves in time?
Whatever you decided in advance, and it should not be a purchase. A request that expires into a yes removes the person while keeping their name on the record. Set that behaviour when you set the threshold, and make sure the agent is told which way it went.
---
For where approval sits among the questions vendors sell together, [identity, authorization and audit are three separate problems](/blog/agent-identity-vs-authorization-vs-audit). 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).