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 service1. 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.
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 requests1. 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 services1.
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 costs1. 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 in2. 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 responsibility3. Treat provider caps as backstops, not as the primary control: they are coarse and they lag. LLM spend limits compared and Provider spend limits compared go into the differences.
Agents make this worse, because one user request can turn into dozens of model calls. Bounding 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 processing1. 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 429s 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 once1. Handling LLM rate limits and 429s and Circuit breakers and throttling for LLMs 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 equivalent1. 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 misuse4.
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 text1. How to stop your AI feature becoming someone's free LLM API covers the product side in detail, and What is an 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 model1. If that is a provider, your job is to choose providers whose security answers satisfy you; questions for an AI vendor security review 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 inventory1.
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 request5. 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); 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, 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 refuse unapproved models with 403 model_not_allowed; routes set per-attempt timeouts and at most three retries (routes); 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); and every request is in the request log 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).
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.