Guides — Agent Spend Firewall How-To
Step-by-step guides for setting up agent spending controls, preventing runaway costs, and designing spend policies.
Step-by-step guide: deploy sipi.bot, connect your agent, set your first spending rules, and go live with APPROVED/BLOCKE…
Why agents overspend, how to detect a runaway loop, and the three firewall rules that stop it before the bill arrives.…
How to design spending policies that balance agent autonomy with cost control — category budgets, team-based limits, and…
How to manage spending across dozens of autonomous agents with per-agent policies, shared budgets, and centralized audit…
Putting this guide into practice
"Guides — Agent Spend Firewall How-To" covers the theory and architecture. The real challenge is translating that into working policy rules that actually run in production. Below are concrete examples that map the guide's concepts to sipi.bot policy configurations.
Common real-world scenarios
Teams implementing the patterns in this guide typically encounter three recurring situations. Here is how each one translates into actionable policy:
Scenario 1: The research agent that reads too deeply
A research agent hits 47 LLM API calls exploring a single topic. Each call is under $0.50 (within the per-transaction limit), but the cumulative cost hits $23 in 90 seconds. The fix is a velocity cap of 10 calls/minute per agent, which catches the rapid-fire pattern before the daily ceiling ever fires. Configure this in sipi.bot: set "max 10 evaluations/minute" on the agent's policy group. When the agent hits the limit, it receives a BLOCKED decision and must pace itself.
Scenario 2: The deployment that bypassed the staging check
A developer deploys a new agent version directly to production, skipping the staging environment. The new agent has a bug in its retry logic that generates 200 identical transactions. Without a daily ceiling ($50/agent) and a velocity cap, this becomes a $2,000 incident. With both, the agent is blocked at transaction 11 (velocity cap) or at the first transaction that pushes daily spend over $50. The audit log shows the new agent ID immediately, pinpoints the deployment, and the developer is alerted within seconds.
Scenario 3: The prompt injection that redirects a payment
An adversarial input tricks a customer-support agent into sending a payment to an attacker-controlled merchant. Without a merchant allowlist, the agent sends $500 to "merchant-service-pay.com" before anyone notices. With a merchant allowlist restricted to 8 approved vendors, the agent receives BLOCKED with reason "merchant not on allowlist." The transaction never executes. This scenario alone justifies the merchant allowlist as the highest-priority control in any deployment.
Next steps after reading this guide
Deploy the concepts in this guide with sipi.bot: set up your policy in the dashboard, wrap your agent's spend functions with the evaluation endpoint, and run the three test scenarios above. Each scenario takes under 10 minutes to configure and validates a different dimension of your spend control. At $99/month, the insurance is cheaper than a single uncontrolled incident.