# OWASP LLM10 Unbounded Consumption, mapped to controls

URL: https://infro.io/blog/owasp-llm-unbounded-consumption
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> OWASP LLM10:2025 Unbounded Consumption is the risk that an LLM application lets users run excessive, uncontrolled inference, leading to denial of service, financial loss (denial of wallet), model theft through extraction or functional replication, and degraded service. Mitigate it in three layers: the application (identity, input and output limits, per-user quotas, purpose checks), the gateway (budgets and per-key limits checked before the provider call, model allowlists, timeouts, alerts) and the provider account (scoped keys, IP restrictions, provider spend caps, usage monitoring).

Key takeaways:
- LLM10 covers three different harms: cost (denial of wallet), theft of model behavior (extraction and functional replication), and availability (resource exhaustion).
- OWASP lists seven common examples and fifteen mitigations; most of the mitigations a typical API customer can apply are limits, quotas, timeouts and monitoring.
- Put each control where it can act: identity and purpose in the application, budgets and allowlists before the provider call, spend caps and key scoping at the provider.
- A rate limit is not a cost limit: long outputs and expensive models under the rate limit still run up a bill.
- Gateway controls do not cover a provider key used directly; provider-side caps and scoping are the backstop.

**What is OWASP LLM10 Unbounded Consumption?** It is the tenth risk in the OWASP Top 10 for LLM Applications 2025: an application that lets users run "excessive and uncontrolled inferences," which OWASP links to denial of service, financial losses, model theft and degraded service[1]. In practice it is three different problems under one heading: **cost** (denial of wallet), **theft of model behavior** (extraction and functional replication), and **availability** (resource exhaustion). Each is mitigated by limits placed at the right layer: the application, the gateway, and the provider account.

This guide summarizes what the OWASP entry says, then maps each example to controls at each layer. For the full OWASP Top 10 as it applies to a gateway, see [A threat model for an LLM gateway](https://infro.io/blog/llm-gateway-threat-model).

## What the entry says

OWASP's starting point is that inference is costly, especially in the cloud, and that an application without bounds on usage hands that cost and capacity to whoever sends requests[1]. It lists seven common examples:

| OWASP example | In plain terms | Family |
| --- | --- | --- |
| Variable-length input flood | Many inputs of varying length that exploit processing inefficiencies | Availability, cost |
| Denial of Wallet (DoW) | High volumes of operations against pay-per-use pricing | Cost |
| Continuous input overflow | Inputs that keep exceeding the context window | Availability, cost |
| Resource-intensive queries | Prompts built to be unusually demanding | Availability, cost |
| Model extraction via API | Crafted prompts to collect outputs and replicate part of a model | Theft |
| Functional model replication | Using outputs as synthetic training data to fine-tune an equivalent | Theft |
| Side-channel attacks | Probing input filtering to learn weights or architecture | Theft |

Its fifteen mitigations range from things any team can do (input validation, rate limiting, resource allocation management, timeouts and throttling, logging and anomaly detection, graceful degradation, limits on queued actions) to things only a model owner can do (adversarial robustness training, watermarking, glitch-token filtering, a model inventory and governed MLOps)[1]. Two sit in between: limiting exposure of logits and logprobs, and sandboxing the model's access to networks and internal services[1].

## Three layers, and what each can see

| Layer | Knows | Can enforce |
| --- | --- | --- |
| Application | Who the user is, what the feature is for, what a normal request looks like | Identity, input shape and size, output length, per-user quotas, purpose checks, sign-up friction |
| Gateway | Every request's key, project, end user, model, tokens and estimated cost, across providers | Budgets and caps before the provider call, per-key rate limits, model allowlists, timeouts, alerts |
| Provider account | All traffic on the account, including traffic that bypassed the gateway | Key scoping, IP restrictions, spend caps, revocation, usage reports |

The layers fail differently. The application cannot stop a stolen key; the gateway cannot see a key used directly at the provider; the provider cannot tell your users apart unless you tell it. That is why each scenario below gets a control at more than one layer.

## Denial of wallet

OWASP describes it as excessive operations that exploit pay-per-use pricing and create unsustainable costs[1]. The amount is set by four numbers: requests, input tokens, output tokens and the model's rate. An attacker who controls the prompt controls three of them.

| Layer | Controls |
| --- | --- |
| Application | Authenticate before any model call; cap spend or tokens per end user per period; set `max_tokens` to what the feature needs; fix the model on the server |
| Gateway | Hard budgets per organization, project, member and key, checked before the provider is called and counting requests in flight; per-end-user caps; model allowlists so the most expensive model is not reachable; alerts on a day that departs from normal |
| Provider | A spend cap on the project or workspace as the backstop; one key per workload so the damage is attributable |

OpenAI's guidance supports the application-layer part: limiting output tokens reduces the chance of misuse, and users should generally register and log in[2]. At the provider layer, Google added a monthly spend cap per project for the Gemini API, with a delay of about ten minutes during which overages remain the customer's responsibility[3]. Treat provider caps as backstops, not as the primary control: they are coarse and they lag. [LLM spend limits compared](https://infro.io/blog/llm-spend-limits-compared) and [Provider spend limits compared](https://infro.io/blog/provider-spend-limits-compared) go into the differences.

> **Example: Why a rate limit is not a cost limit**
> A feature allows 20 requests a minute per user and sets no output limit. A script stays under the rate limit and asks for the longest possible answer each time, on the best model the endpoint accepts. Over 24 hours that is 28,800 requests, each producing thousands of output tokens. Lowering `max_tokens` to what the feature needs, pinning a smaller model, and capping each user at a few dollars a day changes the worst case from open-ended to a known number per account.

Agents make this worse, because one user request can turn into dozens of model calls. [Bounding AI agent loops](https://infro.io/blog/bound-ai-agent-loops) covers step and spend limits per run.

## Resource exhaustion: floods, overflow and expensive queries

OWASP's scenarios here are an oversized input that consumes memory and CPU, a high volume of requests that leaves no capacity for legitimate users, and inputs crafted to trigger the most expensive processing[1]. With a hosted model, the provider absorbs the compute; what you lose is your own rate limits and quota, so a flood from one user turns into `429`s for every other user, and long requests tie up your workers.

| Layer | Controls |
| --- | --- |
| Application | Reject inputs above the size the feature would ever see; count tokens before sending; limit concurrent requests per user; queue with a cap and shed load gracefully |
| Gateway | Per-key rate limits; per-attempt timeouts; limited retries so a struggling provider is not hammered; per-end-user caps so one user cannot use the whole quota |
| Provider | Separate projects or workspaces per workload, so one workload's flood does not consume another's rate limits |

OWASP's graceful degradation mitigation is the one teams skip: decide in advance what the feature does when it is over budget or rate-limited (a shorter answer, a smaller model, a clear message) rather than failing every user at once[1]. [Handling LLM rate limits and 429s](https://infro.io/blog/llm-rate-limits-429-handling) and [Circuit breakers and throttling for LLMs](https://infro.io/blog/llm-circuit-breakers-throttling) cover the mechanics.

## Model extraction and functional replication

OWASP describes attackers gathering outputs through crafted prompts to replicate part of a model, and using outputs as synthetic training data to fine-tune a functional equivalent[1]. If you use a provider's model through its API, the provider's model is the provider's concern. Yours is twofold: your product can be the route by which someone harvests outputs at your expense, and a model you fine-tuned and expose can be replicated.

| Layer | Controls |
| --- | --- |
| Application | Narrow the feature to its purpose and refuse off-purpose prompts; do not return full reasoning or system prompts; do not expose logprobs unless the feature needs them; per-user quotas and sign-up friction against account farming |
| Gateway | Per-end-user caps; model allowlists; request records per key and end user to spot templated, round-the-clock or long-output patterns |
| Provider | Scoped keys and IP restrictions so a stolen key is less useful; per-key usage monitoring |

At the provider, IP restrictions are among the few controls that still work after a key leaks: OpenAI, for example, lets an organization or project accept requests only from listed IP ranges, rejecting others even with a valid key, while saying plainly that this reduces rather than eliminates misuse[4].

OWASP's "limit exposure of logits and logprobs" mitigation is directly actionable: an endpoint that returns token probabilities gives an extraction attempt far more signal than plain text[1]. [How to stop your AI feature becoming someone's free LLM API](https://infro.io/blog/ai-feature-abuse-free-llm-proxy) covers the product side in detail, and [What is an AI distillation attack](https://infro.io/blog/what-is-ai-distillation-attack) the technique.

## Side channels and the model-owner mitigations

Side-channel probing, watermarking, adversarial robustness training and glitch-token filtering sit with whoever trains and serves the model[1]. If that is a provider, your job is to choose providers whose security answers satisfy you; [questions for an AI vendor security review](https://infro.io/blog/ai-vendor-security-review-questions) helps. If you host open-weight models yourself, those mitigations become yours, along with OWASP's access controls on model repositories and a central model inventory[1].

## The scenarios at a glance

| OWASP scenario | First control | Backstop |
| --- | --- | --- |
| Uncontrolled input size | Application input limit | Gateway timeout |
| Repeated requests | Per-user and per-key rate limit | Per-user spend cap |
| Resource-intensive queries | Output limit and fixed model | Gateway budget |
| Denial of wallet | Per-user and per-key spend cap before the call | Provider spend cap |
| Functional model replication | Purpose checks and per-user quotas | Per-key usage monitoring |
| Bypassing system input filtering | Sandbox the model's network and tool access | Logging and review |

## Monitoring that makes the limits tunable

Limits set without data are either too tight or useless. Record per request the key, project, end user, model, input and output tokens and estimated cost, and alert on departures from each scope's normal day. At the provider, pull usage per key: Anthropic's Usage API, for example, reports tokens by API key, workspace and model in buckets as small as one minute, usually within five minutes of a request[5]. Compare the two; traffic the provider counts and your gateway never saw is either a misconfigured client or a key in someone else's hands.

## How INFRO addresses unbounded consumption

INFRO is a gateway in front of provider accounts you own. For traffic sent through it: hard budgets per organization, project, member and key are checked **before** the provider is called, counting the worst case of requests already in flight, and a request with no room is refused with `402` ([spend controls](https://infro.io/docs/org/spend-controls)); a request to a model with no known price is refused under a blocking budget by default rather than counted as free. [End-customer caps](https://infro.io/docs/org/end-customer-caps), from the Team plan, limit spend per end user of your product and return `402 end_user_budget` with a reset time. Gateway keys carry their own spend limits and rate limits and can be restricted to chosen providers and IP ranges; [model allowlists](https://infro.io/docs/org/model-allowlists) refuse unapproved models with `403 model_not_allowed`; routes set per-attempt timeouts and at most three retries ([routes](https://infro.io/docs/routes)); [guardrails](https://infro.io/docs/features/guardrails) on the Business plan apply pattern checks to prompts and responses; spend alerts flag a day that departs from a scope's usual day ([alerts](https://infro.io/docs/observability/alerts)); and every request is in the [request log](https://infro.io/docs/observability/traces) with its tokens and estimated provider cost.

What it does not cover: INFRO's controls govern traffic that goes through INFRO. A provider key stolen from anywhere, including from a platform that stores provider keys as INFRO does, can be used directly against the provider and bypasses every budget and allowlist above. For that path the controls are at the provider: scoped keys, IP restrictions, provider spend caps, revocation, and the provider's own usage reports. INFRO's reconciliation on the Business plan can, with usage access on, report traffic that reached your OpenAI or Anthropic account without passing through INFRO ([reconciliation](https://infro.io/docs/cost/reconciliation)).

## Summary

OWASP LLM10 is about inference nobody bounded: costs that grow without limit, outputs collected to copy a model, and capacity consumed by one caller. Bound it in three places. The application knows who the user is and what the feature is for; the gateway can refuse a request before the provider is called; the provider account is the backstop for everything that does not pass through the first two.

## Questions

### What is OWASP LLM10:2025?

Unbounded Consumption, the tenth risk in the OWASP Top 10 for LLM Applications 2025. It covers applications that let users run excessive and uncontrolled inference, leading to denial of service, financial loss, model theft and degraded service.

### What is denial of wallet in an LLM application?

OWASP's name for an attack that drives up cost rather than taking a service offline: high volumes of requests, or requests built to be expensive, against a pay-per-use model, until the bill becomes the damage.

### Is model extraction a risk if I only use a provider's API?

The provider's own model is the provider's problem, but your product can be the route: an unrestricted feature lets someone collect outputs at your expense, and a model you fine-tuned and expose can itself be replicated. Limit who can call it, how much, and avoid exposing logprobs you do not need.

### Do rate limits solve unbounded consumption?

They help with volume, which is one of OWASP's mitigations, but a rate limit does not bound cost. Combine rate limits with spend or token quotas per user and key, output length limits, timeouts and monitoring.

## Sources

1. LLM10:2025 Unbounded Consumption — OWASP Gen AI Security Project. https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/ (accessed 2026-10-21)
2. Safety best practices — OpenAI. https://developers.openai.com/api/docs/guides/safety-best-practices (accessed 2026-10-21)
3. Giving you more transparency and control over your Gemini API costs — Google. https://blog.google/innovation-and-ai/technology/developers-tools/more-control-over-gemini-api-costs/ (accessed 2026-10-21)
4. IP allowlisting for OpenAI API — OpenAI Help Center. https://help.openai.com/en/articles/20001201-ip-allowlisting-for-openai-api (accessed 2026-10-21)
5. Usage and Cost API — Anthropic. https://platform.claude.com/docs/en/api/usage-cost-api (accessed 2026-10-21)