How do I stop an AI agent from splitting one large purchase into many small ones to dodge an approval threshold?

What should I check, step by step?

1. Write the threshold as two numbers: per_tx_max_minor (the largest single purchase allowed without a human) and daily_max_minor (the largest total allowed without a human in a day). The second number is the one splitting can't get past.

2. Set both with set_spend_policy on the agent's credential, plus allowed_domains, so each authorize_spend call checks the amount, the day's running total and the merchant together.
3. Make the agent request authorization for the whole order: one authorize_spend per cart or invoice, with amount_minor set to the full total and reference set to the order or cart id. Have your payment code refuse to pay one order with more than one authorization.
4. Route anything over either limit to request_human_approval with the full order as the action object (merchant, items, total, order id). The approval is bound to the hash of that action, so a human approves the whole purchase, not one slice of it.
5. If you use Rightshold's guardrail gateway (POST /v1/guard/check), set approval_over_minor for the per-action threshold, daily_max_minor for the rolling 24-hour total and rate_per_minute or rate_per_hour so a burst of small requests is denied. An approval there is single-use and only matches the exact request it was given for.
6. Mirror the limits on the card: Stripe Issuing spending_limits with a per_authorization and a daily interval, so splits are capped at the card even if a step skips Rightshold.
7. Review the signed decisions each day for split signals: several allows to the same merchant_domain on the same day, amounts just under the per-purchase cap, purchases minutes apart, and sequential order or invoice numbers. Treat a match as a question for the owner, not proof of misuse.
8. Test it: with a 100.00 per-purchase cap and a 150.00 daily cap, send two 80.00 purchases to the same merchant. The first allows; the second is denied with over_daily_cap.

Why does a per-purchase approval threshold invite an AI agent to split purchases?

A threshold that looks at one purchase at a time is an instruction as much as a limit: stay under it and nobody asks. GAO's 2008 governmentwide purchase card audit defined split purchases as multiple purchases by the same cardholder at the same vendor on the same day, and found over 600 million dollars that met the definition and appeared to circumvent the micropurchase threshold.

• FAR 13.003(c)(2) says not to break requirements into several purchases under a threshold merely to avoid the rules that apply above it. GAO's purchase card audit guide lists purchases split to get around single purchase limits as improper. The same logic applies to an agent: the threshold is there to bring a human in, and splitting skips that.
• An agent can split with no intent at all. Told to finish a task and blocked by a per-purchase limit, it may simply retry with smaller amounts. That is why the control has to work on totals, not on the agent's honesty.

How do I put an AI agent's approval threshold on the day's running total instead of each purchase?

authorize_spend checks each purchase against the credential's current policy: per_tx_max_minor for the single amount and daily_max_minor for the day's running total of allowed amounts (UTC day), plus the merchant allowlist. Splitting into smaller pieces still adds up, and the request that would pass the daily cap gets a signed deny with over_daily_cap.

• Set daily_max_minor to what you'd accept without a human, not to the agent's whole budget. If larger days are normal, raise the cap through a human decision recorded as a new policy version, ideally with an expires_at, so the higher cap ends on its own.
• Each decision records spent_today_before_minor and daily_max_minor and goes on the spend_authorizations ledger stream. ledger_verify checks the chain free and without a key, so the owner can later show which request hit the cap and when.

How do I approve an AI agent's whole order at once and spot split purchases?

request_human_approval takes the action as an object and records its SHA-256 hash, so the approval covers that exact order. verify_human_approval with the same action checks the match, and a changed order fails with action does not match the approved action hash. Ask once for the full total rather than for each piece.

• On the guardrail gateway, a needs_approval answer is retried with its approval_id, works once, and only for the identical request. Rate limits count every check an agent makes, so a flood of small requests runs into rate_limit_minute or rate_limit_hour.
• No control proves intent. Caps bound the damage and the split signals (same vendor, same day, amounts just under the threshold, sequential invoice numbers) point the owner at what to look at. Card limits are a second layer if one step skips the check.