In November 2024, OWASP folded a new category into its Top 10 for LLM Applications: Unbounded Consumption (LLM10:2025), merging what had previously been listed separately as model denial-of-service and model theft. The change reflects a shift in how attackers hit generative AI systems — not by breaking authentication or injecting malicious prompts to leak secrets, but by simply asking the model to do more work than anyone budgeted for. A single crafted request against a 128,000-token context window, a recursive multi-turn prompt chain, or a burst of parallel API calls can consume gigabytes of GPU memory, tie up an inference queue for minutes, and generate a cloud bill that spikes overnight. Security teams that spent 2023 and 2024 hardening against prompt injection are now discovering the same LLM endpoints are wide open to resource-exhaustion abuse. This post breaks down how unbounded consumption attacks work, why token-based pricing makes them uniquely expensive, and what controls actually stop them.
What Is an LLM Unbounded Consumption Attack?
An LLM unbounded consumption attack is any technique that forces a model or its serving infrastructure to consume far more compute, memory, or API quota than a legitimate request would need, degrading service quality or inflating operating cost. OWASP formalized this as LLM10:2025 in the November 18, 2024 release of the OWASP Top 10 for LLM Applications, combining the old LLM04:2023 "Model Denial of Service" entry with LLM10:2023 "Model Theft" into a single risk category. The reasoning: both problems stem from the same root cause — the absence of limits on how much of a model's resources any single caller can claim.
In practice this shows up as variable-length input flooding (submitting thousands of maximally long prompts per minute), unbounded output generation (requesting the maximum max_tokens value on every call), continuous context growth in multi-turn chat sessions, and batch or agentic workflows that fan out dozens of concurrent model calls with no ceiling. A production example: an API key configured with no request cap that fires 500 completions per minute, each asking for a 4,096-token response, will saturate a shared inference pool far faster than any equivalent number of simple, capped requests — and most teams only notice after the GPU queue backs up or the invoice arrives.
How Does "Denial of Wallet" Differ From Traditional Denial of Service?
Denial of wallet targets the billing model instead of uptime — the attacker doesn't need to crash the service, only make it expensive enough that the cost becomes untenable. Traditional DoS floods a server with connections until it falls over; because commercial LLM APIs bill per token, an attacker can achieve the same disruptive effect purely through cost, while the service stays technically "up." The term itself predates LLMs — cloud security researchers used it around 2018–2019 to describe attacks against serverless functions billed per invocation — but token-metered inference makes the economics far more attacker-friendly.
Consider representative 2024 API pricing: GPT-4 Turbo priced around $10 per million input tokens and $30 per million output tokens, and Claude 3 Opus around $15 and $75 per million tokens respectively. A script issuing 1,000 requests per hour, each pulling the maximum 4,096-token output, adds roughly $120–$300 an hour in output cost alone at those rates — before counting input tokens, retries, or concurrent sessions. Left unthrottled overnight, that scales to a five-figure bill by morning, and because the traffic looks like "normal" API usage rather than a malformed packet flood, standard network-layer DoS protections never fire.
What Are Sponge Examples and Why Do They Matter?
Sponge examples are inputs deliberately engineered to maximize a model's energy and latency consumption per inference, a concept introduced by Shumailov et al. in their 2020 paper "Sponge Examples: Energy-Latency Attacks on Neural Networks," later published at IEEE EuroS&P 2021. Their research showed that carefully crafted inputs could inflate inference time by as much as 200x on certain NLP and vision models without changing what task the input appeared to request — the model was "soaking up" disproportionate compute for ordinary-looking work.
In transformer-based LLMs the same principle applies through different mechanics: inputs that push the model toward its maximum generation length, repeated or adversarial token sequences that increase the number of autoregressive decoding steps, or prompts that trigger extensive chain-of-thought reasoning all act as sponges. A request that would normally return in 200–400 milliseconds can be manipulated into holding an inference worker for 20–30 seconds or more. At scale, even a modest number of sponge requests mixed into normal traffic is enough to starve a shared GPU pool and produce cascading latency for every other user on the same endpoint — which is precisely why sponge-style behavior is treated as a resource-exhaustion vector, not just a curiosity.
How Do Unbounded Context Windows Amplify the Risk?
Growing context windows amplify unbounded consumption because attention computation in standard transformer architectures scales roughly quadratically with sequence length, so each additional token multiplies the compute cost of the request. Context windows have expanded fast: GPT-4 Turbo supports 128,000 tokens, Anthropic's Claude models support up to 200,000 tokens in general availability with extended 1,000,000-token context introduced in 2025, and Google's Gemini 1.5 Pro supports context windows up to 2 million tokens. Each of those numbers represents a larger surface an attacker can fill.
A common real-world exposure is a retrieval-augmented generation (RAG) pipeline that concatenates retrieved documents into the prompt without an enforced cap. An attacker uploads a 500-page PDF and asks the system to "summarize every page in exhaustive detail," simultaneously maxing out the input context and the requested output length in a single call. Multiply that by a handful of concurrent sessions and a system designed to comfortably serve thousands of ordinary queries per hour can be reduced to a crawl by a single motivated user with no special access — just an oversized file and a permissive upload field.
What Does an Unbounded Consumption Attack Look Like in Practice?
In practice, unbounded consumption typically starts with an endpoint that has authentication but no resource governance: a public-facing chatbot or agentic tool where any authenticated user can open unlimited sessions, request unlimited output length, and chain unlimited multi-turn context. An attacker scripts 50 concurrent sessions, each instructing the model to "write an exhaustive, extremely detailed answer, then keep expanding on it" across repeated turns — a pattern that compounds, because each new turn re-sends the growing conversation history as input context on top of a new maximum-length output request.
Agentic and tool-calling systems add a second failure mode: a loop with no iteration cap. This mirrors the runaway-loop incidents reported around early autonomous-agent frameworks in 2023, where an agent given a goal but no hard step limit would call itself, call external tools, and re-prompt the model dozens or hundreds of times chasing an unreachable objective, burning tokens the entire time. In both cases the symptoms are the same: inference queue depth climbs, legitimate users see request latency jump from sub-second to 30+ seconds or outright timeouts, and the token-billing dashboard shows a spike disconnected from any corresponding increase in real user traffic.
How Can Teams Detect and Prevent Unbounded Consumption?
Teams stop unbounded consumption with layered controls, because no single setting closes every vector. OWASP's guidance for LLM10:2025 centers on five categories of mitigation: strict input validation and size limits, hard caps on resource allocation per request and per user, rate limiting and quota enforcement at the API gateway, continuous monitoring for anomalous usage patterns, and sandboxing or timeout enforcement around inference execution.
Concretely, that translates to enforcing max_tokens ceilings on every completion call rather than leaving it to defaults, capping input document size before it ever reaches the prompt template, setting per-API-key and per-user request quotas with automatic throttling, adding hard timeouts on individual inference calls so a sponge-style request can't hold a worker indefinitely, capping agent/tool-call iteration counts in orchestration frameworks like LangChain or custom agent loops, and wiring cost-anomaly alerts directly to cloud billing APIs so a spend spike triggers a page before the invoice does. None of these controls are exotic — they're the same discipline applied to any metered, multi-tenant service — but they're frequently missing from LLM integrations built quickly on top of a vendor SDK's defaults.
How Safeguard Helps
Safeguard approaches unbounded consumption as a supply chain problem as much as a runtime one: the missing rate limit, the uncapped max_tokens call, and the vulnerable orchestration dependency are all things that get committed to a repository long before an attacker ever sends a request. Safeguard's platform scans application code and infrastructure-as-config for exactly these gaps — LLM API calls without enforced token or timeout limits, agent frameworks configured without iteration caps, and API gateway or IaC definitions that expose LLM endpoints without per-key rate limiting — and flags them in CI/CD before the code ships.
Because unbounded consumption is often introduced through third-party components (an outdated LangChain version with a known unbounded-loop issue, a RAG library that concatenates documents without size checks, an SDK default that sets no output cap), Safeguard's software composition analysis and SBOM generation for AI/ML dependencies give teams visibility into which libraries in their LLM stack carry this class of risk, so it can be tracked and remediated the same way any other vulnerable dependency is. Combined with policy-as-code checks that gate merges on the presence of resource limits for AI-facing endpoints, and continuous monitoring integrations that surface cost and latency anomalies tied back to the responsible service, Safeguard closes the loop between the OWASP LLM10:2025 guidance and the actual pull request where the missing control needs to land — turning "we should rate-limit that" into an enforced, auditable gate rather than a postmortem action item.