Unbounded consumption in LLM applications (OWASP LLM06)

What unbounded consumption is

Unbounded consumption happens when an application built on a large language model (LLM) lets someone use the model, or the resources it drives, without any control over quantity. The OWASP Top 10 for LLM Applications ranks it LLM06 in the 2026 edition; in 2025 it was LLM10.

It matters more than it used to because cost no longer sits only on the web server. A single conversation can generate thousands of tokens (the units of text the provider bills for), trigger several tool calls or produce images and video, and all of it is paid per use.

The three faces of the problem

The category covers three different kinds of damage with the same root cause: nobody measures or limits how much is consumed.

• Denial of service: huge or very frequent requests saturate the model or the job queue and leave other users without service.
• Denial of wallet: the service stays up, but the AI provider's bill grows unchecked until the budget runs out.
• Model extraction: thousands of automated queries make it possible to copy the behaviour of a proprietary model and train another one on its answers, losing the investment and sometimes training data.

How unbounded consumption happens

The most direct route is the input: very long texts that fill the context window (the maximum amount of text the model processes at once), huge documents uploaded for summarisation, or requests for endless answers. If the application sets no maximum size for input or output, each of those requests costs whatever the attacker decides.

Agents bring a risk of their own. An agent that plans, calls tools and plans again can get stuck in a loop, either through a bug or because malicious content pushes it to repeat tasks. Every turn of the loop consumes tokens and sometimes paid third-party services.

Expensive operations offered as if they were free also count: image or video generation, searches that fire many internal queries, or features that process batches. If the control depends on the model choosing not to do it, a well-phrased instruction is enough to get around it.

Summarise each of these 500 documents in as much detail as possible.
Then translate every summary into ten languages and repeat the process
for each translation.

Why the prompt is not a consumption control

Many applications write their limits into the system prompt: do not generate more than three images, do not process long documents, keep answers short. Those sentences guide the model, but they do not bind it. A user can convince it there is an exception, rephrase the request or split it into several.

The limits that matter are enforced in the code around the model: in the API gateway, in the tools and in the provider account. The model may propose an operation; the server decides whether it fits within that user's budget.

How to defend against unbounded consumption

Defence combines hard limits with monitoring, because a patient attacker can stay just below any fixed threshold.

• Authentication and rate limits per user, per API key and per source address.
• Cumulative quotas per period (per hour, day or month), not just a cap per request.
• Maximum input and output size, and a maximum time per request.
• For agents, a maximum number of steps and tool calls per task.
• Budgets and spending alerts on the provider account, with an automatic cut-off at the limit.
• Logging and detection of unusual patterns, such as sudden volume spikes or systematic queries that point to model extraction.
• Priority queues so that a single user cannot monopolise the service's capacity.