Velocity limits: the one rule that prevents overnight disasters

Of the six rule types in sipi.bot's firewall, one has the highest incident-prevention-to-configuration-complexity ratio: the velocity limit. It is a single number — "max N calls per M minutes" — and it would have stopped every overnight runaway loop in our database.

How velocity limits work

A velocity rule tracks the count of spend-evaluation calls from a given agent over a sliding window. When the count exceeds the ceiling, the next call gets BLOCKED with a reason. The agent reads the reason in the tool result and stops retrying. The loop is dead.

The key insight: velocity limits don't care what the agent is doing. They don't need to understand the task, parse the prompt, or model intent. They're a pure rate-control primitive. And rate is a universal failure signal — a normally paced agent making 100 calls per minute is either misbehaving or compromised.

The incidents it would have caught

• $47,000 overnight token burn: ~30 retries over 8 hours. A limit of 10 calls/minute stops it on call 11.
• $4,200 Pinecone bill in 3 hours: high-velocity vector searches. A limit of 20 calls/minute caps spend.
• $6,500 DN42 AWS scan: autonomous resource provisioning. Each provision = one evaluate call. Velocity caps provisioning rate.
• PocketOS 9-second DB wipe: dozens of destructive commands. A limit of 5 destructive calls/minute triggers on call 6.

How to set one

It's one field in your ruleset. Most teams start at 10 calls/minute for general-purpose agents and 5/minute for trading/finance agents — calibrated from the incident database patterns. Visit the spend-policy generator to get a ready-to-paste velocity rule for your agent type.