Unbounded consumption in LLM applications — OWASP LLM Top 10 explained

The original framing of model denial of service was a direct analogue of classic network DoS: an attacker saturates a finite resource — request throughput, token quota, inference capacity — until the service degrades or the bill becomes unsustainable. The control model that follows from this framing is capacity-based: count requests, count tokens, cap both, alert on anomalies.

That framing assumed something that stopped being reliably true as LLM applications matured: that the cost of serving a request is roughly proportional to the size of the request. In a single-turn chat application, that assumption mostly holds. In an agentic application — one where a request can trigger tool calls, sub-agent delegation, retrieval loops, or multi-step reasoning — it does not. A five-word user prompt can trigger a chain of a dozen internal LLM calls, each with its own token cost, none of which a request-count limit at the edge ever sees as separate events. OWASP renamed the category because the threat it needed to describe had outgrown the “attacker floods the endpoint” mental model entirely.

Read as Unbounded Consumption rather than Model DoS, the category covers four distinct resource classes, only the first of which is well served by conventional API rate limiting.

The first class — request volume — is the one most teams already have a control for, because it is the one that looks like a familiar API security problem. The other three are where Unbounded Consumption reviews find gaps, because each one requires a control that does not exist in a standard API gateway's default feature set.

Computational complexity per request is the resource class that most clearly separates old-model-DoS thinking from Unbounded Consumption thinking. The old framing measured cost by looking at the request: how many input tokens, how long the context. That measurement misses adversarial inputs designed to maximize what the model does internally rather than what the user typed — a short prompt engineered to reliably trigger extended chain-of-thought reasoning, an exhaustive step-by-step plan, or a maximal-length structured output. The input is small. The compute it provokes is not.

This matters specifically for reasoning-capable models and agent frameworks that let the model decide how much internal work a task warrants. A control that caps input tokens does nothing here, because input tokens were never the cost driver. The control has to look at what the model actually produces — reasoning tokens, planning steps, intermediate tool calls — and cap that, independent of how the request arrived.

A distinct and, in our experience, underappreciated resource class is generation that never terminates the way it should — not because an attacker crafted a prompt to provoke a long completion, but because a decoding-level failure produces a repetition loop or an output that runs to the maximum length on every occurrence of a particular input pattern. Degenerate repetition (the model repeating a phrase or structure until it hits a hard token ceiling) is a known failure mode of autoregressive decoding under certain sampling configurations, and it does not require any adversarial intent to trigger. A legitimate user with an unremarkable query can hit it.

This is a genuinely different control problem from the amplification attacks covered in the model-DoS field note, because the failure is internal to the generation process, not a property of the input the attacker chose. The control has to sit at the decoding layer: a hard output length ceiling as a backstop regardless of cause, and, where the serving stack supports it, repetition detection that halts generation early rather than running to the cap on every occurrence.

The resource class most specific to Unbounded Consumption as OWASP now frames it — and the one with the least precedent in classic API security — is cost amplification through agentic tool-call recursion. An agent that can call tools, and whose tools can themselves trigger further model calls (a sub-agent, a retrieval-then-synthesize step, a self-critique loop), has a resource consumption profile that is not bounded by the size or frequency of the requests reaching it from outside.

The specific failure pattern is a planning or tool-use loop that does not terminate cleanly: the agent calls a tool, the tool result prompts another tool call, and without an explicit recursion-depth limit, nothing structural stops the chain from continuing until a timeout or a budget exhausts by accident rather than by design. Each hop in the chain is, from the model provider's billing perspective, an ordinary inference call — indistinguishable from a legitimate one — which means neither a request-rate limit at the application's edge nor a per-request token cap on the original user turn catches it. The chain is internal.

This is the resource class that most directly requires a control with no analogue in traditional API rate limiting: a circuit breaker specifically on tool-call recursion depth, and a session-level token budget that spans every internal call the original request triggers, not just the call the user directly initiated.

Context-window stuffing is covered in the model-DoS field note as a resource-exhaustion attack that degrades latency for concurrent users. It also belongs in the Unbounded Consumption category for a second, distinct reason: cost. Many agentic and retrieval-augmented architectures accumulate context across a session — prior turns, retrieved documents, intermediate tool outputs — and resubmit that accumulated context on every subsequent call in the chain. Without an explicit ceiling on accumulated session context, a long-running agentic session can see its per-call token cost grow steadily across the session's lifetime, independent of what any single turn requires.

The distinguishing control question here is not “is there a context length cap” — most systems have one, imposed by the model's maximum context window. It is whether there is a session-level token budget that triggers context pruning or truncation before the accumulated cost, not just the raw context length, becomes the problem.

The last resource class sits below the application layer entirely, in the inference infrastructure itself, and it is specific to self-hosted or open-weight deployments running continuous-batching inference servers (vLLM and similar schedulers). Continuous batching improves throughput by packing multiple concurrent requests into shared GPU batch slots and scheduling new requests into slots as earlier ones complete. A single request with an unusually long generation — whether adversarially crafted or simply an unbounded-output failure of the kind described above — occupies a batch slot for the duration of its generation, and in some scheduler configurations can degrade throughput or latency for every other request sharing that batch.

This is a GPU resource exhaustion pattern that a per-request token cap enforced at the application gateway does not prevent by itself, because the exhaustion happens at the scheduling layer inside the inference server, not at the point where the gateway measures request size. It is a reason the output-length ceiling and the tool-call recursion breaker described above need to be enforced close to the inference layer, not only at the application's outer edge — a control that only caps what reaches the gateway leaves the GPU scheduler exposed to whatever request pattern gets past it.

Classic API rate limiting assumes each request costs roughly a fixed, bounded amount, and that the way to prevent resource exhaustion is to cap how many of those roughly-equal-cost units a given identity can submit in a time window. Unbounded Consumption, taken as OWASP now frames it, breaks both halves of that assumption: request cost is not fixed — it can vary by orders of magnitude depending on what the model is provoked to produce internally — and the relevant unit of consumption is not always the external request at all, because agentic chains generate internal requests the rate limiter never observes.

The practical consequence for a review: a system that can produce a clean rate-limiting configuration — request caps, per-user quotas, 429 responses on overage — has answered the request-volume resource class and left the other three unaddressed. A control set that stops at rate limiting is necessary and insufficient for Unbounded Consumption as the current OWASP definition describes it.

The minimum control set for the resource classes covered in this piece, beyond the request-rate controls already documented for classic model DoS:

• Token ceilings at both the request and the session level. A per-request cap alone does not bound an agentic session's accumulated cost across a chain of internal calls; a session-level budget is required alongside it.
• A hard output-length ceiling enforced at the serving layer, not a soft instruction to the model, with repetition or loop detection where the serving stack supports it.
• A circuit breaker on tool-call recursion depth, distinct from any request-rate limit, that terminates a chain of internal agent-to-model or agent-to-tool calls past a defined depth or budget.
• Session-context pruning tied to an accumulated token budget, not just the model's maximum context window.
• A cost-anomaly alerting architecture that treats a spike in internal call volume — not just external request volume — as a signal. This is a design-time control requirement a review checks a system for; it is not something Drel operates or monitors on the system's behalf.

A review that verifies all four resource classes, not just request volume, is checking the definition OWASP actually publishes today — the rename from Model Denial of Service to Unbounded Consumption is the specification, not a suggestion for further reading.