What is OWASP LLM10 unbounded consumption? A worked example

OWASP LLM10:2025, Unbounded Consumption, is the risk that an LLM application lets users run excessive and uncontrolled inferences. The result can be denial of service, financial loss, model theft or degraded service. The fix is limits: on input size, request rate, processing time and spend, plus monitoring.

What does OWASP say it covers?

OWASP lists seven vulnerability types under LLM10: variable length input floods, denial of wallet, continuous input overflow, resource intensive queries, model extraction through the API, functional model replication and side channel attacks. It notes that LLMs are costly to run, especially in the cloud, which makes them attractive targets for resource abuse.

What does it look like in practice?

The following is a constructed scenario, not a report of a real incident, modeled on the OWASP categories. A small company ships a support chatbot on a pay per token model API. The widget needs no login. There is no rate limit and no cap on message length.

Someone writes a script that sends long messages in a loop, asking for long answers. Nothing is hacked. Each request is valid. But the token meter runs all night, and the company finds a large bill and a chatbot that is slow for real customers. That is denial of wallet, joined to plain service degradation.

A second pattern is quieter. An attacker sends many varied queries and records the answers, then trains a cheaper model on them. OWASP calls this functional model replication, and it relates to model extraction through the API. No single request looks odd, which is why usage monitoring matters.

Which controls does OWASP recommend?

OWASP groups its mitigations like this:

• Input validation with size limits, and restricted exposure of logits and logprobs.
• Rate limiting, user quotas and dynamic resource allocation.
• Timeouts and throttling for expensive operations, limited queued actions, and graceful degradation.
• Scaling and load balancing.
• Sandboxing, so the model cannot reach internal services or networks it does not need.
• Logging of resource use with anomaly detection.
• Watermarking, adversarial robustness training and glitch token filtering to protect the model.
• Role based access, least privilege, a central model inventory and approval workflows for deployment.

How does this apply to AI agents?

Agents make this worse because one user request can trigger many model calls and tool calls. A loop where an agent retries a failing step can burn budget with no attacker at all. Cap steps per task, tokens per task and spend per user, and fail closed when a cap is hit.

What to do

1. Require authentication, or at minimum per IP limits, on every endpoint that calls a model.
2. Set a maximum input size and a maximum output length.
3. Add per user and per tenant quotas, with a hard monthly spend cap at the provider.
4. Set timeouts and a maximum number of agent steps per request.
5. Alert on spend per hour and on unusual request patterns, not just on errors.
6. Do not return token probabilities unless a feature needs them.
7. Keep an inventory of which models and keys each service uses, and rotate keys that leak.
8. Test with a load script that sends oversized inputs against staging, and watch what degrades first.

Quick check

Sources

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

Last reviewed: 18 October 2026.