I kept giving agents real API keys and budgets, and the scary part was never a bad answer — it was a retry loop or a prompt injection quietly spending money while I wasn't watching.
So I wrote a small guard you wrap around any spend:
- hard caps per action / day / lifetime (checked against a ledger, so a restart can't reset them)
- an allowlist where empty means nobody
- a kill switch that fails closed
- a blast-radius cap for the "pointed it at the wrong wallet" case
- an append-only ledger you can verify
It got prompt-injected in testing and spent $0.
One file, zero deps, MIT: https://github.com/Mhad2021/agent-spendguard
I also built a free Monte-Carlo "runway simulator" to answer how much capital a self-funding agent needs before it breaks even: https://claude.ai/code/artifact/ebeaa8b2-16eb-400a-8100-5e96c17fd922
How are you all handling runaway spend on autonomous agents? Curious what people do beyond a hard token cap.
Top comments (3)
A ledger-backed cap is the part I would trust here. Prompt-level budgets are too easy to route around once the agent can see tool output or user-provided text. I’d probably split token/API spend from external payments too, since retry loops and real-money actions fail in different ways.
Nice work on the spend guard. The hard caps and kill switch handle the brute-force problem well. But there's a subtler failure mode that budget limits alone don't catch: an agent within its daily cap making hundreds of micro-spends that are individually harmless and collectively expensive. Each call is under the limit, so no guard fires.
The structural fix is to decouple proposal from confirmation. The agent proposes a spend, a separate context authorizes it, and the signing key never passes through the tool scope. The retry loop problem disappears because retrying the same proposal hits the same confirmation gate, not a new spend. Some teams building agent-native payment infrastructure are applying this hosted-action pattern where the agent proposes and a wallet confirms in a secure context, keeping the key outside the tool call.
The spending firewall is the right first feature. Once an agent can touch money, the product boundary is no longer “can it complete the task?” but “can it fail without creating an expensive surprise?”