Agents tend to retry the same failing action until tokens are exhausted, or they stall with no output when no branch satisfies the success criteria. In both cases, the failure is not just model quality. It is orchestration design. Teams need explicit ceilings, escalation paths, and stop rules so the model cannot keep acting indefinitely on bad state.
What fails when an AI agent can keep acting without a hard stop?
An agent with tool access and no hard exit condition stops behaving like a bounded workflow and starts behaving like an open-ended executor. That changes the failure mode from “the model answered badly” to “the system kept spending time, tokens, permissions, or side effects after it should have stopped.” The key issue is not only control flow. It is whether the orchestration layer can prove that the agent has ended decisively when success, failure, or uncertainty is reached.
This matters because tool-enabled agents do not only generate text. They can query systems, write records, trigger workflows, and chain actions across multiple steps. Without explicit stop rules, a failed branch can loop, a partially successful branch can continue on stale state, and a low-confidence branch can keep seeking a path that never appears. OWASP’s OWASP Agentic AI Top 10 is useful here because it frames agent failures as orchestration and control problems, not just prompt-quality problems. In practice, many teams only discover the missing exit condition after the agent has already retried a bad action several times or left an approval workflow hanging.
At NHI Management Group, we treat this as a governance issue as much as a reliability issue: if the agent can act, it must also be able to stop, hand off, or fail closed.
How do hard stop rules change agent behaviour in production?
Hard stop rules define the boundary between “keep trying” and “stop and escalate.” In practice, they are usually implemented as a combination of ceilings and branches: maximum step count, maximum tool calls, maximum elapsed time, confidence thresholds, and explicit terminal states for success, failure, or human review. The orchestration layer, not the model, should own those boundaries. If the model is allowed to decide unilaterally when to continue, it can overrun the environment even when the underlying task is no longer recoverable.
For tool-using agents, the most useful design pattern is to make state transitions explicit. The agent should know what counts as progress, what counts as a dead end, and what evidence is required before another tool call is justified. That means distinguishing between a recoverable error, such as a transient timeout, and a structural failure, such as a missing permission, incompatible input, or unresolved ambiguity. NIST’s NIST AI Risk Management Framework is relevant because it pushes teams toward measurable governability, not just model performance. The practical test is whether the system can explain why it is still acting, and under what condition it must stop.
- Set a hard ceiling on retries so the same failing action cannot loop indefinitely.
- Separate tool failure from task failure so the agent does not confuse “try again” with “different strategy needed.”
- Require an explicit terminal state for success, fail closed, or human escalation.
- Log the stop reason so operators can distinguish a controlled stop from an accidental stall.
Where this guidance breaks down is in loosely specified tasks that have no reliable completion signal at all, because the agent then has no defensible way to prove that continued action is productive.
Why do open-ended agents create edge cases that look like logic bugs?
Tighter stop conditions often increase operational friction, so organisations have to balance autonomy against recoverability. A strict ceiling can end a useful process early, while a loose ceiling can let an agent drift into repeated failure or silent waiting. That trade-off becomes sharp when the agent sits inside customer workflows, incident response paths, or approval chains where “no output” is itself a failure mode.
The edge cases usually show up in three places. First, the agent may keep retrying a transiently failing tool call even after the surrounding context has changed. Second, it may stall because none of the available branches satisfy its success criteria, yet no terminal failure condition is defined. Third, it may continue to use stale assumptions after the task state has shifted, especially if the tool output is incomplete or contradictory. These are not just model defects. They are orchestration defects caused by missing decision boundaries.
Guidance across the industry is still converging on how much autonomy should be delegated before the system must hand off. For agentic security work, the relevant question is not whether the model is “smart enough.” It is whether the control plane can terminate action cleanly when the environment becomes ambiguous, unsafe, or unrecoverable. MITRE’s MITRE ATLAS adversarial AI threat matrix is useful as a reference point for thinking about how adversarial pressure can exploit weak control boundaries, even when the immediate symptom looks like a reliability issue.
Risk and Threat Considerations
When an AI agent has tool access without hard exit conditions, the main risk is uncontrolled persistence in a bad state. That creates exposure through repeated actions, resource exhaustion, stale decisions, and unbounded tool use. In agentic environments, a simple retry loop can become an attack surface if the agent keeps invoking actions after the task is no longer valid or safe.
Failure mechanism: the system lacks a terminal state, so the agent continues to execute on ambiguous or failing conditions. Adversaries can benefit from that by inducing errors, feeding conflicting signals, or exploiting the agent’s tendency to keep searching for a successful branch instead of stopping and escalating.
Impact: organisations can see wasted token and compute spend, delayed workflows, repeated unsafe actions, bad writes to downstream systems, and harder incident containment because the agent has no enforced stop point.
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, CSA MAESTRO and MITRE ATLAS address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Unbounded Actions | Agent loops and missing exit rules are core agentic control failures. |
| Recommendation — Enforce explicit terminal states and retry ceilings for every tool-enabled agent. | ||
| NIST AI RMF | GOV-3 — Map, Measure, and Manage AI Risks | Hard stop design is an AI governance and risk-management control issue. |
| Recommendation — Define measurable stop conditions and escalate when the agent cannot prove progress. | ||
| CSA MAESTRO | TM-3 — Agentic Workflow Failure Modes | This question concerns orchestration breakdowns in multi-step agent workflows. |
| Recommendation — Model agent workflows with failure states, handoffs, and bounded retry paths. | ||
| MITRE ATLAS | ATLAS-TA0040 — Impact | Persistent bad-state execution can be abused to drive resource and operational impact. |
| Recommendation — Map repeated tool misuse to impact patterns and monitor for adversarial state manipulation. | ||
| CIS Controls v8 | 8 — Audit Log Management | Stop reasons and failed tool chains must be observable to detect runaway behaviour. |
| Recommendation — Log terminal states and repeated failures so uncontrolled agent loops are detectable. | ||
Practitioner Guidance
What to prioritise: define the stop condition before expanding tool access. If the agent can write, call, approve, or trigger, it also needs a terminal path for “stop now,” not just “try another branch.”
What to verify: test the orchestration layer under failure, not only success. A useful check is whether the agent stops cleanly after repeated tool errors, contradictory outputs, or unresolved ambiguity, and whether that stop is logged as intentional rather than accidental.
Decision rule: if the task cannot prove progress after a bounded number of steps, move it to human review or fail closed. Do not let the model negotiate its own continuation when state is already degraded.
What practitioners underestimate: the absence of a hard exit condition is often discovered only after the system has already created operational noise, side effects, or stalled dependencies. The important design question is not “can the agent keep going?” but “can the organisation prove when it must not.”
Practitioner takeaway: bounded autonomy is a control requirement, not a convenience feature, and any agent that can act without being forced to stop will eventually turn a small failure into an uncontrolled workflow problem.
Related resources from NHI Mgmt Group
- What breaks when AI agents share memory and tool access across sessions?
- What breaks when AI agents are allowed to access agreement data without redaction or inspection at the tool layer?
- What breaks when access checks are embedded only in system prompts or tool descriptions for AI agents?
- What breaks when organisations cannot see tool calls and data access from autonomous AI agents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
