Runaway Agent Loop Detection

How the attack works

An agent normally completes a task, checks whether it's done, and moves on. In a runaway loop, the agent repeats an identical action, retries a failed step endlessly, or calls itself recursively without ever reaching a stopping condition. The rule looks for textual signs of this in the agent's output and tool calls: retry counters climbing, the same action description repeated, recursive invocation patterns, or indicators that progress has stalled. It does not distinguish an internal software bug from an attacker deliberately triggering the loop with crafted input (chaff data).

Netzilo detection

Why it matters

Runaway loops burn compute and API budget, can degrade or crash multi-agent systems through cascading failures, and may be a sign that an attacker is exploiting excessive agent autonomy to run up costs or disrupt operations.

What you can do

• →Set hard limits on retry counts and maximum iterations per agent task, and enforce them outside the agent itself.
• →Add timeout and cost budgets per task so a stuck agent is killed automatically rather than left running.
• →Review flagged sessions to separate genuine bugs from input that looks designed to trigger repetition.
• →Whitelist known batch-processing, polling, or long-running pipeline agents that normally produce high iteration counts, to cut down on false alerts.

Known benign look-alikes

• Legitimate batch processing with progress counters in output
• Polling agents designed to check status at regular intervals
• Long-running data pipeline agents with expected high iteration counts
• Retry logic in error handling with bounded retry limits
• CI/CD build logs that include 'attempt 2 of 3' progress counters during normal deployment retries
• Monitoring dashboards displaying iteration counts for scheduled polling jobs that legitimately run hundreds of cycles

References

• https://agentthreatrule.org/en/rules/ATR-2026-00050

Related threats