If you implement one safety feature for agent payments, make it hard spending limits. Not alerts, not dashboards: limits enforced before authorization, so a confused agent gets a decline instead of causing a loss. This is the layered pattern production teams converge on, and how to calibrate it once it is live.
Four layers, four failure modes
One limit is never enough, because agents fail in four distinct ways and each layer catches a different one. A per-transaction cap stops the single oversized charge (the quantity-1,000 order). A per-session budget stops many small charges from compounding during one autonomous run. A daily or weekly cap per agent stops slow drift in long-running workflows. And a velocity cap on transaction attempts stops the classic incident: the retry loop that hammers an ambiguous checkout until something gives.
Together they convert expensive incidents into contained events. A policy for a mid-risk workflow looks something like this:
{
"policy": "travel-booking-agent",
"perTransactionMax": 500,
"perSessionMax": 1500,
"dailyMax": 2500,
"velocity": { "maxAttempts": 6, "window": "1h" },
"merchants": { "allow": ["airlines", "hotels"] },
"approvalAbove": 200
}Set budgets from risk, not confidence
Size each workflow's caps from business risk, not from how much you trust the model. A SaaS renewal agent gets a higher cap with a strict merchant lock, because the merchant set is known and stable. A travel agent gets a medium cap with approval required above a threshold, because amounts vary legitimately. An experimentation agent gets a very low cap and tight velocity, because its whole job is doing unexpected things.
Then enforce the limits in two places at once: in your policy engine, and as hard constraints at the authorization layer itself. App-layer policy alone drifts as implementations change; authorization-level constraints fail safe even when your code does not.
Approvals and the intent record
Approval thresholds preserve speed without giving up control: spend below the line auto-approves, and anything above it pauses for a human. Set the first threshold lower than feels necessary; raising it after two quiet weeks costs nothing, while lowering it after an incident costs the incident.
Every limited spend path should also log intent: the expected amount, the approved ceiling, the actual charge, and the policy decision that let it through. This record is not bureaucracy. It is the only way to tune limits safely, because without it a decline tells you nothing about whether the policy was right or the agent was wrong.
Make the limits rail-aware
A limit that exists only on your card program covers only your card spend. Agents also move money over bank transfers, where a wire is final the moment it sends, and burn budget through metered APIs, where a token bill never touches an authorization flow at all. The same layered caps need to govern every rail, with the enforcement point matched to the rail: before the transfer on irreversible rails, at authorization on cards, and at the metering layer for API spend.
This is where Signets sits: one policy layer over a Signet, enforced before money moves on every rail the agent transacts on, with scoped credentials issued per purchase so the card-side caps cannot drift.
The mistakes that cause incidents
Four patterns account for most overspend postmortems. Static limits that never change as behavior improves or degrades. Missing velocity caps, because most incidents are many rapid attempts rather than one large charge. Amount caps without merchant scope, which contain how much goes wrong but not where. And no freeze path: if a limit trips repeatedly and you cannot halt the workflow in seconds, the control system has a hole where its brake should be.
The calibration loop
Limits are a control system, not a checkbox, so close the loop. Review weekly: the approval-to-decline ratio per policy tier, false declines (legitimate purchases the limits blocked), anomaly rate, and average spend per completed task. Tighten where anomalies cluster, loosen where false declines tax throughput, and change one variable at a time so you can attribute the effect.
Start strict. Expand deliberately. And if you would rather inherit this control system than build it, tell us what you are building and we will get you sandbox access.
FAQ
What spending limits should AI agents have?
Layer four limits together: a per-transaction cap, a per-session budget, a daily or weekly cap per agent, and a velocity cap on transaction attempts, plus merchant restrictions and an approval threshold. Each layer catches a different failure mode, from oversized charges to retry loops.
Are alerts enough to control AI agent spending?
No. Alerts report a loss after it happens. Autonomous agents need hard limits enforced before authorization, so out-of-policy purchases are declined in real time rather than flagged in the morning.
Where should agent spending limits be enforced?
In two places: a policy engine for expressiveness, and hard constraints at the authorization or transfer layer so the limit holds even if application code drifts. On irreversible rails like wires, enforcement must happen before the transfer; on cards, at authorization; for metered API spend, at the metering layer.
How do I set the right limit amounts?
Start from business risk per workflow, not model confidence: begin strict, log intent on every spend path, then calibrate weekly using the approval-to-decline ratio, false declines, and anomaly rate. Raise caps after sustained clean behavior rather than setting them high up front.
