Earlier articles in this series covered prompt injection, insecure output handling, and training-data poisoning, three vulnerabilities that manipulate what a model says or learns. This entry covers a different failure mode: an attacker does not need to trick the model into anything. Overwhelming it is enough. Denial of service against a large language model does not crash a server in the traditional sense; it exploits the fact that every token processed costs real compute, real money, or both.
THE UNBOUNDED CONSUMPTION PROBLEM
The OWASP Top 10 for LLM Applications tracks this risk under LLM10:2025, Unbounded Consumption, a 2025 renaming of what the 2023 list called Model Denial of Service. The rename reflects a broader scope. Classic DoS floods a network pipe or a request queue. Unbounded Consumption floods a system where a single request can be made arbitrarily expensive by its content, not just its volume.
A traditional web server treats most requests as roughly equal cost. An LLM endpoint does not. A ten-word prompt and a ten-thousand-token prompt hit the same API route but consume wildly different amounts of GPU time. Unbounded Consumption is the umbrella OWASP uses for every attack that exploits that asymmetry, spanning resource exhaustion, economic drain, and even model extraction through repeated querying.
RESOURCE EXHAUSTION AND CONTEXT WINDOW ATTACKS
The most direct version of the attack targets compute directly. An attacker sends inputs engineered to maximize processing time relative to their size: long documents padded with dense but plausible-looking text, repeated requests that each fill the context window to its limit, or prompts that trigger long chains of tool calls in an agentic pipeline. Each individual request looks legitimate. In aggregate, they saturate the GPU pool a provider allocated for that tenant.
Academic work anticipated this class of attack outside the LLM context. Shumailov and colleagues described sponge examples in 2020, inputs crafted specifically to maximize a neural network’s energy consumption and latency rather than to change its output. Their tests increased energy use on vision and language models by factors of 10 to 200.
The paper frames the technique explicitly as a denial-of-service attack against the machine learning component of a system, not the infrastructure around it. The same logic applies to a modern LLM API: the attacker does not need a botnet, just carefully shaped input.
Multi-step agentic systems widen this surface further. A tool-calling agent that resolves one user request into five internal LLM calls turns a single incoming request into five times the resource draw, and a request crafted to trigger the most expensive branch of that logic, rather than the cheapest, amplifies the effect again.
DENIAL OF WALLET AND COST AMPLIFICATION
Pay-per-token pricing turns resource exhaustion into a financial attack. Security researchers use the term denial of wallet for this variant, since the service usually keeps running while the bill spirals. Sysdig’s threat research team documented this at scale in its coverage of LLMjacking, where attackers harvest exposed API keys and cloud credentials and route inference traffic through them. Sysdig’s analysis of a compromised AWS Bedrock account found that an attacker running requests against Claude models at maximum rate limits could generate victim costs exceeding 46,000 dollars per day, with more expensive models pushing that figure toward 100,000 dollars per day.
Cost amplification does not require stolen credentials to work against an application’s own users. A single incoming request that fans out into a multi-step agentic workflow, several tool calls, and a large context retrieval can cost fifty times more than a cached, single-turn response, while looking identical to a request-counting rate limiter. That gap between request count and actual cost is the mechanism denial-of-wallet attacks exploit, whether the attacker is external or is simply an authenticated user finding the most expensive path through the application.
MITIGATIONS: RATE LIMITING, INPUT CAPS, AND RESOURCE BUDGETING
OWASP’s guidance for Unbounded Consumption groups defenses into a few concrete controls, and none of them depend on the model itself behaving well.
INPUT VALIDATION AND CAPS
Restricting request size, enforced before the request reaches the model, is the first line of defense. Maximum input length, maximum context window usage per request, and rejection of inputs that exceed a defined complexity threshold all remove the cheapest version of the attack before it consumes GPU time.
RATE LIMITING AND QUOTAS
Per-user and per-API-key limits bound how much a single identity can request in a given window. This stops floods but, as the denial-of-wallet economics above show, request-count limits alone miss attacks that stay under the count threshold while maximizing cost per request.
COST-AWARE RESOURCE BUDGETING
The more precise control tracks spend, not request count. A pre-execution cost estimate, checked against a remaining budget for that user or tenant, catches the case a plain rate limiter misses: few requests, each disproportionately expensive. Timeouts on individual generations and hard ceilings on tool-call chains in agentic systems close the multi-step amplification path specifically.
MONITORING AND GRACEFUL DEGRADATION
Logging token counts, latency, and cost per request alongside standard traffic metrics makes the asymmetric-cost pattern visible before it becomes a bill. Systems designed to degrade gracefully, serving a smaller model or a cached response under load rather than failing outright, limit the blast radius when an attack does get through.
None of these controls require trusting the model to refuse an expensive request on its own. They sit in front of it, in the application layer, where a denial-of-service or denial-of-wallet attempt can be measured and stopped before it reaches the part of the system that costs money to run.
The next article in this series turns to three lighter but still significant OWASP entries: sensitive information disclosure, insecure plugin design, and excessive agency in autonomous systems.
T.
References
- OWASP Top 10 for LLM Applications - The official OWASP project page cataloging Unbounded Consumption and the broader LLM Top 10 referenced throughout this series.
- OWASP LLM10:2025 Unbounded Consumption - The 2025 revision’s entry defining the risk, its resource-exhaustion and denial-of-wallet attack scenarios, and its recommended mitigations.
- Sponge Examples: Energy-Latency Attacks on Neural Networks (Shumailov et al., 2020) - The research demonstrating crafted inputs that increase a model’s energy consumption and latency by factors of 10 to 200, framed explicitly as a denial-of-service attack on the ML component of a system.
- The Growing Dangers of LLMjacking (Sysdig) - Threat research documenting stolen-credential attacks against cloud LLM services, including the cost figures cited for compromised AWS Bedrock accounts.
- What is LLMjacking? (Sysdig) - Background on the mechanics of credential theft and unauthorized inference consumption that underlie denial-of-wallet attacks.
