A support chatbot goes dark at 2 a.m. Not because of a bug, not because of a network flood, but because someone pasted a 40,000-token prompt padded with repeated clauses into the feedback box, and the model's self-attention mechanism spent seconds — then minutes — chewing through it on a shared GPU pool. Multiply that by a few hundred concurrent requests and the inference cluster is pinned at 100% utilization while paying customers get timeouts. This is an LLM denial of service attack: no exploit, no malware, no CVE — just carefully shaped input exploiting how transformer inference actually works. As enterprises wire LLMs into customer support, coding assistants, and autonomous agents, this attack class has moved from academic curiosity to production incident. OWASP now tracks it as a top-ten risk in its own right. Here's how these attacks work, what research has already demonstrated, and how to defend against them.
What is an LLM denial-of-service attack?
An LLM denial-of-service attack is any input or usage pattern designed to make a language model consume disproportionate compute, memory, or cost relative to a legitimate request, degrading or crashing the service for other users. OWASP's Top 10 for LLM Applications renamed this category from "LLM04:2023 Model Denial of Service" to the broader "LLM10:2025 Unbounded Consumption," reflecting that the risk now spans classic latency attacks, runaway generation, and financial exhaustion ("denial of wallet") rather than just crashed servers. Unlike a volumetric network DDoS, which floods bandwidth with junk packets, an LLM DoS attack often needs only a single, well-crafted request. A 200-token prompt can trigger a 4,000-token response, dozens of tool calls, or a multi-hop retrieval chain — turning a trivial request into a compute-intensive one and making rate limiting by request count alone ineffective.
How do "sponge" inputs exhaust GPU and energy resources?
Sponge inputs work by exploiting the fact that inference cost for a transformer scales with sequence length and token complexity, not with how "meaningful" the input is. The technique was formalized in the 2021 paper "Sponge Examples: Energy-Latency Attacks on Neural Networks" (Shumailov et al.), which showed that adversarially optimized inputs could push NLP and vision models into worst-case compute paths, increasing energy use and latency by anywhere from several times to multiple orders of magnitude depending on the model architecture and hardware. Applied to LLMs, sponge-style inputs typically use dense, high-entropy token sequences, repeated rare tokens, or structures that maximize attention computation. Because self-attention costs grow quadratically — O(n²) — with input length, an attacker who can submit long inputs (via file uploads, pasted documents, or chained conversation history) gets an outsized compute return on a small amount of effort, and a handful of concurrent sponge requests can saturate a GPU that would otherwise serve hundreds of normal users.
Can a single prompt make an LLM generate output forever?
Yes — this is exactly what "unbounded generation" or poisoning-based DoS (P-DoS) attacks demonstrate. A 2024 study, "Denial-of-Service Poisoning Attacks Against Large Language Models" (Kang et al.), showed that an attacker who can influence a small slice of a model's fine-tuning data — a viable path when teams pull instruction-tuning datasets or LoRA adapters from public hubs — can train the model to suppress its own end-of-sequence token under specific trigger conditions. The result: the model keeps generating until it hits the hard max-token ceiling on nearly every triggered query, instead of stopping after a normal 50–200 token reply. Separately, the "Engorgio" attack line of research (2024) crafted adversarial prompt prefixes that push chatbot outputs toward the maximum generation length far more often than benign traffic does, multiplying per-query GPU time and API cost by an order of magnitude without ever tripping a content filter, because the output text itself looks perfectly normal.
Why does a long context window make LLMs a bigger target than a typical web API?
Because context windows that used to top out at 4K or 8K tokens now routinely run to 128K, 200K, or 1M+ tokens, and every one of those tokens gets re-processed on each turn of a conversation. A single malicious PDF, an oversized support ticket, or a poisoned web page ingested by a RAG pipeline can silently inflate the context an application sends to the model on every subsequent request in that session. In agentic and RAG architectures, this compounds: a retrieval step that pulls in an attacker-controlled document with repeated or padded content can balloon the prompt sent to the model well past what the user actually typed, and because that cost is paid on every follow-up turn, a single injected document can degrade an entire session rather than one request. Teams that size their infrastructure and rate limits around "typical" request volume are frequently unprepared for the tail-end cost of a single adversarial context.
What happens when denial of service meets denial of wallet in agentic AI?
They merge into a single attack: an agent that is tricked into looping keeps consuming API credits and compute even if the underlying service never technically "goes down." Autonomous and multi-agent systems chain LLM calls to tools, sub-agents, and external APIs, so a prompt-injection payload that convinces an agent to retry a failing tool call, re-plan indefinitely, or spawn recursive sub-tasks can rack up thousands of billed API calls in minutes — a cost-based denial of service sometimes called "denial of wallet." Because each individual call looks legitimate to a per-request rate limiter, this failure mode routinely evades defenses built for classic DoS and instead shows up first on the cloud invoice or the LLM provider's usage dashboard, often a day or more after the triggering interaction.
Are old-fashioned network DDoS attacks still a threat to LLM providers?
Yes, and they've already taken down major AI services. On November 8, 2023, OpenAI confirmed that a wave of "abnormal traffic" — a distributed denial-of-service attack later claimed by the group Anonymous Sudan — caused hours of intermittent outages and degraded performance across ChatGPT and the OpenAI API. The incident is a reminder that LLM deployments inherit every conventional infrastructure risk (volumetric floods, application-layer request storms) on top of the model-specific attacks described above, and that the two threat classes can be combined: a network-layer flood that forces failover to smaller backup capacity, paired with sponge or unbounded-generation prompts, can exhaust the reduced capacity far faster than either technique alone.
How Safeguard Helps
LLM denial-of-service resilience is, at its core, a supply chain problem: the fine-tuning data, base models, adapters, prompt templates, and agent frameworks that make these attacks possible are pulled in from third-party sources long before a single malicious prompt is ever sent. Safeguard treats the AI stack as part of the software supply chain and secures it accordingly.
- Model and dataset provenance verification. Before a fine-tuned model, LoRA adapter, or instruction dataset from a hub like Hugging Face is promoted to production, Safeguard verifies its origin, checks for tampering, and flags unvetted training data — closing the door that P-DoS-style poisoning attacks rely on.
- AI-BOM for full lineage tracking. Safeguard generates and maintains an AI bill of materials that records which base model, dataset, and adapter versions are running in each environment, so a poisoned upstream artifact can be traced and pulled everywhere it was deployed, not just where it was first spotted.
- CI/CD policy gates for AI-specific risk. Safeguard enforces guardrails — maximum context length, output token ceilings, tool-call recursion limits — as checks in the deployment pipeline, so unbounded-consumption configurations never reach production in the first place.
- Runtime anomaly monitoring. Safeguard's monitoring integrations watch for the signatures of sponge and unbounded-generation attacks in production: abnormal input-token distributions, generation lengths clustering at the max-token cap, and agentic loops with runaway tool-call counts, alerting teams before a cost spike becomes a bankrupted budget.
- Third-party agent and plugin vetting. Because agent frameworks and plugins introduce their own dependency trees, Safeguard scans these components the same way it scans traditional software dependencies, surfacing risky retry logic, missing rate limits, or unvetted external calls before they ship.
LLM denial-of-service attacks succeed because they hide inside legitimate-looking traffic and legitimate-looking model artifacts. Securing the supply chain those artifacts come from — not just the network perimeter around the inference endpoint — is what turns an unpredictable AI outage into a contained, traceable, and preventable event.