OWASP LLM10 Unbounded Consumption Guide

Every call to a large language model costs compute and money, and an application that lets anyone make unlimited calls of unlimited size has handed its budget, its availability and its model behaviour to whoever finds the endpoint. LLM10:2025 Unbounded Consumption is the OWASP Top 10 for LLM Applications entry for this problem. OWASP describes it as expanding on what was previously Denial of Service, and it now covers three harms that share one root cause: denial of service, denial of wallet, and model extraction or replication through the inference API. This guide turns the OWASP text into enforceable limits, explains why the credential that calls the model is part of the control, and shows how to test and evidence it. It is written for AI platform engineers, API and application security teams, FinOps owners and assessors.

Key takeaways

Cost is an attack surface. OWASP names Denial of Wallet as a distinct example: under pay-per-use pricing, an attacker does not need to break anything to cause harm, only to keep the meter running.
Limit in tokens, not just requests. One request can carry a full context window and ask for thousands of output tokens, so request counts alone say little about load or spend.
Every limit needs an identity to hang on. Quotas only work when each caller (user, tenant, service or agent) authenticates with its own credential; a shared provider key turns every limit into one shared bucket.
Extraction looks like heavy legitimate use. Model replication and side-channel attacks run through the normal API, so exposure of logprobs and logit bias, plus query pattern monitoring, matter as much as rate limits.
Spend and usage telemetry are security signals. In the Sourcegraph and LLMjacking cases, a spike in API usage or cost was the first visible sign of abuse.

What it is and who it applies to

OWASP defines the risk as occurring when an LLM application "allows users to conduct excessive and uncontrolled inferences", leading to denial of service, economic losses, model theft and service degradation. The underlying weakness is the classic MITRE CWE-400 Uncontrolled Resource Consumption, made sharper by two properties of LLMs: inference is expensive and its cost scales with input and output length, and the model's outputs are themselves valuable enough to steal.

It applies to any system that exposes inference to someone you do not fully control: public chatbots, customer-facing copilots, internal assistants reachable by every employee, partner APIs that wrap a model, agents that loop on tool calls, and self-hosted models where the cost is GPU time rather than an invoice. It also applies to the credentials that pay for inference. A stolen provider key is unbounded consumption by someone outside your application entirely, which is why this guide is read alongside the LLMjacking Guide.

LLM10 is the LLM-specific form of API4:2023 Unrestricted Resource Consumption, and OWASP lists that entry among its related frameworks. Everything in the OWASP API Top 10 API4 Unrestricted Resource Consumption Guide (execution timeouts, payload size, spending limits on third-party services) applies to the API in front of the model; LLM10 adds tokens, context windows and model extraction. For where it sits in the full list, see the OWASP Top 10 for LLM Applications Guide.

Structure and key requirements

OWASP gives seven common examples of the vulnerability. They fall into three harm groups, and each group needs a different primary control.

OWASP example	Harm group	What the attacker exploits	Primary control
Variable-length input flood	Availability	Many inputs of different lengths that exploit processing inefficiencies	Input size limits, per-caller rate limits, queue caps
Denial of Wallet (DoW)	Cost	The cost-per-use model of hosted AI services	Token quotas per identity, budget caps, hard spend limits
Continuous input overflow	Availability	Inputs that keep exceeding the context window	Reject or truncate oversize input before it reaches the model
Resource-intensive queries	Availability and cost	Prompts that drive long or complex generation	Output token caps, timeouts, throttling of expensive operations
Model extraction via API	Intellectual property	Crafted queries, sometimes with prompt injection, to build a shadow model	Limit logits and logprobs exposure, extraction-pattern monitoring
Functional model replication	Intellectual property	Using outputs as synthetic training data to fine-tune another model	Volume limits per identity, watermarking, terms enforcement
Side-channel attacks	Intellectual property	Input filtering behaviour, to harvest weights and architecture information	Sandbox the LLM's network access, restrict response detail

OWASP lists 15 prevention and mitigation strategies. In practice they form five layers:

Admission: input validation against size limits; access controls with RBAC and least privilege.
Metering: rate limiting and user quotas per source entity; limits on queued and total actions.
Execution: timeouts and throttling for resource-intensive operations; dynamic resource allocation so no single user or request monopolises capacity; graceful degradation under load.
Response: restricting or obfuscating logit_bias and logprobs; glitch token filtering; watermarking outputs; sandboxing the model's access to networks and internal services.
Governance: comprehensive logging, monitoring and anomaly detection; a centralised ML model inventory; automated MLOps deployment with approval workflows; adversarial robustness training.

Model extraction is not theoretical. Carlini and colleagues (arXiv 2403.06634, "Stealing Part of a Production Language Model") recovered the full embedding projection layer of OpenAI's Ada and Babbage models for under 20 US dollars in queries, recovered the hidden dimension of gpt-3.5-turbo, and estimated under 2,000 US dollars to recover its full projection matrix. That attack used ordinary API access, which is why OWASP puts response detail and query volume in the same risk as cost.

Limits that actually bound consumption

Major providers meter in several dimensions at once, and an application should mirror them at its own boundary so it fails safely before the provider does.

Limit	What it bounds	Provider behaviour to know	Where to set it in your stack
Requests per minute (RPM)	Call rate	Azure OpenAI evaluates RPM over short windows of 1 or 10 seconds, so bursts are throttled even under the per-minute total	Gateway, per identity and per tenant
Tokens per minute (TPM) and per day (TPD)	Compute and spend	OpenAI and Azure OpenAI count the larger of `max_tokens` and the estimated tokens from request size, not the billed tokens	Gateway, per identity; set `max_tokens` close to the real need
Input size	Context abuse	Oversize prompts consume quota and memory even when rejected later	Application, before tokenisation where possible
Output size	Generation cost	Output tokens usually cost more than input tokens	Request parameter, enforced server-side
Concurrency and queue depth	Capacity	Queued work still holds memory and connections	Worker pool, queue
Agent loop budget	Recursive tool calls	Each step of an agent loop is a new inference	Agent runtime: maximum steps, total tokens per task
Spend limit	Money	OpenAI distinguishes spend alerts (notify only) from hard spend limits (requests return HTTP 429)	Provider account and cloud budget

Provider response headers such as x-ratelimit-remaining-tokens, x-ratelimit-reset-requests and, on Azure OpenAI, retry-after-ms let the gateway back off cleanly. Microsoft notes that unsuccessful requests still count toward the per-minute limit, so clients that retry without backoff make throttling worse. For the API-layer mechanics (token bucket, sliding window, 429 handling), see the Rate Limiting and API Abuse Guide.

Identity and NHI requirements

A rate limit is only as fine-grained as the identity it is keyed on. Most real LLM10 failures trace back to identity design rather than missing throttles.

One credential per consumer: each application, tenant, service account and agent should authenticate to your AI gateway with its own identity, and only the gateway should hold the provider key. Quotas, budgets and kill switches then apply per consumer. See the AI Gateway and LLM Gateway Guide.
Provider keys are spending authority: a model provider key is a non-human credential that can spend money without limit unless the account caps it. Keep it in a vault, scope it to one project, and rotate it. LLMjacking research reported by Sysdig estimated potential costs to victims of over 46,000 US dollars per day in May 2024, rising to over 100,000 US dollars per day in September 2024 for higher-tier models; see the LLMjacking 2024 to 2026 breach page.
Admin and quota-setting rights are privileged: in the Sourcegraph incident of August 2023, a site-admin access token committed to code on 14 July was used on 30 August to elevate an attacker account, which then raised API rate limits for selected users and fed a proxy app that gave others access to Sourcegraph's APIs and the underlying LLM. The control that bounds consumption was itself reachable through a leaked NHI.
Prefer federated workload identity: on cloud platforms, call hosted models with roles or workload identity federation instead of static keys, so there is no long-lived secret to scrape. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
Agents need budgets as well as permissions: an agent identity should carry a step limit and a token budget per task, enforced by the runtime, not by instructions in the prompt. See the Denial-of-Wallet and AI Agent Cost Runaway Guide.
Never ship provider keys in clients: a key in a mobile app or browser bundle is public, and anyone holding it bypasses every limit your backend enforces. The Microsoft Azure OpenAI Abuse 2025 case involved customer credentials scraped from public sources and resold as a service.

Implementation steps

Inventory inference paths. List every model endpoint, provider account, project and key, and every application, agent and user group that calls them. OWASP's centralised model inventory recommendation starts here.
Put a gateway in front. Route all inference through one control point that authenticates callers with their own identities, holds provider credentials, and records identity, model, input tokens and output tokens per request.
Set baselines in monitor mode. Run for two to four weeks logging consumption per identity, per tenant and per feature. Use the 95th and 99th percentile of real usage to size limits rather than guessing.
Enforce admission limits. Reject inputs over a defined character or token size, cap max_tokens per route, and set request timeouts. Start with the most expensive routes and models.
Enforce per-identity quotas. Apply RPM and TPM per identity and per tenant, daily token budgets, and concurrency caps. Return HTTP 429 with a Retry-After header so well-behaved clients back off.
Cap spend at the account level. Configure provider hard limits and cloud budgets with alerts at staged thresholds (for example 50, 80 and 100 percent), and decide in advance who can raise them.
Reduce response detail. Disable or restrict logprobs, top_logprobs and logit_bias for callers who do not need them, especially external ones.
Bound agents. Set maximum steps, maximum tool calls and maximum tokens per task in the agent runtime, plus a global kill switch per agent identity.
Design degradation. Define what happens under load: smaller model fallback, cached answers, queueing with a ceiling, or a clear "try later" message.
Turn on logging and detection. Enable provider-side invocation logs (for example, Amazon Bedrock model invocation logging is disabled by default) and alert on the signals in the next section.

Rollback: deploy limits behind feature flags per route and per tenant, start with soft limits that log and alert, and keep a documented override for incidents. If a limit blocks legitimate traffic, raise that identity's quota rather than removing the control for everyone.

Choosing where to enforce

Option	Strengths	Weaknesses	Best fit
Provider limits only	No build effort; hard spend limits stop the bill	Shared across all your callers; one abuser exhausts everyone's quota	Prototypes, single internal app
Application code	Knows the user and feature context	Duplicated across apps, easy to miss on new routes	Small organisations with one product
AI or API gateway	One policy point, per-identity quotas, central logs, holds provider keys	Another component to run and secure	Any organisation with several apps, tenants or agents
Self-hosted serving layer	Controls GPU scheduling, batch size and memory directly	Needs specialist tuning; no provider spend cap	Self-hosted models; see the Self-Hosted LLM Security Guide

Small teams can start with provider hard limits plus input and output caps in code. Larger organisations, and anyone exposing models to customers or running agents, need the gateway layer because per-identity metering is impossible without it.

Evidence and assessment

What to log and monitor

Per-request record: caller identity, tenant, model, input tokens, output tokens, latency, status (including 429s) and route. The Bedrock invocation log, for example, records the calling role ARN and input and output token counts.
Cost anomalies: daily spend per identity against its baseline; first use of a new model or region by an identity.
Abuse signals: sustained near-limit usage, many identities from one source, repeated maximum-length inputs, high 429 rates from one client.
Extraction signals: systematic, low-diversity queries at high volume, heavy use of logprob or logit parameters, and outputs harvested in bulk by a single API identity.
Control changes: quota raises, spend limit changes, new keys and disabled logging, all treated as privileged events.

Metrics

Coverage: percentage of inference traffic passing through the gateway with a per-identity quota (target 100 percent).
Shared credential count: number of provider keys used by more than one application or held outside the vault (target zero).
Cost per identity variance: number of identities exceeding 3 times their 30-day baseline per week, and mean time to triage.
Time to contain: minutes from cost or usage alert to key revocation or quota cut.
Load test result: service availability for legitimate users while an abusive identity is at its limit.

How to test

Assessors should run, in a non-production environment with its own budget: an oversize input test; a burst test from one identity; a multi-identity test from one tenant; an agent loop that never terminates; and a request for logprobs from an external client. The pass condition in each case is that the limit triggers, the event is logged with the right identity, and other users are unaffected. Retain gateway configuration exports, limit change history and test results as evidence.

Mapping to other frameworks

Framework	Reference	Relevance to LLM10
MITRE ATLAS	AML.T0029 Denial of AI Service	Availability attacks on inference
MITRE ATLAS	AML.T0034 Cost Harvesting	Driving up the victim's cost of running AI services
MITRE ATLAS	AML.T0024 Exfiltration via AI Inference API; AML.T0040 AI Model Inference API Access	Model extraction and replication through the API
MITRE ATT&CK	T1496.004 Cloud Service Hijacking	Stolen credentials used to consume hosted services at the victim's expense
OWASP API Security Top 10 2023	API4:2023 Unrestricted Resource Consumption	Same weakness at the API layer
MITRE CWE	CWE-400 Uncontrolled Resource Consumption	Root weakness named by OWASP
NIST SP 800-53 Rev. 5	SC-5 Denial-of-service Protection; SI-10 Information Input Validation; AC-6 Least Privilege; AU-6 Audit Record Review, Analysis, and Reporting	Availability, input size limits, scoped access, usage review
NIST CSF 2.0	PR.AA-05; DE.CM-01; ID.AM-02	Least-privilege access, monitoring, inventory of AI services
ISO/IEC 27001:2022 Annex A	A.8.6 Capacity management; A.8.16 Monitoring activities	Resource use planning and anomaly monitoring
CIS Controls v8.1	Control 16 Application Software Security; Control 8 Audit Log Management	Secure design of the application and retained usage logs

Common pitfalls

Request-only rate limits: limiting calls per minute while allowing maximum context and unlimited max_tokens lets one caller consume a large share of capacity in a handful of requests.
One provider key for everything: all applications share a key, so the provider limit is one bucket, nobody can tell who spent what, and revoking the key in an incident takes every service down.
Spend alerts without spend limits: an alert that arrives overnight does not stop a bill. LLMjacking victims typically learned of abuse from the invoice; see the LLMjacking 2024 to 2026 case.
Quota controls reachable by a leaked token: as at Sourcegraph, the ability to raise limits was held by an admin token that ended up in code. Treat quota administration as privileged access and scan for its tokens.
Unbounded agents: agents that retry failed tool calls or re-plan forever, with no step or token ceiling, generate cost without any attacker involved.
Full response detail to everyone: exposing logprobs and logit_bias to anonymous callers makes extraction cheaper with no product benefit.

Practitioner checklist

Inventory every model endpoint, provider account, key and consumer, and record an owner for each.
Route all inference through a gateway that authenticates each consumer with its own identity and holds provider keys.
Cap input size, max_tokens and request time on every route.
Enforce RPM, TPM and daily token budgets per identity and per tenant, returning 429 with Retry-After.
Set hard spend limits and staged budget alerts at provider and cloud account level.
Restrict logprobs and logit_bias to callers that need them.
Give every agent a step limit, token budget and kill switch enforced by the runtime.
Enable invocation logging and alert on cost anomalies, new model use and quota or logging changes.
Run abuse, burst and runaway-agent tests each release and keep the results as evidence.

OWASP LLM Top 10 LLM10 Unbounded Consumption Guide: Limiting Cost, Abuse and Model Extraction