What Are Velocity Rules and How Do They Stop Runaway Agent Spending?

TL;DR

A velocity rule is "no more than N transactions in W time window." It's a circuit breaker, not a policy decision. When an agent goes off the rails — runaway loop, compromised credential, prompt injection telling it to drain a budget fast — velocity is what stops it before serious damage is done.

What's the rule actually doing?

For every transaction request, count how many transactions this agent has attempted in the last W minutes/hours/days. If the count would exceed the cap, decline.

Concretely:

``json

{

"velocity_per_minute": 5,

"velocity_per_hour": 60,

"velocity_per_day": 500

}

`

Three caps composed: 5/minute, 60/hour, 500/day. Each enforced independently. Hit any one, decline with reason velocity_exceeded.

Why three windows?

Different attack speeds need different windows:

  • Per minute catches runaway loops and rapid prompt-injection attacks.
  • Per hour catches more patient attackers throttling to evade per-minute caps.
  • Per day catches slow-drip attacks that stay under both shorter caps but accumulate.

A single window doesn't cover all timescales. Three composed windows do.

What are typical caps?

Depends entirely on the agent type. Production patterns:

| Agent type | Per minute | Per hour | Per day |

|------------|-----------|----------|---------|

| Travel agent (low velocity) | 2 | 10 | 30 |

| SaaS procurement agent | 3 | 20 | 100 |

| Research agent (paywalled content) | 10 | 200 | 1000 |

| Shopping assistant | 5 | 60 | 300 |

| MCP-call agent | 30 | 500 | 5000 |

Tune for "normal × 1.5-2x". Too tight → choke legitimate bursts. Too loose → don't catch attacks fast enough.

How do velocity rules compare to amount caps?

| | Velocity rule | Amount cap |

|--|---------------|------------|

| Catches | Volume-based attacks | Magnitude attacks |

| Tightening cost | False positives in busy periods | False positives at normal high-value transactions |

| Where it fires | Runaway loops, prompt injection | Single bad transaction |

Both. Compose them. An agent with $500/transaction cap + 5/minute velocity cap is bounded at $2500/minute worst case.

What happens when velocity is exceeded?

Three things, in order:

  • The triggering transaction declines. Reason code velocity_exceeded` with explanation.
  • The agent (and the publisher's webhook handler) is notified. They can:

    • - Back off (correct behavior).

    - Escalate to a human (if the velocity was unexpected — possible compromise).

  • The dashboard logs the velocity hit. Available for review and tuning.

    • The agent isn't paused. Velocity throttles, doesn't kill. If you want a kill switch, use the emergency-stop flag (which freezes all cards under the agent).

    Can velocity rules cause false positives?

    Yes — most commonly during legitimate bursts:

    Mitigation:

    What does this look like in the policy engine?

    Velocity is a O(1) check via Redis-backed counter:

  • Increment counter with TTL = window duration.
  • If counter > cap, decline.
  • Otherwise approve (subject to other rules).

    • Latency cost: ~1-2ms per check. Three windows: ~5ms. Fits comfortably in the 100ms auth budget.

    What about velocity at the policy / publisher / user level?

    Three additional levels worth considering:

    Composing these (per-agent + per-policy + per-user) gives layered defense without choking individual agents.

    FAQ

    What's the smallest meaningful window?

    30 seconds. Below that, ordinary network latency variation makes the cap unstable. Above 30s is workable.

    Can velocity caps be adjusted dynamically?

    Yes — policy edits create new versions; new transactions evaluate against the latest. In-flight transactions use the version they were issued under.

    What if my agent has legitimate burst patterns I can't shape?

    Set the cap at the burst peak + 50% headroom. Use longer-window caps (per hour, per day) to catch sustained issues without choking the bursts.

    Do velocity rules interact with fraud scoring?

    Yes — fraud models use velocity as a signal among others. A velocity-exceeded transaction also factors into the fraud score. The rules are deterministic; fraud is probabilistic; both run.

    Can attackers bypass velocity caps by spreading across multiple agents?

    That's what per-publisher and per-user velocity caps catch. Attackers compromising one agent hit the per-agent cap; trying to spread to multiple agents under the same user hits the per-user cap.

    Related reading

    External references

    ---

    By Vlad K.. Last updated 2026-04-29.