How to control AI agent spending with human approval gates
A purchasing agent should handle reversible work independently and stop before a meaningful financial commitment. A sound policy combines spending caps, decision context, and safe behaviour when conditions are uncertain.
/1. Define more than one budget limit
One cap is not enough. Set a maximum per action, a daily or monthly cumulative amount, and category limits where useful. State the currency: 100 EUR and 100 GBP are not interchangeable.
- Per-transaction cap to contain one mistake.
- Cumulative budget to prevent a sequence of small purchases.
- Explicit market and currency for FR, GB, and ES.
/2. Classify actions by risk tier
Allow reads and simulations automatically. Require approval for an offer, payment, contact reveal, or budget increase. Block out-of-policy actions rather than routing every one of them to a human.
/3. Present an understandable request
The request should summarize the seller, item, amount, currency, fees, market, the agent's reason, and the policy that triggered. Add an expiration and show exactly what will change if the owner approves.
- Show total cost, not only the headline price.
- Bind the request to the agent identity and target resource.
- Offer explicit outcomes: approve, deny, or let it expire.
/4. Execute once after approval
An approval must authorize one exact action, not grant general permission. After approval, use an idempotency key so a network retry or double click cannot create a second offer. Reject execution if amount, target, or currency differs from the approved request.
- Consume approval only once.
- Re-evaluate policy immediately before the write.
- Fail safely when a request expires or changes.
/5. Measure and improve the policy
Keep the timestamp, triggered rule, decision maker, outcome, and request identifier. Review denials, expirations, and prevented bypasses. If almost every identical request is approved, cautiously tune a threshold instead of removing the control.
- Alert on repeated attempts after a denial.
- Test revocation for both agents and approvers.
- Separate policy changes from purchase execution.
/Example approval tiers to adapt to your own risk policy
| Risk tier | Example | Default decision | Evidence to retain |
|---|---|---|---|
| Low | Read-only search or comparison | Allow within the declared scope | Query, sources, and agent identity |
| Medium | Reversible reservation or seller message | Allow only within a narrow policy | Policy version, inputs, and result |
| High | Payment, binding purchase, or irreversible action | Require human approval | Approver, decision time, amount, and final outcome |
/Frequently asked questions
Should every agent action require approval?
Not necessarily. Read-only and low-impact actions can follow a documented allowlist, while financial, binding, or irreversible actions should cross an independently enforced approval boundary.
Can the model decide whether its own purchase needs approval?
The model may describe context, but the final gate should be enforced by server-side policy using trusted inputs such as amount, action type, account, and market.
What belongs in an approval record?
Keep the actor, agent, requested action, material parameters, policy version, decision, approver when applicable, timestamps, request ID, and outcome.
/Sources and review basis
The governance model was reviewed against the following primary material on 18 July 2026.
Configure controlled purchases
Explore budgets, thresholds, and approval gates in Policy Control.