Unbounded Consumption

The defining property of this risk is cost asymmetry. An attacker triggers disproportionately expensive computation at negligible cost to themselves, through crafted prompts, stolen credentials, or manipulated workflows. Every other detail in LLM06:2026 follows from that ratio.

Unbounded Consumption rose four places in the 2026 list, the second-largest move after Excessive Agency. OWASP attributes the climb to practitioners weighting resource and cost exhaustion higher than the old rank allowed. Four structural changes drove it: extended-thinking and reasoning models with large or insufficiently constrained output budgets; multimodal models with substantially higher per-request compute; agentic architectures and tool-use protocols such as MCP that amplify one request into cascading downstream operations; and shared inference infrastructure introducing new supply-chain attack surface.

OWASP’s conclusion is direct: traditional request-rate limiting alone is no longer sufficient. What is needed is token-aware cost controls, hard spending caps, agent-level circuit breakers, and continuous cost-attribution monitoring.

Three distinct failures under one heading

The entry bundles three outcomes that share one root cause: absent controls over resource consumption. They fail differently, are detected differently, and are mitigated differently. Conflating them is the common mistake.

Denial of wallet (DoW) turns pay-per-call pricing into a weapon. A high volume of operations produces an unsustainable financial burden on the provider. OWASP uses the phrase “risking financial ruin”. It does not require the service to fall over. A DoW attack that degrades nothing is still successful.

Capacity exhaustion is the classic availability failure: excessive and uncontrolled inference depletes resources until the system is unresponsive.

Model extraction is theft by querying. An attacker queries the API with crafted inputs, collects enough outputs to replicate a partial model or fine-tune a functional equivalent, and walks away with the capability. Carlini et al. (2024) showed that exposure of logits and log-probabilities significantly accelerates extraction. If you return log-probs by default, you are subsidising this.

One scoping note: side-channel extraction of weights or architecture through timing or shared- infrastructure observation is not here. That is LLM02:2026 Sensitive Information Disclosure. LLM06 covers extraction by sustained querying through the intended interface.

Common examples of risk

OWASP lists nine. The ones that change how you build are the ones where input size tells you nothing about cost.

1. Variable-length input flood and output explosion. Numerous inputs of varying lengths exploit processing inefficiencies until the system is unresponsive. This also covers output explosion via fine-tuning poisoning: Gao et al. (2024) showed a single malicious training sample can break the model’s end-of-sequence behaviour so that output runs to maximum length on every request. That is a poisoning attack (see Data and Model Poisoning) with a billing consequence, and it persists until the model is replaced.
2. Denial of wallet.
3. Large-context abuse. Repeated near-limit requests, context accumulation, and application-side rechunking consume disproportionate compute and memory. OWASP makes a precise point here: many APIs reject over-limit inputs outright, so the durable risk comes from requests that stay just within limits while inflating per-request cost. The obvious defence (reject oversized input) is the one the provider already applied, and it is not where the money goes.
4. Reasoning-loop and thinking-token exhaustion. Short, benign-looking prompts force extended-thinking models into prolonged or non-terminating reasoning loops, consuming massive thinking-token budgets while bypassing input-size filters (Li et al., 2025). Because the prompts are small and look legitimate, standard input validation provides no protection at all.
5. Adversarial inputs optimised for resource overconsumption. Distinct from simply asking the model to do something expensive. This is explicit optimisation over the input space, by gradient-based or gradient-free techniques, and includes sponge examples (Shumailov et al., 2020) and adversarial visual perturbations. The distinction from reasoning-loop attacks is the optimisation step: reasoning-loop attacks are prompt design, these are search.
6. Multimodal inputs and outputs. Images, audio, and video convert into large numbers of tokens, so a single request can cost substantially more than a comparable text request. OWASP explicitly declines to give an overhead figure: the exact overhead varies with model, provider, resolution, media duration, and preprocessing pipeline. Measure it against your own stack rather than assuming a ratio.
7. Model extraction and distillation theft.
8. Agent-tool interactions flooding model resources. A published tool can force an application into recursive or infinite tool-calling loops. When one call fans out, the model may end up managing hundreds of calls spawned from a single task. Each individual action looks legitimate.
9. Inference infrastructure exploitation. Attacks on serving frameworks themselves (OWASP names vLLM, TensorRT-LLM, SGLang, Triton, and Ollama) to crash services or exhaust resources via unsafe deserialisation flaws, special-token injection, and injected chat templates.

Mitigations

Cost controls that actually stop spending

Rate limiting and user quotas remain the baseline, but must move beyond requests per second to tokens-per-minute, tokens-per-day, and estimated cost per request. Use pre-flight token estimation to reject a request before inference begins; once generation has started, the cost is largely committed.

Hard spending caps are the control OWASP is most emphatic about. Set non-overridable budget ceilings per API key, per user, per team, and per cloud account. The wording is deliberate: these must be enforcement mechanisms that halt inference when exceeded, not alerting thresholds. A fast-accumulating workload outpaces an alert. Caps should also account for cost differences between modalities and tool protocols, because a cap denominated in requests is meaningless when one request may be a paragraph or a video.

The trade-off is real and should be stated: a hard cap is a self-inflicted availability control. It will eventually stop a legitimate workload. That is the intended behaviour, and the alternative is an unbounded invoice.

Beyond that, allocate resources dynamically so that a single user or request cannot monopolise capacity, and maintain continuous cost-attribution monitoring so spend can be traced to a principal rather than appearing as an aggregate line item.

Availability controls

Design for graceful degradation: partial functionality under heavy load instead of complete failure. Cap the number of queued and in-flight actions, and pair dynamic scaling with load balancing. Note that scaling is an ambiguous control here: it protects availability while directly increasing exposure to denial of wallet. Scaling without a cap converts an outage into a bill.

Agentic controls

Agentic circuit breakers are the addition that matters most in the 2026 edition. Enforce step limits, recursion depth limits, time limits, and per-run cost ceilings on every agent execution, and use state hashing to detect recursive loops. A loop that varies its surface text will not be caught by comparing prompts, but will be caught by hashing state.

Alongside that, detect resource-intensive tool interactions: monitor agent-tool sessions for recursive or resource-intensive action without a clear end state, and establish baselines of normal tool behaviour so a tool deviating from its usual token consumption is visible. Baselining is what makes a malicious third-party tool detectable at all, since its individual calls are well-formed.

Extraction and infrastructure

Sandboxing restricts the model’s access to network resources, internal services, and APIs. Its role here is specific: constraining reach limits an attacker’s ability to exfiltrate extracted model information or data to an external destination.

Scan model inputs (particularly visual inputs to large visual language models) for adversarial perturbations that could cause resource overconsumption.

Harden inference infrastructure: keep serving frameworks updated, disable unsafe deserialisation, restrict special-token passthrough, and enforce authentication on all inference endpoints. Unauthenticated inference endpoints are a recurring finding and convert every other control on this page into decoration.

Attack scenarios

1. Uncontrolled input size. An unusually large input drives excessive memory and CPU load, crashing or badly slowing the service.
2. Repeated requests. High request volume consumes computational resources and denies service to legitimate users.
3. Resource-intensive queries. Inputs crafted to trigger the model’s most computationally expensive paths, causing prolonged GPU usage and potential system failure.
4. Denial of wallet. Excessive operations exploit pay-per-use pricing, producing unsustainable cost for the provider.
5. Functional model replication. Rather than extract the model, the attacker has it teach a replacement: query it at volume, keep the outputs as a training set, and fine-tune something else on them until the behaviour matches. No weights are recovered, and none are needed.
6. Perturbations in LVLM image input. Adversarial image inputs carry perturbations optimised to make the model overconsume tokens in its output (Gao et al., 2025).
7. Multi-turn tool-calling loops and fan-out. An attacker publishes a malicious tool (OWASP’s example is a Claude Skill on an open-source repository), instructing an agent to perform recursive cyclical tasks or tasks requiring very many tool calls. Developers who incorporate it inherit excessive token consumption and service instability.
8. Growing context in agentic sessions. An open agentic session accumulates injected content so that each inference re-processes the full context. Per-turn cost climbs from roughly $0.001 on the first turn to about $0.50 by turn 100. No single request trips a rate limit, because each stays individually within budget, yet the aggregate across many concurrent or long-lived sessions reaches hundreds of dollars. OWASP notes this scenario does not require an attacker: a benign user produces the same curve.

Scenario 8 is the clearest argument for cost-per-session and cost-per-run accounting. Per-request limits are structurally blind to it.

Related entries

• Data and Model Poisoning (LLM05:2026) - fine-tuning poisoning that breaks end-of-sequence behaviour (Gao et al., 2024) makes every subsequent request maximally expensive.
• Prompt Injection (LLM01:2026) - the delivery mechanism for many reasoning-loop and tool-loop payloads.
• Misinformation (LLM07:2026) - an agent looping on a false premise burns budget as well as producing wrong answers.
• LLM02:2026 Sensitive Information Disclosure - side-channel extraction of weights or architecture via timing or shared infrastructure, as opposed to extraction by querying.

The full list is at AI Security.