What breaks when multi-agent workflows do not have depth limits and per-agent rate limits?

Why This Matters for Security Teams

Depth limits and per-agent rate limits are not just performance guardrails. In multi-agent systems, they are containment controls that stop a delegated task from turning into an uncontrolled execution graph. Without them, a single prompt, tool failure, or retry loop can trigger recursive delegation, repeated tool calls, and fan-out across multiple agents until budgets, tokens, or timeouts are exhausted. That creates a reliability problem, but it also becomes a security problem when agents can chain actions faster than human reviewers can intervene.

This is why agentic AI guidance increasingly treats bounded execution as a core control, not an optional optimization. The OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modelling framework both point to runaway tool use, uncontrolled delegation, and missing guardrails as recurring failure modes. NHI Management Group has also highlighted the broader governance problem in the Ultimate Guide to NHIs, where excessive privilege and poor lifecycle control amplify impact once an identity or workflow starts behaving badly.

In practice, many security teams encounter the blast radius only after a workflow has already consumed the entire execution budget or flooded downstream services with retries.

How It Works in Practice

The practical failure mode is straightforward: one agent receives a task, calls another agent for help, that second agent calls a third service or retries the first agent, and the system keeps expanding because nothing says “stop after N hops” or “rate-limit this agent independently.” A well-designed workflow treats each agent as a bounded actor with its own depth ceiling, per-agent quota, and runtime policy checks. That means recursion is capped, fan-out is constrained, and repeated tool access is throttled before it becomes an outage.

Good implementations usually combine three controls. First, a maximum depth or hop count limits how far a task can propagate through a chain of agents. Second, a per-agent rate limit prevents one noisy or stuck agent from monopolising tool calls, model invocations, or downstream APIs. Third, runtime policy evaluation decides whether the next step is still acceptable in context, rather than assuming the workflow is safe because it was approved at design time. This aligns with current guidance from NIST AI Risk Management Framework, which emphasises measurement, monitoring, and governance of AI behaviour, and with implementation patterns discussed in OWASP NHI Top 10.

• Set a maximum delegation depth for every workflow, including retries and sub-agents.
• Apply per-agent quotas for model calls, tool calls, and external API actions.
• Separate budgets by agent so one failing branch cannot drain the whole run.
• Log hop count, retry count, and tool frequency as first-class security telemetry.

These controls tend to break down in highly event-driven environments where asynchronous callbacks, hidden retries, or loosely coupled microservices can re-enter the same workflow without preserving the original depth and rate-limit context.

Common Variations and Edge Cases

Tighter depth and rate controls often increase implementation overhead, requiring organisations to balance safety against workflow flexibility. That tradeoff becomes most visible in agent swarms, approval chains, and research-style systems where legitimate tasks may need multiple handoffs before completion.

Best practice is evolving, but a few patterns are already clear. Research agents often need a higher depth ceiling than transactional agents, yet still need hard stops to prevent endless refinement loops. Customer-facing agents may require strict per-agent rate limits because one bursty request can trigger broad downstream impact, while internal orchestration agents may be better controlled with separate budgets for planning, execution, and verification. In some environments, an explicit human checkpoint after a threshold number of hops is more reliable than simply increasing the limit.

Edge cases also appear when agents share tools. If several agents can invoke the same API key, a per-agent limit alone may not stop aggregate overload; the system also needs shared resource throttles. The same applies when one agent delegates to a helper that silently mirrors requests, because the apparent depth can remain low while the actual work multiplies. NHI Management Group’s research on Ultimate Guide to NHIs shows why broad privilege and weak visibility compound these failures, and the OWASP Agentic Applications Top 10 reinforces the need for bounded tool use and explicit control over autonomous execution.

In short, depth limits stop recursion, rate limits stop saturation, and both are needed when agents can chain actions faster than operators can observe them.

Related resources from NHI Mgmt Group

• What breaks when multi-agent MCP workflows share one runtime boundary?
• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?