Setting spend caps & approval thresholds

If you only set up one kind of guard, make it this one. Spend caps and approval thresholds are the guards that turn “an agent can move money” from a sentence that should scare you into one that’s merely operational. This guide walks through configuring both.

The two guards, and how they differ

• A spend cap is a hard ceiling. Over it, the action is denied. (“No agent spends more than $1,000/day.”)
• An approval threshold is a soft gate. Over it, the action pauses for a human and proceeds only if approved. (“Any single payment over $500 needs sign-off.”)

You’ll usually use both together: a generous hard cap that should never be hit, and a lower approval threshold that catches the consequential actions while letting routine ones flow.

Step 1 — Decide what “spend” includes

“Spend” is broader than dollars. Before setting numbers, list the agent actions that consume something costly or irreversible:

• Direct payments and transfers (payments_pay)
• Provisioning paid resources (new infrastructure, paid API tiers)
• Bulk actions with real cost (sending 50,000 emails, mass record changes)

Each of these can carry a cap. The principle is the same whether the unit is dollars, messages, or rows.

Step 2 — Set caps per role, per window

Caps belong on the role, not the individual agent, so they apply consistently to every agent doing that job. And they’re scoped to a time window so a compromised agent can’t drain the limit in one burst.

role: Billing
  guard payments_pay:
    per_action_max:  1000      # deny any single payment over $1,000
    per_day_max:     5000      # deny once daily total exceeds $5,000
    approved_payees: true      # recipient must be on the allowlist

Start tighter than you think you need. Loosening a cap because work is getting blocked is a five-minute, low-stakes change. Tightening after an overspend is a postmortem.

Step 3 — Add an approval threshold

Below the threshold, the agent just acts. At or above it, the action becomes a pending approval — the side effect doesn’t run until a human says yes.

role: Billing
  guard payments_pay:
    approval_threshold: 500    # ≥ $500 → route to a human
    approvers: ["finance-oncall"]
    expires_after: 4h          # auto-deny if not approved in time

Set the threshold where the cost of a human glance is worth less than the cost of a wrong action. For most teams, routine SaaS invoices fall below it and flow automatically; anything large enough to hurt rises above it and gets a look.

Step 4 — Make approvals fast or they’ll be ignored

This is the step teams skip, and it’s the one that determines whether the whole thing works. An approval that lands in an inbox and waits two days is a bottleneck that trains everyone to disable the guard. Route approvals where people already are and make the decision one tap:

• Slack/Teams with allow / deny buttons inline
• Enough context in the message to decide without leaving it: agent, owner, amount, recipient, and the run that led here
• A timeout that auto-denies, so a forgotten request fails safe rather than hanging forever

A guard that’s annoying gets turned off. A guard that’s a one-tap Slack approval gets to stay on. Speed of approval is a security control, not a UX nicety.

Step 5 — Watch what the guards catch

Every cap hit and every approval is a log line. Review them:

• Frequent approvals just below denial might mean the threshold is too low for normal work — raise it, or you’re training people to rubber-stamp.
• A cap hit you didn’t expect is exactly the signal you built this for. Investigate before you raise it.
• A spike in denied payments to new payees can be the first sign of a prompt-injection attempt.

A sensible starting point

If you want defaults to copy and then tune:

• Per-action cap: the largest payment this role makes in a normal week, rounded up.
• Daily cap: roughly 5× the per-action cap.
• Approval threshold: the amount above which you’d want a human to have looked, even for a trusted teammate.
• Approval timeout: 4 hours during business hours, auto-deny after.

Set those, route approvals into chat, and watch the log for a week. You’ll have a money-moving agent you can actually trust — because the worst case is a denied action and a notification, not a wire you can’t claw back.