Unbounded Consumption (LLM10): AI agent DoS and costs

What is Unbounded Consumption (LLM10:2025)?

It is the category of the OWASP Top 10 for LLM Applications 2025 that groups resource-consumption abuse. It replaces and widens the former model denial-of-service risk. OWASP lists seven vulnerability types:

1. Variable-Length Input Flood: overloading the system with inputs of varying sizes.
2. Denial of Wallet (DoW): driving costs up through a high volume of operations on a pay-per-use service.
3. Continuous Input Overflow: repeatedly sending inputs that exceed the context window.
4. Resource-Intensive Queries: submitting requests that drain resources.
5. Model Extraction via API: replicating a partial or "shadow" model from targeted queries.
6. Functional Model Replication: using the model's outputs as synthetic data to train an equivalent.
7. Side-Channel Attacks: exploiting input filters to learn about the model.

For a company that consumes a model through an API, the first four are the most concrete: service availability and the bill. Model extraction mainly concerns those who expose a proprietary model.

Why does an AI agent multiply the risk?

Because a single request can trigger a chain of dozens of calls, whose cost the attacker does not pay. A chatbot answers once. An agent plans, calls tools, rereads the results and starts again.

The amplification mechanisms:

• Loops. The agent retries a failing action forever, or two agents hand the task back to each other.
• History resent at every step. With a stateless API, each call resends the whole context: the longer the run, the more each step costs.
• Bulky tool results. A tool that returns a whole web page or file swells the context.
• Fan-out. An agent that launches sub-agents or parallel calls multiplies spending.
• Paid downstream tools. Search, image generation, SMS or email sending, third-party API calls: the cost falls outside the model budget.
• Tasks triggered by third parties. A public form, an incoming email or a webhook starts the agent with no volume control.

That last case is the most dangerous: the attacker needs no account, only a way to trigger the agent. Our n8n webhook case study shows how an exposed entry point lets anyone launch workflows.

How does an attacker cause denial of service or a cost explosion?

By sending inputs designed to be expensive to process, or by making the agent loop through a poisoned document. The scenarios we test:

The first two are classic denial of service. The others exploit the agentic nature of the workload and are often combined with indirect prompt injection: the poisoned document orders the agent to loop. See prompt injection.

Which prevention measures does OWASP recommend?

Defense in depth across inputs, rate, time and monitoring. The LLM10:2025 page lists in particular:

• Input validation: reasonable size limits.
• Rate limiting and quotas per user.
• Resource allocation management so one user cannot consume everything.
• Timeouts and throttling to cap the time of costly operations.
• Sandboxing: restrict the LLM's access to the network, internal services and APIs.
• Logging, monitoring and anomaly detection of resource usage.
• Graceful degradation: keep partial service under heavy load.
• Limiting queued actions and scaling robustly.
• Limiting logits and logprobs exposure to slow extraction.

These points are generic. For an agent, they must be translated into ceilings specific to each run.

How do you cap an agent in practice?

By setting hard limits, enforced by the code around the model, at five levels. The model must never be the one deciding to stop.

1. Per run: maximum number of steps, tool calls, tokens consumed and total duration. Beyond that, stop and return an error.
2. Per tool: call quota and timeout for each tool, with a lower ceiling for paid or slow tools.
3. Per user and per customer: daily and monthly budget, maximum rate, number of concurrent runs.
4. Per entry point: authentication, rate limiting and a bounded queue on webhooks, forms and incoming email.
5. Globally: spending cap at the model provider, alerts at several thresholds and a circuit breaker that disables costly features.

A few more design rules:

• Detect loops: the same tool called with the same arguments several times in a row, or the same states recurring.
• Truncate or summarize tool outputs before putting them back in the context, with a maximum size.
• Limit the depth of sub-agents and parallelism.
• Pick a suitable model for each step: a small model for simple tasks cuts spending.
• Separate keys per application or customer, to isolate a runaway and cut it without stopping everything.

How do you test an agent's resistance to Unbounded Consumption?

With controlled loads, on a test environment or with a budget capped in advance, never in production without written approval. The goal is to find the missing limits without taking the service down.

1. Extreme inputs. Send a message of the maximum accepted size, then beyond, and watch the rejection.
2. Loop. Ask for an impossible or circular task and verify the agent stops at the step ceiling.
3. Huge tool output. Make a tool return a very large file or a very long page and watch the truncation.
4. Fan-out. Request a task that needs many sub-calls and measure the effective ceiling.
5. Quotas. Repeat requests from one account until the limit is hit, then verify it protects other customers.
6. Public entry point. Trigger a webhook or form repeatedly, at low volumes, and check that a quota exists.
7. Alert. Confirm that abnormal spending does raise an alert, and how quickly.

For each test, record the tokens, the calls and the estimated cost: that is the number that speaks to management. The consumption metrics recommended in our article on agent logging let you retrieve them.

What role for the human?

Beyond a spending or volume threshold, a run should ask for approval. An agent about to send thousands of emails or launch a long task is typically a high-level action. See which actions to approve.

How does CleanIssue assess this risk?

We map the entry points that trigger your agent, its paid tools and its ceilings, then test each limit with bounded loads. The Agent Red Team Express at €1,900 covers this area for one agent in 5 days, with the missing ceilings expressed in tokens and cost. Our approach is described on the method page, and the framework in the AI agent red teaming pillar. The first conversation is a free 30-minute discovery call.