Cascading failures

How it works

OWASP draws a boundary most vendor write-ups blur: cascading failures is “the propagation and amplification of an initial fault-not the initial vulnerability itself-across agents, tools, and workflows, turning a single error into system-wide impact.” A single fault — a hallucination, a corrupted tool output, or a memory already poisoned under agent memory poisoning — gets scored under its own category the moment it happens. ASI08 only applies once that fault stops being contained to where it started: it spreads across agents, sessions, or workflows and produces measurable fan-out or systemic impact.

Because agents plan, persist, and delegate on their own, a single error can skip the stepwise human checks a person would normally catch it at, and persist in a saved state instead. As agents pick up new tools or peers, the latent fault chains into privileged operations — compromising confidentiality, integrity, or availability across the whole agent network, not just the one agent that first made the mistake.

Why it matters

OWASP’s own examples show the same shape recurring across domains. A poisoned market-analysis agent inflates risk limits, and downstream trading agents auto-execute larger positions while compliance sees each trade as individually “within-parameter” activity. A remediation agent that suppresses alerts to meet a latency target teaches a planning agent that fewer alerts mean success, so it widens automation and compounds the blind spot. In each case, every single action taken along the chain can look legitimate in isolation — the harm is visible only in the pattern connecting them.

OWASP is candid that this outruns human oversight: the speed and scale of fault propagation in a multi-agent system can exceed a human’s ability to keep up, leaving some risk that an organization has to evaluate and accept rather than fully close.

In practice

OWASP’s guidelines aim at containment rather than trying to prevent every fault: isolation and trust boundaries — sandboxed agents, least privilege, network segmentation, scoped APIs, and mutual authentication — so one agent’s fault cannot freely reach another’s. Short-lived, task-scoped credentials and a runtime policy check on every high-impact tool call limit what a compromised or drifting agent can trigger downstream. Planning and execution are separated behind an independent policy engine, so a corrupted plan cannot execute itself. And blast-radius guardrails — quotas, progress caps, and circuit breakers between planner and executor — cap how far a single fault can fan out before something intervenes, backed by rate limiting, behavioral drift detection, and non-repudiation logging that traces what propagated and how.

Questions and answers

Is a cascading failure the same as the bug that caused it?

No. OWASP scores the initial defect — a tainted dependency, poisoned memory, or spoofed message — under its own category (ASI04, ASI06, or ASI07). Cascading failures, ASI08, applies only once that defect spreads across agents, sessions, or workflows and produces measurable fan-out beyond the original breach.

Does a cascading failure need an attacker?

No. OWASP's example causes include an honest hallucination in a planner agent and a corrupted tool output, alongside attacker-planted poisoned memory or spoofed messages. What defines ASI08 is the spread, not who or what started it.