When the Model Never Stops: LLM06 Unbounded Consumption

LLM06 Unbounded Consumption and denial-of-wallet attacks on AI applications.

Part 9 of the AI Pentesting series. Previous: Data and Model Poisoning: Backdoor Triggers Lurking in Training Sets

Most LLM security discussions focus on what a model might say or leak. LLM06 is about something different: what a model might spend. An AI application that lets anyone trigger unlimited inference does not usually crash. It stays up, keeps answering, and quietly runs a bill far past anything anyone budgeted for, until the invoice, the rate-limit alert from the provider or the throttled production service makes it impossible to ignore.

The OWASP Top 10 for LLM Applications 2026 lists this as LLM06: Unbounded Consumption, and it moved up the ranking this year. The reason is simple: inference costs real money and real compute, and agents that can call tools and other models in loops have turned “an expensive query” into “an unbounded one.”

This article explains what Unbounded Consumption is, the attack patterns behind it, how to test for it safely, and why the fix is architectural rather than a content filter.

Key takeaways

Unbounded Consumption is a resource and cost attack, not a data attack; the classic outcome is “denial of wallet,” not downtime.
Agentic systems make it worse: one request can fan out into many model calls and tool calls.
Model extraction, where an attacker queries an API enough to clone its behavior, is also part of this category.
The defense is architectural: budgets, quotas, token and output limits, agent step and depth limits, circuit breakers and monitoring, not prompt filtering.

What Is LLM06 Unbounded Consumption?

Unbounded Consumption covers any LLM application that allows excessive, uncontrolled inference. Where a traditional denial-of-service attack aims to take a service down, this one often leaves the service running while its cost or resource use climbs without limit.

It differs from the rest of the OWASP list in an important way. Prompt injection and data poisoning are about making the model behave a certain way, and they are fought with content controls. Unbounded Consumption is about how much the model is allowed to do, and it is fought with resource controls. A perfectly aligned model that never says anything harmful can still bankrupt the service running it.

Why the Cloud and Agent Era Makes It Worse

Three shifts turned this from a theoretical concern into a top-ranked risk:

Usage-based pricing. Most LLM APIs bill per token. Every extra token of input, output or “thinking” has a direct cost, so an attacker who inflates token usage inflates the bill.
Autonomous agents. An agent does not answer once and stop. It reasons, calls tools, reads results, reasons again and may call other agents. A single user request can expand into dozens or hundreds of model and tool calls.
Elastic infrastructure. Auto-scaling keeps the service responsive under load, which also means it keeps spending under an attack instead of failing fast. The system’s resilience becomes the attacker’s lever.

The Attack Patterns

OWASP catalogues several distinct ways Unbounded Consumption plays out.

1. Denial of Wallet

The signature pattern. Instead of knocking the service offline, the attacker drives its running cost past the budget. Automated scripts send a high volume of expensive requests, or a smaller number of requests crafted to maximize cost per call: very long inputs, prompts that force very long outputs, or questions engineered to trigger maximum “reasoning” on models that bill for thinking tokens. The service stays healthy on every dashboard except the billing one.

2. Token and Context Inflation

A single request can be made disproportionately expensive. Pushing the input toward the model’s maximum context window, uploading large documents for summarization, or asking for exhaustive, maximum-length output all multiply token usage per request. If the application does not cap input size, output length and conversation history, one caller can consume as much as hundreds of ordinary users.

3. Agent-Tool Fan-Out

The most dangerous pattern in agentic systems. One query triggers unbounded branching: the agent calls a tool, the result prompts more sub-questions, each spawns more tool calls or model invocations, and the tree grows. Without a cap on steps, depth or total calls, a seemingly innocent request (“research every competitor and summarize each in detail”) can expand into an enormous, self-multiplying workload. This connects directly to Excessive Agency (LLM03): the more tools and autonomy an agent has, the further a fan-out can run.

4. Recursive and Looping Calls

Agents that can call themselves, call other agents or re-enter the same workflow can get stuck in loops that a human would never run. A multi-agent setup where agent A asks agent B, which asks agent A again, can consume resources until something external stops it. Prompt injection can deliberately induce such loops.

5. Model Extraction

A different goal with the same mechanism: an attacker sends a large, systematic volume of queries, not to exhaust the budget but to collect enough input-output pairs to reconstruct, fine-tune a clone of, or steal the behavior of a proprietary model. It is theft of intellectual property carried out through ordinary API calls, and from the infrastructure’s point of view it looks like heavy usage, which is why it belongs under this category.

Impact: More Than a Big Bill

The consequences span cost, availability and intellectual property:

Financial loss. Direct, sometimes severe, spend on inference and infrastructure. For a startup on usage-based pricing, a weekend of unthrottled abuse can be existential.
Service degradation for real users. Even when cost is capped, resource exhaustion can slow or throttle the service for legitimate customers, a classic availability failure.
Provider-level limits. Hitting the upstream provider’s rate or spend limits can take the whole feature offline, turning a cost attack into an outage.
IP theft. Model extraction can erode the competitive advantage of a model that cost a great deal to build.

Testing for Unbounded Consumption

Because this is a resource attack, testing it carelessly can create real cost or a real outage. Every test must run inside the scope and budget limits agreed in writing, ideally against a staging environment with its own spending cap.

An assessment typically checks:

Input limits. Is there a cap on prompt size, uploaded document size and conversation history length? What happens at the context-window boundary?
Output limits. Can the caller force very long or maximum-length responses? Is max_tokens enforced server-side rather than trusted from the client?
Rate limits and quotas. Are limits applied per user, per API key and per IP? Are they enforced server-side, and do they cover authenticated and unauthenticated paths? Can they be bypassed with new sessions or keys?
Agent step and depth limits. For agentic systems, is there a hard cap on tool calls, reasoning steps and recursion depth per request? What stops a fan-out?
Cost observability. Does the system track cost per user and alert on anomalies, or would an attack only surface on the monthly invoice?
Extraction resistance. Is there monitoring for systematic, high-volume querying patterns consistent with model extraction?

A useful way to demonstrate the risk without causing harm is a simulated-cost harness: a test agent that counts the model and tool calls a request would make and multiplies by a per-call price, so you can show “this one query fans out to 200 calls, about $10” without actually spending it.

# Illustrative: measure fan-out and simulated cost, not a live attack
COST_PER_CALL = 0.05  # example price per model/tool call

def run_agent(query, call_budget, max_depth):
    calls = 0
    def step(task, depth):
        nonlocal calls
        if depth > max_depth or calls >= call_budget:
            return "[stopped: limit reached]"      # the guardrail that must exist
        calls += 1
        for subtask in plan_subtasks(task):         # may branch — this is the fan-out
            step(subtask, depth + 1)
    step(query, 0)
    return calls, calls * COST_PER_CALL

# Undefended: call_budget huge, max_depth huge -> cost grows without bound
# Defended:   call_budget=10, depth=2, with alerting on the stop condition

The point of the harness is the stop condition. An agent without one has no natural limit; an agent with a budget and a depth cap fails safely and loudly.

Defense: Architecture, Not Filtering

OWASP’s own guidance for Unbounded Consumption points at architecture. Content filtering does not help here, because the requests can be entirely legitimate in content; it is their volume and cost that are the problem. The controls that work:

Budgets and spending caps. Set hard cost limits per user, per key and per time window at the application layer, and configure spend alerts and limits with the model provider as a backstop.
Rate limits and quotas. Enforce request and token quotas server-side, per user, key and IP, covering every entry point including unauthenticated ones.
Input and output limits. Cap prompt size, document size, conversation history and max_tokens. Never trust a client-supplied limit.
Agent step, depth and call budgets. Give every agent a hard ceiling on tool calls, reasoning steps and recursion depth per request, and make exceeding it a logged, alertable event.
Circuit breakers and timeouts. Stop a request that exceeds its time or call budget rather than letting it run. Fail fast.
Least privilege for agents. The fewer tools and the less reach an agent has, the smaller the blast radius of a fan-out. This is the same principle as Excessive Agency.
Cost and behavior monitoring. Track cost and call volume per user in real time, alert on anomalies, and watch for the systematic query patterns that indicate model extraction.
Patch the serving stack. Keep inference servers and frameworks updated; resource-exhaustion bugs at the infrastructure layer are a separate path to the same outcome.

The guiding idea mirrors the rest of this series: you cannot rely on the model, or the user, to be reasonable. You design the system so that an unreasonable request stops at a boundary you control.

Conclusion

Unbounded Consumption is the LLM risk that shows up on the finance dashboard before the security one. It does not need a jailbreak or a data leak; it only needs an application that never says “that’s enough.” As agents gain the ability to call tools and other models in loops, a single request can expand into an unbounded workload, and usage-based pricing turns that workload directly into cost. The defense is not a smarter filter but a firmer boundary: budgets, quotas, limits on tokens and agent steps, circuit breakers and monitoring that catches abuse in minutes rather than on the monthly invoice.

Running an AI feature with real usage costs or autonomous agents? Our AI & LLM Security Testing service safely tests rate limits, token and agent-step controls and extraction resistance, and our AI Security Training helps your team design these limits in from the start. Talk to our team.

References

Subscribe to our cyber security newsletter

Scroll to top