Agent loops happen when an agent gets stuck repeating a similar action, or an escalating sequence of actions, without ever converging on a resolution, and because agents operate at machine speed with real tool access, a loop that would be a minor annoyance in a human workflow can burn through budget, API quota, or rate limits in minutes. Sometimes this is a plain bug: a tool that returns an error the agent misinterprets as a reason to retry indefinitely, or a plan that circles back on itself because the model lost track of what it already tried. Sometimes it's deliberately induced by an attacker who's figured out that a specific input reliably sends the agent into an expensive, repetitive pattern, effectively a denial-of-wallet attack aimed at the business running the agent rather than at its users.
Why agents loop more than conventional software
A conventional program loops because of a bug in explicit logic, usually a missing exit condition someone can find in the code. An agent can loop because its reasoning, at each step, looks locally sensible: "that didn't work, let me try a slightly different approach," repeated indefinitely without ever recognizing the pattern globally. There's no single line of code to point to. The loop is an emergent property of the model's step-by-step decision making, which makes it harder to catch with a code review and easier to miss until it's already run up a bill.
Cost abuse as a deliberate attack
Once an attacker understands that certain inputs, unusually long documents, adversarial phrasing, requests that trigger expensive retrieval or multiple tool calls, reliably increase an agent's resource consumption, they can exploit that pattern deliberately and repeatedly. This kind of attack doesn't need to break anything technically. It just needs to make the agent do expensive work over and over, and it can be launched at a scale and speed no human attacker replicates through a normal UI.
Hard ceilings outside the agent's own judgment
The most reliable defense against both accidental loops and deliberate cost abuse is a hard ceiling enforced outside the agent's own reasoning: maximum steps per task, maximum tool calls per session, maximum spend per user or time window. These limits should trip regardless of how justified the agent's next action seems from inside its own reasoning, because the whole point of a loop is that each individual step looks reasonable in isolation.
Detecting loops before the ceiling is hit
Waiting for a hard ceiling to trip means the damage already happened up to that point. Pattern detection, flagging repeated near-identical tool calls, plans that revisit the same state, or sessions with unusually high tool-call density relative to typical sessions, can catch a developing loop earlier and trigger a pause or an alert before it reaches the ceiling.
Recovery needs a clean exit, not just a stop
When a loop or runaway sequence gets detected, the response needs to be more than just halting the agent mid-action, which can leave a workflow in an inconsistent state. Recovery should include a clean way to roll back or complete any partially executed action, and a clear signal to whoever owns the workflow that something needs manual attention.
A patient attacker can stay under a naive rate limit
A rate limit set too high to avoid interfering with legitimate heavy usage can still leave plenty of room for a patient attacker to run a cost-abuse campaign that never trips the limit at all, simply by spreading requests out or distributing them across multiple accounts or sessions. Effective rate limiting for cost abuse needs to look at aggregate patterns across a longer window and across related identities, not just a per-session ceiling that resets cleanly with every new conversation. An attacker who understands the per-session limit will simply start a new session before hitting it, which makes session-scoped limits alone a fairly weak defense against a deliberate, sustained abuse attempt.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary can apply session-level and time-window rate and spend limits independently of the agent's own reasoning, and its audit trail of tool-call activity is well suited to spotting the repeated or escalating call patterns that indicate a developing loop, whether accidental or deliberately induced. That gives teams both a hard backstop and an earlier detection signal without needing to modify the agent's own code.
Building the recovery logic that cleanly halts and reconciles a stopped workflow remains application-specific work, since it depends on what the agent's incomplete actions actually leave behind.
A short checklist
- Set hard ceilings on steps, tool calls, and spend per session, enforced independently.
- Detect repeated or near-identical tool calls as an early loop signal.
- Flag sessions with unusually high tool-call density compared to typical usage.
- Design a clean halt-and-reconcile path, not just an abrupt stop mid-action.
- Alert a human owner when a loop or cost anomaly gets detected.
- Analyze inputs that reliably trigger expensive agent behavior for abuse patterns.
- Review cost and resource metrics as a security signal, not only a finance one.
Runaway agent behavior rarely announces itself as an attack. It looks like the system working, just working too much, on the wrong thing, for too long. Treating cost and resource anomalies as a legitimate security signal, worth the same monitoring rigor as a failed login attempt, catches problems that a purely functional view of "is the agent still running" will miss entirely.