Use a kill switch in the agent framework that watches token count, tool-call count, retry count, and span depth. When one of those ceilings is crossed, stop the run before it completes the next loop. That containment belongs in the execution path, because post-hoc review arrives too late to prevent the cost.
Why This Matters for Security Teams
A misbehaving agent run is not just a reliability issue. It is an operational cost control problem, a governance problem, and, in some environments, a security problem if the run has access to tools, data, or downstream actions. Once an agent starts looping, retrying, or expanding its task scope, spend can rise faster than most teams expect. The right containment pattern is to stop the execution path, not to rely on logs or billing review after the fact.
This is why current guidance on agentic AI risk emphasises runtime controls, bounded autonomy, and clear accountability. The OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both support the idea that agent behaviour should be monitored and constrained during operation, not only audited later. For teams running workflows with external tool access, the same pattern also helps reduce accidental data exposure and uncontrolled side effects.
Many teams get caught by the same failure mode: the agent is judged successful only after the budget spike has already happened, because no runtime ceiling was enforced when the loop started to drift.
How It Works in Practice
The most effective stop mechanism is a layered budget guard inside the agent executor. That guard should inspect multiple runtime signals together, because no single metric captures runaway behaviour on its own. Token count limits the size of the model interaction. Tool-call count limits repeated API usage. Retry count catches failing chains that keep reissuing the same request. Span depth or step depth limits recursive planning loops and long agent chains.
In practice, the guard should sit in the same execution path that schedules the next model call or tool invocation. That means the agent framework checks the ceiling before the next loop is allowed to begin. If the ceiling has been crossed, the framework should terminate the run, emit a structured event, and preserve enough context for investigation. A strong implementation also distinguishes between hard stops and soft warnings, so teams can alert on near-limit behaviour before they hit the kill switch.
- Set per-run ceilings for tokens, tool calls, retries, and depth.
- Apply smaller limits to high-risk tools such as file writes, outbound messages, or payment actions.
- Log the reason for termination so operations teams can distinguish abuse from benign failure.
- Route repeated violations into review, because recurring loops often indicate a prompt, policy, or tool design problem.
For threat-informed design, the MITRE ATLAS adversarial AI threat matrix is useful because it helps teams think about how agent behaviour can be manipulated into expensive or unsafe patterns. For broader governance, the CSA MAESTRO agentic AI threat modeling framework can help structure controls around execution, tooling, and escalation paths. These controls tend to break down when the agent is allowed to spawn nested sub-agents without inherited limits, because the parent run no longer has a reliable view of total spend or recursive depth.
Common Variations and Edge Cases
Tighter kill switches often increase operational overhead, requiring organisations to balance cost containment against workflow continuity. That tradeoff is real in customer support, software engineering, and research agents where a legitimate task may need more steps than expected.
There is no universal standard for the right ceiling values yet. Best practice is evolving toward policy-by-risk rather than one global limit. High-trust internal agents may get higher ceilings, while external-facing or internet-connected agents should usually run under stricter thresholds. Some teams also use time-based caps, dollar-based caps, or tool-specific budgets, especially when a single model call can trigger several expensive downstream actions.
Edge cases matter. A long but valid workflow can look similar to a runaway loop if the task is underspecified. A budget guard should therefore be paired with quality checks, human escalation paths, and a clear retry policy so that normal failure does not always look like abuse. Where agent behaviour affects regulated decisions or high-impact actions, the control should align with governance expectations from the NIST AI Risk Management Framework and, where applicable, the Anthropic report on AI-orchestrated cyber espionage, which shows why runtime containment matters when agent autonomy is being abused or redirected.
In practice, the hardest cases are not obvious failures but ambiguous ones: a run that is still making progress while silently crossing the point where cost, risk, or trust is no longer acceptable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Runaway agent loops map to agentic abuse and weak runtime guardrails. |
| NIST AI RMF | GOVERN | Budget kill switches are governance controls for bounded AI operation. |
| MITRE ATLAS | ATLAS helps model adversarial patterns that drive costly agent behaviour. | |
| CSA MAESTRO | MAESTRO addresses agent execution and control boundaries. | |
| NIST AI 600-1 | GenAI profile supports operational controls for model use and monitoring. |
Map limits to execution, tool access, and escalation so runaway runs can be stopped deterministically.
