Runtime Limits & Circuit Breakers
IntentGate's outbound execution governor. It caps how fast, how far, and how expensively an AI agent can act against your systems. Where the Tool Schema Sanitizer cleans what an agent reads on the way in, Runtime Limits govern what an agent does on the way out. It is a protocol-aware control that sits between the agent and its target systems, APIs, databases, and microservices, and trips a circuit breaker the moment an agent's velocity, cumulative scope, or spend crosses a configured limit.
Why the outbound plane needs its own governor
An agent that has passed authorization can still cause damage simply by acting too much. A single approved action, repeated in a tight loop or escalated across thousands of records, becomes an operational and financial incident. Inbound hygiene and intent authorization decide whether a call is allowed; they do not, on their own, bound how many times that call fires, how much it costs, or how far it reaches. Runtime Limits is the layer that governs outbound velocity, scope, and cost, the execution governor that keeps a legitimate agent from turning into a runaway one.
Threats it addresses
Agent infinite loops
An LLM hits a tool error, doesn't recognise the failure, and retries the same call hundreds of times. Left unchecked, that loop can crash a downstream API or run up cost with every iteration. Velocity breakers cut the wire when call frequency exceeds a threshold, for example, a maximum of N calls per ten-second window per session, so the loop is stopped at the gate instead of at your infrastructure.
Runaway token and API spend (Denial-of-Wallet)
An autonomous agent runs recursive searches or heavy queries indefinitely, calling metered LLM and API endpoints in a way that never crashes anything but never stops billing either. Spend and budget caps enforce hard financial limits per session, user, or tenant. When the ceiling is reached, execution stops, a bug becomes a blocked call rather than an open-ended invoice.
Scope creep and privilege escalation
An agent approved to read a single file starts scraping thousands. The individual calls may each be permitted, but the cumulative behaviour is far outside what was intended. Call-count and scope limits track cumulative execution across the session and halt the agent when its authorized scope is exceeded, so a narrow grant can't quietly widen into a bulk operation.
Mass exfiltration via rapid pagination
An agent pulls data at sustained high frequency, walking page after page to drain a dataset as fast as the target will serve it. Burst and rate limits stop the sustained high-frequency pull, and policy row-ceilings bound how much a single operation is allowed to return. The defence here is rate and volume control, not a separate byte-size inspection engine.
How the outbound check works
Runtime Limits runs on every tool call, in the path between the agent and the target system, as a set of deterministic, local checks with no LLM involved:
- Read the in-memory counters. Per-session counters are held in a native rolling window and a Redis-backed budget store, so the current state of a session is available immediately.
- Evaluate the limits. The call is measured against configured rate limits, spend and budget caps, and call-count/scope ceilings.
- Check the kill-switch status. Any active global, tenant, or agent-scoped stop is honoured before the call proceeds.
- Forward or trip. If everything is within limits, the call is forwarded. If a limit is breached, the breaker trips: the call is blocked, a circuit-breaker event is emitted (optionally onto the event stream), and recovery is triggered.
Because the checks are deterministic and run locally against in-memory state, they add only sub-millisecond deterministic overhead to a call and stop a runaway agent in the same moment it misbehaves, rather than after a slower system notices.
What Runtime Limits actually does
To keep the claims honest: the velocity and rate breakers, the spend and monetary budget caps, and the call-count and scope ceilings are real and shippable. They run on real in-memory counters, a Redis budget store plus a native rolling window. The kill switch is real and can be scoped globally, per tenant, or per agent, and IntentGate's federation lets that decision fan out across nodes. When a breaker trips, recovery and inoculation run through Session Rewind. The enforcement is deterministic and adds only sub-millisecond deterministic overhead; it is not marketed as a guaranteed microsecond or sub-1ms end-to-end number. The circuit-breaker event, the ig.circuit.v1 topic, is emitted onto an optional Kafka event stream that is on the roadmap, not a shipping dependency, so the local breaker works whether or not that stream is wired up. And there is no dedicated byte-size payload inspection engine: mass-exfiltration is bounded by burst/rate limiting and policy row-ceilings, which is what actually ships.
What it's worth
Runtime Limits buys three things. The first is financial predictability: a looping agent can't produce a surprise API or token bill, because the spend cap draws a hard line the agent cannot cross. Picture an agent that gets stuck overnight recursively querying a metered API, without a cap that's an open-ended charge; with one it's a blocked call and an event. The second is infrastructure protection: a rogue or buggy agent can't accidentally deny service to your internal microservices, databases, or third-party APIs, because the velocity and burst breakers cut the connection before the flood lands. The third is control: an instant kill switch lets an administrator trip a global or tenant-scoped stop from the central console and freeze execution across every node, without redeploying agent code.
Defence in depth
Runtime Limits is the outbound execution governor, not the whole story. It bounds velocity, scope, and cost after a call has been authorized; it pairs with the controls that decide whether a call should be made at all. The Tool Schema Sanitizer is its inbound counterpart, it cleans the tool definitions the model reads before any call is proposed. Intent Enforcement refuses calls that fall outside the user's declared intent. Sanitizing what the model reads, authorizing what the agent intends, and governing how much the agent may do are separate, composable layers. See the Capabilities overview for how the controls compose end to end.
Frequently asked questions
What is Denial-of-Wallet in the context of AI agents?
Denial-of-Wallet is a failure mode where an autonomous agent runs up unbounded cost rather than crashing a system. An agent stuck in a retry loop or running recursive searches can call metered APIs, LLM endpoints, or heavy database queries indefinitely, turning a bug into a runaway bill. IntentGate's spend and budget caps enforce hard financial limits per session, user, or tenant, so a looping agent hits a ceiling instead of your invoice.
How does a velocity circuit breaker stop a runaway agent?
On each tool call IntentGate checks in-memory counters, a native rolling window plus a Redis-backed budget store, for that session. If call frequency crosses a configured threshold (for example, more than N calls in ten seconds), the breaker trips: the call is blocked, a circuit-breaker event is emitted, and recovery is triggered. The check is deterministic and runs locally with no LLM in the path, so an agent caught in an infinite loop can't crash a downstream API or burn budget while a slower control catches up.
How does the kill switch work across a distributed deployment?
An administrator can trip a global, tenant-scoped, or agent-scoped stop from the central console. Because IntentGate federates state across nodes, that decision fans out and freezes execution everywhere without redeploying or changing agent code. It is an instant, operator-controlled halt for the whole estate.
See it in the live demo → Try the interactive scenarios on the demo page to watch a runaway agent trip a breaker in real time.