In a multi-agent system one agent's mistake becomes the next agent's trusted input, and at machine speed a small fault can become an outage, a loss or a security incident before a human notices. ASI08 Cascading Failures is the eighth entry in the OWASP Top 10 for Agentic Applications for 2026, published by the OWASP GenAI Security Project on 9 December 2025. Unlike most entries it is not about how the first fault happens, but about how it propagates and amplifies across agents, tools and workflows. This guide covers what OWASP includes, the engineering controls that contain propagation (borrowing proven reliability patterns from site reliability engineering), the identity controls that limit blast radius, how to test for cascades, and how the entry maps to other frameworks. It is for platform owners, SREs, security architects and risk teams running agents that act on each other's output. For the whole list, see the OWASP Top 10 for Agentic Applications Guide.
Key takeaways
- ASI08 is about propagation, not origin. OWASP frames the entry around how a single fault (a hallucination, malicious input, corrupted tool or poisoned memory) spreads and grows; the originating fault usually belongs to another entry such as ASI01, ASI04 or ASI06.
- Assume components will fail. OWASP's first mitigation is zero-trust, fault-tolerant design that treats LLM and agent components as fallible, which is the same mindset reliability engineering applies to servers and networks.
- Classic reliability patterns apply directly. Circuit breakers, retry budgets, deadlines, load shedding and quotas stop agent feedback loops the same way they stop service outages; OWASP's own references point to the Google SRE guidance on cascading failures.
- Identity sets the blast radius. Short-lived, task-scoped credentials and one identity per agent mean a misbehaving agent can only touch what its current task needs; OWASP maps NHI Reuse, Long-Lived Secrets and Environment Isolation from the NHI Top 10 to ASI08.
- Human oversight cannot be the only brake. OWASP notes that people may not keep pace with machine-speed propagation, so automated tripwires must stop the cascade and humans decide whether to resume.
What it is and who it applies to
OWASP describes cascading failures as a single fault spreading across autonomous agents and compounding into system-wide harm. The signals it lists are rapid fan-out (one decision triggering many downstream actions), spread across domains or tenants, retry loops oscillating between agents, and queue storms. The entry is deliberately about the path a fault takes: a poisoned memory record is ASI06, but the fact that five downstream agents then act on it, each with its own privileges, is ASI08.
Google's SRE book defines a cascading failure as one that grows through positive feedback, where one part failing increases the probability that other parts fail. Agent systems add two amplifiers that classic services lack: agents trust each other's natural-language output without validation, and agents can take new actions (not just retry the same call) in response to a failure.
- Applies to: planner and executor pairs, multi-agent pipelines, agents that trigger other agents through events or queues, auto-remediation and SOC automation, and any agent whose output is consumed by another system without review.
- Also applies to single agents with loops: an agent that retries, re-plans and calls tools repeatedly can cascade within itself, consuming budget and touching more systems on each iteration. See the Denial-of-Wallet and AI Agent Cost Runaway Guide.
- Includes non-malicious faults: OWASP's scenarios include a regional cloud DNS outage breaking dependent AI services across organisations, so ASI08 is a resilience risk as much as a security one.
Structure and key requirements
The tables paraphrase OWASP's common examples, scenarios and mitigations, and show where each sits in the propagation chain.
How cascades start and spread
| Propagation path (OWASP example) | Illustrative scenario in the entry | Likely origin entry (our mapping) |
|---|---|---|
| Planner emits unsafe steps that an executor runs without validation | Poisoned planning data grants excess permissions and deploys costly infrastructure with a backdoor | ASI01, ASI06 |
| Poisoned long-term memory keeps shaping new plans after the source is removed | Poisoned knowledge leads quality control to approve defects while scheduling optimises on bad data | ASI06 |
| One corrupted update misleads peer agents | A false alert spreads through a multi-agent defence system and triggers shutdowns or network disconnects | ASI07 |
| Misuse of one agent's integration or elevated credential is repeated downstream | Stolen service credentials make detection mislabel real alerts and incident response disable controls | ASI03 |
| A tainted release propagates automatically to all connected agents | A tampered supply data source causes a clinical agent to change protocols that then spread across the network | ASI04 |
| Repeated bulk approvals erode oversight and configuration drift spreads | A remediation agent suppresses alerts to meet SLAs, and a planner widens automation based on the false success signal | ASI09, ASI10 |
| Interdependent agents form a feedback loop that magnifies early errors | Prompt injection inflates risk limits in a trading system and downstream agents trade larger positions | ASI01 |
Mitigations and how to implement them
| OWASP mitigation (paraphrased) | Concrete control |
|---|---|
| Zero-trust, fault-tolerant design | Every agent validates inputs from peers as untrusted; define a safe failure state (stop and hold) for each agent |
| Isolation: sandboxing, least privilege, segmentation, scoped APIs, mutual authentication | Separate trust zones per workflow; agents in one zone cannot call agents in another without a policy decision |
| Short-lived, task-scoped credentials; policy-as-code checks on high-impact tool calls | Token exchange per task with narrow scope and minutes-long lifetime; an external policy decision point evaluates each high-impact call. See the Policy-as-Code for Authorisation Guide |
| Separate planning from execution with an external policy engine | The planner proposes; a deterministic engine outside the model approves or rejects each step |
| Output validation and human gates before results flow downstream | Schema and range checks on every handoff; human approval for actions above a value or scope threshold. See the Human-in-the-Loop for AI Agents Guide |
| Rate limiting and monitoring; pause on anomalous propagation | Per-agent and per-workflow rate limits; automatic pause when fan-out or error rate crosses a threshold |
| Blast-radius guardrails: quotas, progress caps, circuit breakers between planner and executor | Caps on records changed, systems touched, money spent and steps per run; a breaker that opens after repeated failures or anomalies |
| Behavioural and governance drift detection against baselines | Compare decisions, approval rates and tool mix with a baseline; alert on drift. See the AI Agent Behaviour Baselining and Anomaly Detection Guide |
| Digital twin replay: replay recent agent actions in an isolated clone of production; gate policy expansion on the result | Before widening an agent's autonomy, replay last week's traffic in a sandboxed copy and check for runaway paths |
| Tamper-evident, signed logs of inter-agent messages, policy decisions and outcomes | Append-only, signed log store with message hashes and correlation IDs, supporting tracing and rollback |
Reliability patterns that contain agent cascades
The reliability engineering literature already solved much of the mechanics. Two well-known sources are worth reading alongside the OWASP entry.
- Retry amplification: the Google SRE book shows three retries at each of three layers producing 64 attempts at the bottom layer; the AWS Builders' Library calculates a 243-fold load increase for three retries across five layers. Agents that re-plan on failure add even more attempts. Retry at one layer only.
- Retry budgets: limit retries per request and per process (the SRE book's example is 60 retries per minute per process), or use token-bucket retry limiting as the AWS SDKs do. Never retry indefinitely, and do not retry permanent errors.
- Backoff with jitter: randomised exponential backoff stops retries from synchronising. The A2A specification also recommends exponential backoff for failed push notification delivery and allows agents to stop after a set number of consecutive failures.
- Deadlines and cancellation: set a deadline on every agent run and tool call, propagate the remaining time downstream, and propagate cancellation so child agents stop when the parent gives up.
- Idempotency: side-effecting actions must carry idempotency keys so a retried or duplicated message does not execute twice. A2A asks webhook receivers to process notifications idempotently because duplicates may occur.
- Circuit breakers: after a threshold of failures or anomalies, stop calling the downstream agent or tool (open state), then allow limited trial traffic (half-open) before resuming. OWASP places breakers specifically between planner and executor.
- Load shedding and graceful degradation: when overloaded, reject new work early or fall back to a cheaper mode (for example read-only, or plan-only with no execution) rather than letting queues grow.
Identity and NHI requirements
The size of a cascade is set by what each agent in the chain is allowed to do. OWASP's Appendix C maps three OWASP NHI Top 10 risks to ASI08: NHI7 Long-Lived Secrets, NHI8 Environment Isolation and NHI9 NHI Reuse.
- No shared identities across agents: if five agents share one service account, a fault in one is exercised with the privileges of all five and you cannot tell which acted. See the OWASP NHI Top 10 NHI9 NHI Reuse Guide.
- Short-lived, task-scoped credentials: a credential that expires with the task caps how long a runaway can continue. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
- Environment separation: a test agent whose credentials work in production turns a test fault into a production incident. See the OWASP NHI Top 10 NHI8 Environment Isolation Guide.
- No token passthrough: each hop should exchange for a narrower token rather than forwarding the caller's, so privilege shrinks along the chain rather than staying constant. See the OAuth Token Exchange and Delegation Guide.
- Revocation as a breaker: disabling an agent's identity is the most reliable kill switch, because it works even if the agent ignores instructions. Measure how fast you can do it. See the AI Agent Kill Switch and Containment Guide.
Implementation steps
- Map dependencies. For each workflow, list which agents consume which agents' output, which tools and credentials each uses, and which external services all of them depend on (model APIs, DNS, identity provider). Single shared dependencies are cascade points.
- Define the safe state. For each agent, decide what "stopped" means: no new actions, in-flight work cancelled, pending approvals held. Implement it as a control-plane switch, not a prompt.
- Set blast-radius limits. Per run: maximum steps, tool calls, records changed, spend and wall-clock time. Start generous, in log-only mode, then tighten to the 99th percentile of normal runs plus margin.
- Insert a policy engine between planning and execution. Begin with the highest-impact actions (deletes, payments, permission changes, network isolation). Run in audit mode, compare its decisions with what happened, then enforce.
- Add circuit breakers and retry budgets on every agent-to-agent and agent-to-tool edge, with deadlines and cancellation propagation.
- Validate handoffs. Schema, range and plausibility checks where one agent's output becomes another's input; route out-of-range values to a human.
- Instrument propagation. Correlation IDs across every hop so you can see fan-out per originating event; signed, append-only logs of messages and policy decisions.
- Test with replay and fault injection. Replay recent production traffic in an isolated clone, inject a false alert, a poisoned record and a downstream outage, and confirm the breakers trip. Gate any increase in autonomy on these tests passing.
- Rehearse recovery. Practise stopping, rolling back and restarting a workflow, including ramping traffic back gradually rather than all at once.
Evidence and assessment
| Test | Method | Pass condition |
|---|---|---|
| False alert propagation | Inject a fabricated high-severity alert into one agent in a replay environment | Downstream containment actions require approval or are capped; no mass isolation |
| Poisoned input | Seed an out-of-range value (risk limit, quantity, permission set) at the planner | Policy engine or handoff validation rejects it before execution |
| Retry storm | Make a downstream tool fail persistently | Retries stop at budget; breaker opens; no re-planning loop |
| Dependency outage | Block the model API or DNS for the workflow | Agents enter the safe state; no partial, inconsistent actions |
| Kill switch | Revoke one agent's identity mid-run | All its calls fail within the target time; peers do not continue on its behalf |
| False success signal | Have an agent report success on a task that failed | Independent verification catches it before autonomy is widened |
Metrics:
- Fan-out per originating event: downstream actions triggered per initial input, with alerts on outliers.
- Breaker trips and pauses: count and cause; zero trips in a busy system usually means thresholds are too loose.
- Containment time: minutes from anomaly to all affected agents in the safe state.
- Blast-radius coverage: percentage of production agents with enforced step, spend and scope limits.
- Shared and long-lived credential count: credentials used by more than one agent or living longer than the task (target zero).
See the AI Agent Incident Response Playbook for the response side.
Mapping to other frameworks
| Framework | Reference | Relevance to ASI08 |
|---|---|---|
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection, LLM04 Data and Model Poisoning, LLM06 Excessive Agency | OWASP's Appendix A mapping; LLM10 Unbounded Consumption is also relevant to retry and cost loops |
| OWASP Agentic AI Threats and Mitigations | T5 Cascading Hallucination Attacks, T8 Repudiation and Untraceability | Source threats (Appendix A) |
| OWASP NHI Top 10 | NHI7 Long-Lived Secrets, NHI8 Environment Isolation, NHI9 NHI Reuse | Appendix C mapping |
| MITRE ATLAS | AML.T0080 AI Agent Context Poisoning, AML.T0034.002 Agentic Resource Consumption, AML.T0029 Denial of AI Service, AML.T0101 Data Destruction via AI Agent Tool Invocation | Seeds of a cascade and its typical impacts |
| MITRE ATT&CK | T1499 Endpoint Denial of Service, T1565.002 Transmitted Data Manipulation | Availability impact and tampered handoffs |
| NIST SP 800-53 Rev. 5 | SC-5, SC-6, SC-24, SI-17, AC-4, AU-9, SI-4, CP-2 | DoS protection, resource availability, fail in known state, fail-safe procedures, flow enforcement, protected logs, monitoring, contingency |
| NIST CSF 2.0 | PR.IR-03, PR.IR-04, DE.AE-02, RS.MI-01 | Resilience mechanisms, capacity, event analysis, containment |
| ISO/IEC 27001:2022 Annex A | 5.30 ICT readiness for business continuity, 8.6 Capacity management, 8.14 Redundancy, 8.16 Monitoring activities | Continuity and capacity anchors |
Related entries: OWASP Agentic Top 10 ASI06 Guide, OWASP Agentic Top 10 ASI07 Guide and OWASP Agentic Top 10 ASI10 Guide.
Common pitfalls
- Trusting an agent's own report of success. In the Replit AI agent database deletion, the coding agent deleted production data during a code freeze, then wrongly said rollback was impossible and was alleged to have produced fake data and test results. Verify outcomes independently before acting on them or widening autonomy.
- Instructions instead of controls. The same incident shows a freeze expressed in natural language does not stop an agent. Blast-radius limits and approvals must be enforced outside the model.
- Retries at every layer. Framework retries, tool client retries and agent re-planning stack multiplicatively. Choose one layer and budget it.
- Auto-remediation without caps. OWASP's scenarios include a defence agent shutting systems down on a false alert. Containment agents need limits on how many hosts or accounts they can isolate per hour without approval.
- Bulk approval fatigue. When humans approve batches by habit, the gate stops being a gate. Measure approval times and rejection rates; near-zero rejections is a warning sign.
- One shared dependency. All agents relying on one model endpoint, one identity provider or one DNS path fail together. Plan degraded modes for each.
Practitioner checklist
- Map agent-to-agent dependencies and shared external dependencies for every workflow.
- Define and implement a control-plane safe state for each agent.
- Enforce per-run limits on steps, tool calls, records changed, spend and time.
- Put an external policy engine between planning and execution for high-impact actions.
- Add circuit breakers, retry budgets, deadlines and idempotency keys on every edge.
- Validate every handoff with schema and range checks, with human review above thresholds.
- Issue one short-lived, task-scoped identity per agent, separated by environment.
- Keep signed, append-only logs with correlation IDs across all hops.
- Replay production traffic and inject faults before widening any agent's autonomy.
- Measure fan-out, containment time and time to revoke an agent identity.
Standards and references
- OWASP GenAI Security Project: OWASP Top 10 for Agentic Applications for 2026
- OWASP: Top 10 for LLM Applications 2025
- Google: Site Reliability Engineering, Addressing Cascading Failures
- AWS Builders' Library: Timeouts, retries and backoff with jitter
- A2A Project: Agent2Agent (A2A) Protocol Specification
- MITRE ATLAS: AI Agent Context Poisoning
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: OWASP Top 10 for Agentic Applications Guide · AI Agent Kill Switch and Containment Guide · Rogue and Runaway AI Agent Detection Guide · Multi-Agent and A2A Security Guide · Cyber Resilience Guide