The problem

Your AI agent is spending more than it should. Maybe the balance is dropping faster than expected, maybe you see a burst of payments, or maybe a report flags an agent whose spend is well above its peers. Whatever surfaced it, the agent is overspending right now, and unlike a latent risk, this is an incident in progress: money is leaving the wallet faster than intended, and every minute it continues costs more.

This is the overspending problem, and it calls for a different response than prevention. When an agent has no controls, the fix is to add them before anything goes wrong; when an agent is actively overspending, the fix is to stop it now, find out why, and put controls in place so it cannot recur. The symptom is real spend you did not intend, and the response has a clear order: stabilize, diagnose, then prevent. Treat it like the incident it is.

Stop it now

Before anything else, stop the spending. You have two immediate options, both enforced server-side and effective at once. The gentler one is to tighten the agent's spend limit in the dashboard to a very low value, so further payments are refused while you investigate. The firmer one is to revoke the agent's API key with apiKeys.revoke, which stops the agent from authenticating and paying at all, a hard freeze.

Choose by the situation. If you suspect the agent is compromised or behaving maliciously, revoke the key, the hardest stop. If it is likely a misconfiguration or a runaway loop and you just need to cap the damage, tightening the limit is enough and less disruptive. Either way, do this first, because diagnosis takes time and you do not want the agent spending throughout it. Stabilizing the incident, halting further spend, is always step one; understanding it comes after the money has stopped moving.

Diagnose the cause

With spending stopped, work out why it happened. Overspending usually traces to one of a few causes. The spend limit may have been set too loose, or not at all, so there was nothing to bound the agent. The agent's logic may have a bug that loops and pays repeatedly. An upstream price may have been higher than expected, so calls cost more than budgeted. Or the agent may have been prompt-injected, steered by adversarial content to spend in ways you did not intend.

Distinguishing these matters, because the fix differs. A too-loose limit is fixed by tightening it; a buggy loop by fixing the code; a price surprise by validating costs; an injection by hardening the agent against untrusted input. The payment trail is your main diagnostic, since it shows exactly what the agent paid, to whom, and how often, which usually narrows the cause quickly. Resist the urge to just raise nothing and re-enable; understand the cause first, so the fix addresses the real problem rather than masking it.

Right-size the policy

The durable fix is a right-sized server-side spend policy. Set the per-transaction cap to the most a single legitimate payment should cost and the period allowance to a realistic total for the agent's expected work, with sensible headroom but not so much that a runaway could spend alarmingly before hitting the cap. The goal is a policy that is unobtrusive in normal operation but firm against the kind of excess you just saw.

This is where the prevention and incident cases meet: the same server-side spend policy that should have been in place is exactly what stops recurrence. Once it is set, the agent's spending is bounded no matter what, so even if the underlying cause recurs, a buggy loop, say, the damage is capped at the policy bounds rather than unbounded. The policy is read-only through the API and set in the dashboard, so it is a control you hold, not one the agent can loosen. Setting it well is covered in how-to-set-up-agent-spending-limits.

Investigate the trail

To both diagnose and confirm the fix, use the payment trail. The agent's payment.sent events record each payment it made, and you can look up a specific transaction with transactions.get. Reading these tells you what the overspending consisted of: a flood of small payments suggests a loop; a few large ones suggests a price or logic problem; payments to an unexpected party suggests injection or misdirection.

Build or check your own ledger of these events to reconstruct the incident, since there is no single list-all endpoint, you assemble the picture from the event stream. That reconstruction does two things: it points at the cause, and it quantifies the damage so you know what actually happened. After you have fixed the cause and re-enabled the agent within a right-sized limit, watch the same trail to confirm spending has returned to normal. The payment trail is both the forensic record of the incident and the early-warning system for the next one.

Prevent recurrence

Once the incident is resolved, close the gap so it does not happen again. Keep the right-sized spend policy in place, fix whatever caused the overspend, and add monitoring so an anomaly is caught early rather than discovered after the fact, a simple alert on spend approaching the period allowance, or on an unusual rate of payments, gives you warning. And apply the lesson across your fleet: if one agent overspent because it lacked a sensible limit, others may too, so audit them.

The broader prevention practice, making a spend policy a default part of creating every agent, is covered in ai-agent-no-spending-controls. The point is that an overspending incident should leave you not just patched but better defended: a bounded agent, a fixed cause, and monitoring that would catch a recurrence sooner. Handled that way, the incident becomes the reason your agents are properly controlled, rather than a loss you simply absorbed.

A worked incident

A short example shows the whole flow. An operator notices a research agent's balance dropping fast. They open the dashboard and lower its spend limit to near zero, which immediately stops further payments, the stabilize step. Then they read the agent's payment.sent events and see dozens of identical small payments to the same data API in a few minutes, which points at a loop rather than a price surprise or an injection.

Investigating the agent's logic, they find a retry that re-paid on a transient error instead of backing off, so each failure triggered another paid call. They fix the retry to not re-pay, right-size the spend policy so a future loop would hit a per-period cap quickly, and add an alert on an unusual rate of payments. Finally they re-enable the agent within the new limit and watch the trail confirm normal spend. The incident is resolved, the cause is fixed, and the agent is now bounded and monitored, which is exactly the better-defended end state the response is meant to reach.

Related reading

If your agent is overspending, stabilize first, then read on. The policy that bounds it is set per how-to-set-up-agent-spending-limits, and the prevention practice is in ai-agent-no-spending-controls. Together they take you from an active overspend to a bounded, monitored agent. Pricing is on the pricing page.