LLM10 unbounded consumption: controls that work and ones that do not

OWASP LLM10, unbounded consumption, happens when an application lets users run excessive, uncontrolled inference. The result can be service denial, runaway bills, degraded service or model theft. Controls that work cap work per user and per request. Controls that only obscure the endpoint do not.

What does OWASP include under LLM10?

OWASP lists variable length input floods, "denial of wallet" (driving up pay per use costs), continuous input overflow beyond the context window, resource intensive queries, model extraction through the API, functional model replication using synthetic data, and side channel attacks. The shared cause is that nothing bounds how much inference one party can consume.

So the question for each control is: does it bound consumption, or does it merely hope nobody tries?

Controls that work

These come from OWASP's mitigation list and work because they set a hard limit.

• Input validation with size limits. Reject inputs beyond a reasonable length before they reach the model.
• Rate limiting and user quotas. Cap requests per identity per time window, and cap total spend per identity per month.
• Timeouts and throttling. Stop long running generations and slow down expensive operations.
• Resource allocation management. Prevent any single user or request from taking a disproportionate share.
• Limits on queued and total actions. In agent systems, cap the number of steps and tool calls in one task.
• Sandboxing. Restrict the model's access to network resources, internal services and APIs.
• Graceful degradation. Keep partial service under load rather than failing completely.
• Logging, monitoring and anomaly detection. Watch consumption per user, per key and per feature.
• Limited exposure of logits and logprobs. Return only what clients need.
• Access controls and a model inventory. Use least privilege for model repositories and a central registry of production models.

Add one from outside the list that most teams need: a hard budget alarm and a kill switch at the account level with your model provider.

Controls that do not work on their own

A secret endpoint. Obscurity does not bound anything. Once found, the endpoint is open to unlimited use.

A per IP limit alone. Distributed callers and shared corporate addresses defeat it. Limit by authenticated identity and add network level limits as a second layer.

A monthly bill review. It finds the problem after the money has gone. Use alerts that fire in hours.

A longer context window as a fix. More room per request can raise cost per abuse.

Trusting the client to limit itself. Enforce every limit server side.

Watermarking alone. OWASP lists it as a mitigation for detecting unauthorized use of outputs. It helps with attribution, but it does not stop consumption.

A short worked example

Suppose a support chatbot lets anonymous visitors ask anything. The weak design: no login, no limits, a large model, and a bill that arrives monthly. The bounded design: sign in or a signed session token, a maximum input size, a cap on output length, a per session request budget, a cheaper model for first pass triage, and a daily spend alarm. Nothing clever, but each item sets a ceiling.

What to do

1. Put a maximum on input size, output size and steps per task, server side.
2. Rate limit and set a spend quota per authenticated identity.
3. Set provider side budget alerts and know how to cut access quickly.
4. Log tokens in and out per user, feature and key, and alert on spikes.
5. Restrict what the model can reach on the network and which tools it may call.
6. Test the limits: simulate a flood in staging and confirm what breaks first.
7. Keep a model inventory so you know what is exposed and who owns it.

Quick check

Sources

• OWASP Top 10 for LLM Applications, LLM10:2025 Unbounded Consumption

Last reviewed: 18 October 2026.