Model Denial of Service in LLM Deployments
LLM attacks now work by making inference expensive, not by crashing servers.

The instinct, when you hear "denial of service," is to picture something crude: a flood of junk traffic hammering a server until it falls over. That mental model works fine for a 2003-era network attack. It doesn't work at all for what's happening to LLM deployments today.
The more you sit with how language models actually consume resources, the more the old framing dissolves. The server doesn't go down. The API keeps accepting requests. The model keeps generating tokens. And somewhere, almost invisibly, the operator's bill climbs into the tens of thousands of dollars per day, legitimate users get throttled into uselessness, and nobody's availability dashboard fires a single alert. That is the actual shape of the problem.
OWASP's taxonomy committee noticed it too. Their 2023 category was called "Model Denial of Service." By April 2025, they'd renamed and broadened it to "Unbounded Consumption," explicitly covering service degradation, runaway costs, and model extraction alongside traditional availability attacks. That's not a minor editorial revision. That's a committee acknowledging that the original frame was too narrow.
Three distinct harm modes live inside this problem: availability failures that lock users out, financial attacks that weaponize cloud spend against the operator, and integrity attacks that systematically extract proprietary model behavior. Each mode has different detection signatures. Each one matters to a different person in your organization: operations, finance, and legal or IP counsel, respectively. Understanding that fracture is the first step toward addressing any of it.
How LLMs Are Structurally Built to Be Expensive to Abuse
Start with the token. Every major provider, whether OpenAI, Anthropic, Google, or AWS Bedrock, charges per token processed. A token is roughly a word or a word-piece; both input tokens and output tokens count against your bill. But output generation is where the latency and compute really accumulate. The model has to produce each token sequentially, sampling from a probability distribution, before it can produce the next one.
Now layer in the architecture underneath. Transformer models compute attention across every token in the input sequence simultaneously. The computational cost of that attention operation scales roughly with the square of the input length. Double the context, and you more than double the compute. This isn't a bug that will get patched out; it's a structural property of how transformers work. And it means a carefully crafted long input is not just big, it is disproportionately expensive.
Research has documented a direct proportionality between output token count and both energy consumption and response time. Attackers who understand this aren't just being inconvenient; they are maximizing cost per request in a calculable way.
Reasoning models add a second layer of exposure. Models like OpenAI's o-series generate an internal chain-of-thought trace before producing a visible answer. That trace consumes tokens the user never sees but the operator pays for in full. You can have a perfectly correct, concise visible answer sitting on top of a reasoning trace that cost ten times as much to generate.
Production deployments push this further. RAG pipelines inject retrieved documents into context. Tool call results come back and get appended. Conversation history accumulates. Operators use large context windows by design because that's what makes the product useful. That's also exactly the surface an attacker looks to fill.
Multi-step agent workflows compound everything. A single user request that initiates an agentic loop can trigger many downstream inference calls, each with its own token cost, none of which are visible as separate requests to a conventional rate limiter. And in physical-world deployments, an embodied AI or autonomous vehicle system under resource exhaustion doesn't just return a slow response; it becomes incapable of reacting to dynamic conditions at all.
The Sponge Attack: How Input Crafting Forces Expensive Computation
In 2021, Shumailov and colleagues introduced the concept of "sponge examples," inputs crafted specifically to maximize a model's computational burden rather than to extract any useful output. The name is apt. These inputs are designed to absorb compute the way a sponge absorbs water.
The core insight exploits the quadratic attention cost. If you can construct an input that forces the model to attend across the widest possible key-value space, you stress the architecture at its most expensive dimension. The inputs themselves don't need to be semantically meaningful. Spelling errors, non-semantic characters, adversarially constructed token sequences that look syntactically normal enough to pass casual inspection but are maximally costly to process: these are the raw materials.
The measured effects are not marginal. IEEE EuroS&P research on sponge examples demonstrated latency increases of up to 30 times on language models. One attack pushed Microsoft Azure Translator from a one-millisecond response to six seconds, a degradation of roughly six thousand times.
What makes sponge attacks particularly tricky to defend against is that they're invisible to the heuristics most operators actually deploy. The inputs don't crash the model. They don't produce obviously harmful output. They don't exceed request-count rate limits. They simply cost far more to process than typical inputs, and nothing in a conventional monitoring stack is watching for that signal.
This attack class is the template. Every subsequent technique in the taxonomy either refines the mechanism or redirects it toward a different part of the system.
EOS Suppression and Prompt-Level Over-Generation Attacks
The EOS token is the model's stop sign. When the model generates it, output halts. If you can delay or suppress that signal, the model keeps producing tokens, and the meter keeps running.
Engorgio-style prompts are adversarially constructed to do exactly that: inhibit end-of-sequence generation so the model produces abnormally long outputs from a single request. Researchers including Geiping and colleagues systematized the adversarial objectives for this class of attack, and subsequent work developed specific loss functions, including delayed EOS loss, uncertainty loss, and token diversity loss, each designed to explicitly incentivize over-generation.
The arithmetic is straightforward and unforgiving. A prompt that doubles average output length roughly doubles per-request cost. Sustained across many concurrent requests, that compounds quickly into a significant billing event.
Two variants extend the surface. Context window flooding constructs inputs that fill the model's available context limit, forcing expensive computation across the entire window before a single output token is produced. Recursive prompting feeds model output back as input in a loop, creating exponential token growth across turns of a conversation.
The attacker's structural advantage here is timing. They choose the prompt. The operator cannot inspect output length until generation completes, and by the time that happens, the compute is already consumed and the cost is already accrued. You can't un-generate tokens.
The OverThink Attack and What Reasoning Models Add to the Attack Surface
Reasoning models introduced something genuinely new to this threat landscape. The hidden think trace is billed as output tokens, which means a class of attacks exists that makes the model expensive to run without producing any visible signal of compromise.
The OverThink attack, documented in early 2025 by Kumar and colleagues, works by injecting decoy reasoning problems into content the model retrieves at inference time, specifically targeting RAG pipelines. The attacker doesn't touch the user prompt at all. They poison a document or data source that the model will fetch during retrieval. The model ingests the poisoned document, gets pulled into extended internal deliberation by the embedded decoy problems, and produces a visible answer that remains correct. Only the reasoning trace balloons.
The demonstrated amplification is substantial: token generation increases of up to ten times compared to baseline.
The implications for defenders are uncomfortable. Monitoring output quality won't catch this. Response coherence checks won't catch it. The attack is invisible to any evaluation that looks at what the model says rather than what it costs to say it. Token consumption in the reasoning trace has to be measured separately, which most production deployments don't do today.
There's also a supply-chain dimension worth sitting with. If any document in a RAG corpus can carry an OverThink payload, the attack surface extends to every data source the model is authorized to retrieve from. That's a wide perimeter, and most of it belongs to someone other than the model operator.
Poisoned Fine-Tuning and Backdoor DoS
Runtime attacks require the attacker to interact with the deployed model. Training-time attacks require only that the attacker influence what the model learned before deployment, and the threat persists indefinitely in the model's weights.
Researchers have demonstrated training-time backdoors that induce sustained output elongation and resource exhaustion. The mechanism is a small number of malicious training examples embedded in the fine-tuning dataset. On clean inputs, the model behaves normally. On inputs containing a specific trigger pattern, it burns resources. Work by Cinà and colleagues in 2025 documented this capability in detail.
The attack success rates observed across agent benchmarks for code, operating system, and web shopping tasks exceeded ninety percent. That's not a marginal capability being demonstrated in a lab; that's a highly reliable attack vector.
The operational reality for enterprises is direct: organizations that fine-tune on community datasets or deploy externally fine-tuned models inherit any backdoors present in that training data. Standard pre-deployment evaluation suites test for capability and alignment. They do not test for embedded computational backdoors that only activate under specific runtime conditions. That gap exists right now in most deployment pipelines.
Safeguard Exploitation as a DoS Vector
Content filters and safety classifiers are themselves machine learning models with learnable decision boundaries. Which means they are, in principle, exploitable.
The attack class here inverts the usual concern. Instead of crafting inputs that evade safeguard rejection, the attacker crafts inputs that cause the safeguard to reject legitimate user requests at scale. They weaponize the safety layer to produce false positives, effectively locking a class of users out of the service.
Documented research shows that adversarially optimized prompts of approximately thirty characters can trigger safeguard rejections for nearly all requests from a targeted client. The optimization uses gradient and attention information from the safeguard model itself, the same interpretability tools that alignment researchers use for legitimate purposes.
What makes this particularly hard to detect is what doesn't happen. Throughput looks normal. The model is up. Availability metrics are green. But a specific population of users is being denied service, and the mechanism is a short, plausible-looking prompt that can be hidden almost anywhere in the user interface. Standard logging won't surface it without specific instrumentation.
LLMjacking and Denial-of-Wallet Through Stolen Credentials
LLMjacking is the credential theft variant: attackers obtain stolen API keys or compromised non-human identity credentials and use them to run unauthorized LLM inference, charged to the victim's account.
The financial scale is documented concretely. Sysdig's research found that Claude 2.x LLMjacking attacks generated $46,080 per day in costs for victims. Claude 3 Opus targets pushed that above $100,000 per day. OWASP's 2025 documentation describes a startup that received over 100,000 unauthorized requests in 48 hours, generating a $200,000 bill and forcing the company to shut down. A stolen Google Gemini API key reported in early 2026 generated $82,000 in costs within 48 hours.
The credential market that enables this is liquid and cheap. Stolen API keys sell for as little as $30 on underground markets, producing extraordinary attacker ROI against victims absorbing six-figure losses. The supply of exposed credentials is not scarce: over 39 million secrets were exposed on GitHub in 2024, and attackers have demonstrated the ability to detect newly committed keys in under four minutes.
What started as a billing attack has evolved into something more dangerous. By late January 2026, the majority of attack traffic in Operation Bizarre Bazaar had shifted toward MCP reconnaissance: using compromised LLM access as an entry point to probe file systems, databases, shell access, and Kubernetes clusters. The denial-of-wallet is real, but the foothold is increasingly the point.
The detection gap is structural. The service never goes down. No availability alert fires. The attack runs undetected until a billing cycle closes, which can mean weeks of exposure.
Agentic and MCP Tool-Layer Attacks as the Emerging Frontier
Single-turn attacks are cost-capped. A request completes, tokens are billed, the session ends. Multi-turn agentic loops remove that ceiling entirely.
LLM agents call external tools iteratively: APIs, databases, code interpreters, web browsers. Each tool call can trigger additional inference. Each inference is billed. An agent tasked with completing a multi-step objective generates dozens of downstream inference calls before returning a final answer, none of which are visible as discrete requests to a rate limiter watching the entry point.
Research has demonstrated an attack operating at the MCP tool-coordination layer rather than the prompt or RAG context layer. By injecting cost amplification into the protocol that mediates agent-tool communication, this attack drove GPU key-value cache occupancy from under one percent to between thirty-five and seventy-four percent, cutting throughput for co-running workloads by approximately fifty percent. The server remains protocol-compatible. Task outcomes remain correct. The only signal is economic and computational cost accumulating across the session.
The connection to LLMjacking reconnaissance is direct. Once an agent has tool access, a compromised or malicious MCP server can orchestrate resource exhaustion across the entire connected environment. The security perimeter for LLM denial of service is no longer the model endpoint. It extends to every tool, connector, and data source the agent is authorized to reach.
Why Standard Rate Limiting Fails Against These Attack Classes
Rate limiters count requests. They answer "how many?" They do not answer "how expensive?"
An attacker who maps the most computationally expensive execution paths available to them can stay comfortably under request-count thresholds while draining the token budget. The limits never trigger. The billing accumulates.
There is also a fundamental accounting problem. Exact request cost is only known after LLM response generation completes. You cannot pre-bill what you haven't generated yet. Implementing cost-aware limits requires provisional reservation at request initiation and true-up accounting on completion, a more complex system than most deployments have built.
Reasoning models deepen the gap further. Think-trace token consumption is invisible to any rate limiter that counts only visible output or input size. You can be tracking every metric your infrastructure exposes and still have no view into the primary cost driver for o-series class models.
Agentic loops make the problem structurally worse. A single user request initiating a multi-step workflow can generate an unbounded number of downstream inference calls. A per-request rate limit at the entry point captures none of them. The limit applies to one; the cost is borne by many.
The denial-of-wallet attacker's strategy is built around this gap precisely: stay stealthy, stay under every threshold that exists, maximize cost per permitted request. The attack is designed for the monitoring stack that most operators have actually deployed.
Defensive Controls Matched to Each Attack Mechanism
The pattern across every attack class described above is that generic controls fail because the mechanisms are specific. The defenses need to match.
Input Controls
Hard input length limits at the API gateway reduce the sponge attack surface and prevent context window flooding before the transformer ever sees the request. This is blunt but effective as a first layer.
Structural validation of retrieved RAG content before it enters the context mitigates OverThink-style injection. Documents pulled from external sources should be inspected for embedded instruction patterns and unusual structural complexity before being appended to the model's context window.
Prompt anomaly detection targeting token sequences with non-semantic characters or unusual entropy catches sponge-style crafted inputs that are invisible to content-based filtering but distinguishable by their statistical properties.
Output and Budget Controls
Maximum token budgets per request cap EOS suppression and over-generation attacks. The model stops when the budget is exhausted regardless of whether it has generated an EOS token. This is a hard ceiling and it matters.
Cost-aware rate limiting, throttling on token consumption rather than request count, is the control most teams have not deployed and the one the research gap most clearly identifies. It requires the accounting infrastructure described above, provisional reservation plus true-up, but it's the only mechanism that actually matches how these attacks accumulate damage.
For reasoning models specifically: cap think-trace tokens separately from visible output tokens. Treating the reasoning trace as an invisible cost with no budget ceiling is how you expose yourself to OverThink amplification at scale.
Agentic and Tool-Layer Controls
Circuit breakers on agent loops halt a session when cumulative token spend or tool-call count exceeds a defined threshold. This applies a session-level budget to the multi-turn problem that per-request limits cannot address.
Monitoring the full agent execution trace, not just the entry-point request, is necessary to surface MCP-layer attacks and runaway agentic loops. If your observability only covers what enters through the user-facing API, you have no visibility into the majority of the cost surface for deployed agents.
MCP server allowlisting and integrity verification reduce the attack surface for tool-layer injection. If the agent can only communicate with explicitly authorized, cryptographically verified tool endpoints, a malicious or compromised MCP server cannot inject cost amplification into the coordination layer.
Credential and Supply-Chain Controls
Secret scanning on every code repository commit, with automated revocation on detection, addresses the GitHub exposure pipeline. The four-minute window between exposure and attacker detection means manual review is not a viable response; the revocation has to be automated.
Pre-deployment evaluation of fine-tuned models for anomalous output length distributions on trigger-pattern inputs detects backdoor DoS before the model goes into production. This requires building specific test suites that probe for computational inefficiency, not just capability or alignment, a practice that most organizations have not yet standardized.
Spending alerts with low thresholds and short detection windows are the last line of defense against denial-of-wallet attacks. They don't prevent the attack, but they can bound the damage by surfacing it before a billing cycle closes.
The through-line across all of this is measurement. You cannot defend against resource exhaustion attacks using controls that don't measure resources. Requests counted, dollars spent, tokens consumed, reasoning trace length, session-level tool call depth: each of these metrics corresponds to a specific attack vector, and an absent metric is an unmonitored attack surface. The attackers already know which ones you're not watching.


