AML.T0029
Denial of AI Service
view on ATLAS ↗
Adversary exhausts compute, memory, or rate-limit budgets so the AI system stops responding or stops processing legitimate requests.
← Atlas · Threats
High
T25 · Helmwart ID · OWASP MAS Guide source
Workflow Disruption via Dependency Exploitation
An attacker disrupts an agent's workflow by overwhelming a system it depends on rather than the agent itself, denying service to legitimate work through the weakest link in the chain.
Extends T4: Resource Overload · base threat in OWASP v1.1 catalog
Definition
The RPA agent is part of a larger Agent-to-Agent (A2A) workflow involving an approval agent, a payment processing system, and an external bank API. An attacker disrupts the workflow by targeting a dependent system rather than the RPA agent directly. The RPA agent continues to function correctly, but the pipeline it depends on is unavailable or degraded, causing denial of service for legitimate claims. This is distinct from T2 Tool Misuse, which requires direct interaction with the primary agent.
What it looks like in practice
An attacker floods the approval agent (a downstream service in the A2A pipeline) with a high volume of fabricated approval requests. The approval agent becomes overwhelmed and begins queuing or dropping requests. The RPA agent submits legitimate claims and waits for approval responses that never arrive within the configured timeout. Claims expire and must be resubmitted manually, degrading throughput and creating an operational backlog.
The attack need not target the most hardened component; it targets the weakest link in the dependency chain. A shared approval microservice that is less hardened than the primary RPA agent becomes the effective attack surface for the entire workflow.
Why it’s dangerous in multi-agent context
Multi-agent workflows create dependency chains. Each agent in the chain is a single point of failure for every agent upstream of it. Because the RPA agent trusts its downstream dependencies to be available and responsive, no individual agent detects that the system-wide denial of service is adversarial rather than a transient outage. Without circuit-breaker patterns and independent retry budgets, the cascading failure propagates silently: claims accumulate in the RPA agent’s queue while the approval backlog grows.
Detection signals
The attack presents as a dependency availability problem; detection requires distinguishing adversarial flood from organic load increase by examining the source and shape of requests hitting the approval agent.
- A spike in the approval agent’s inbound request rate that is not correlated with a corresponding rise in RPA-agent claim submission events. If requests arriving at the approval agent exceed the volume the RPA agent could plausibly have generated, the excess is from a fabricated source.
- Approval agent queue depth crossing a defined ceiling (e.g. > 500 pending requests) while the approval agent’s CPU and memory utilisation remain low. This is indicative of a connection-exhaustion or head-of-line-blocking attack rather than genuine processing load.
- A sustained rise in timeout events logged by the RPA agent for approval responses, without any corresponding error events from the approval agent itself. The approval agent may be healthy but overwhelmed at the queue layer; alert when RPA-side timeout rate exceeds 5 % of submissions over a 5-minute window.
- A high proportion of fabricated approval requests sharing identical or templated payload structures (e.g. all using the same
submitter_id, all with identical claim amounts). Inspect inbound request diversity at the approval agent and alert on low payload entropy. - The circuit-breaker counter incrementing at a rate that exceeds its historical maximum (baseline from normal operations). A sudden burst of consecutive timeouts that opens the breaker faster than any known peak-load event is a strong indicator of adversarial flooding.
Mitigations
- Map the full dependency graph of the A2A workflow; assign a maximum acceptable latency and an availability SLA to each dependency.
- Implement circuit-breaker patterns: after a defined number of consecutive timeouts from a downstream agent, the RPA agent stops forwarding new requests and enters a degraded mode rather than accumulating queue depth.
- Rate-limit inbound requests to the approval agent to prevent flood-based exhaustion; enforce admission control before the request reaches the processing queue.
- Design fallback paths: claims that cannot be approved within the SLA window should route to a human reviewer queue rather than silently expiring.
Relation to base threat (T1–T17)
T25 extends T4 Resource Overload. Where T4 targets the primary agent’s own resources, T25 targets a dependent agent or system, achieving denial of service indirectly. T32 (Runaway Agent on Solana) and T39 (Unintended Resource Consumption via MCP) are the self-inflicted resource exhaustion variants: the agent itself is the source of the overload rather than an external attacker.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T25 is covered by the following Top 10 entries:
-
ASI08 Cascading Failures primary A single low-severity fault (a hallucinated value, a corrupted tool output, a poisoned memory entry) propagates across a network of agents that each build on the last agent's output, compounding into system-wide harm that is disproportionate to the original defect. ASI08 is about propagation and amplification, not the fault's origin; the initial trigger may itself be innocuous.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T25 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-Depth The attack exploits the dependency chain rather than the primary agent: the RPA agent continues to function correctly while a less-hardened downstream approval service becomes the effective attack surface for the whole workflow. Depth means no single dependency's availability is an unchecked assumption: the full dependency graph is mapped with explicit latency and availability SLAs, circuit-breaker patterns stop the RPA agent from accumulating queue depth when a downstream agent stops responding within the SLA, and claims that cannot be approved within the window route to a human reviewer queue rather than silently expiring. Rate-limiting on the approval agent's inbound queue is an independent layer that caps the flood before it reaches the processing queue, regardless of the RPA agent's behaviour.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T25, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
-
Tier 1 Agent SBOM (Signed AIBOM: a cryptographically-bound inventory of every component an agent loads)
An AI agent assembles itself at runtime from a model, prompt templates, plugins, and library dependencies, any of which can be tampered with before they arrive. A signed AI Bill of Materials (AIBOM) locks down that assembly: it records every component with a version and hash at build time, signs the manifest, and verifies it before the agent accepts traffic. A component that does not match its declared hash cannot silently enter the agent.
why it helps Workflow Disruption via Dependency Exploitation attacks the weakest system the agent depends on rather than the agent. An inventory of what it actually depends on, including the services behind its tools, is what makes that list reviewable, so a fragile upstream component is identified before an incident rather than during one. The dependency remains a single point of failure until something else removes it.
-
An agent that is uncertain about what to do next faces a choice: refuse and ask for clarification, or proceed on its best guess. In low-stakes situations that tradeoff is tolerable. In agentic systems that write, delete, or send, a confident-sounding but wrong output can commit an irreversible action. A fail-closed gate resolves that choice structurally: below a configured confidence threshold, the agent stops and escalates rather than guessing.
why it helps Workflow Disruption via Dependency Exploitation often turns a slow or degraded dependency into wrong output, because the agent proceeds on whatever it managed to retrieve. A fail-closed gate makes the degraded case a refusal with a stated reason, so the disruption stays a disruption instead of becoming a bad action taken on partial data. Availability is still lost.
-
Tier 2 Graceful degradation (Graceful degradation — fail closed where it matters, fail open where it's safe)
An agent that encounters a quota trip, a dependency failure, or a timeout faces a choice: continue at reduced quality, or refuse. Getting that choice wrong is the core operational failure. Graceful degradation requires the answer to be declared before the incident, not improvised during it: write-authority paths fail closed and return a refusal; read-only paths fail open and disclose the degraded state explicitly.
why it helps Workflow Disruption via Dependency Exploitation occurs when an attacker degrades or disables a dependency that a pipeline agent relies on, causing upstream agents to block, retry indefinitely, or propagate corrupt state. A pre-declared fail-closed response with a circuit breaker prevents the degraded dependency from stalling the entire pipeline: the affected agent halts and returns a structured refusal rather than blocking indefinitely.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v2026.09.
© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.
AML.T0034
Cost Harvesting
view on ATLAS ↗
Adversary intentionally inflates the victim's inference bill (long prompts, expensive tools, repeated calls) to cause financial harm rather than service disruption.
Agentic angle: Loop-amplification by an agent can exceed a quarterly budget in minutes.
AML.T0046
Spamming AI System with Chaff Data
view on ATLAS ↗
Adversary floods the AI system with low-value inputs to crowd out legitimate signals, mask attacker activity, or drive up cost.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §3 RPA Expense Reimbursement Agent — Layer 7 Agent Ecosystem.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §3 RPA Expense Reimbursement Agent — Layer 7 Agent Ecosystem
Adapted by Helmwart from the OWASP source(s) above under CC BY-SA 4.0 (changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.