Unbounded Consumption: Token Floods & Runaway AI Cost (LLM DoS)

June 25, 2026 · Securing AI: How AI Gets Attacked — and Defended (part 20)

▶ Watch on YouTube & subscribe to The Stack Underflow

The cheapest attack on your AI system is not an exploit, a jailbreak, or a stolen key. It is a request — thousands of them, or a single carefully crafted one, each cheap to send and expensive to serve. The cost meter spins whether or not the attacker gains any data. Somewhere between the input and the invoice, your availability is the asset at risk.

If you are building any public-facing LLM feature — a chat endpoint, an autonomous agent, a retrieval-augmented answer engine — this attack class can make your service unavailable, drain your monthly budget in hours, or both. In May 2026 researchers demonstrated token inflation attacks that inflated hidden token usage by an average of 1,469%, turning a $100 bill into roughly $1,569 without triggering any abuse filter (Sondera AI, May 2026). This is not theoretical.

The one-sentence version: Unbounded Consumption is what happens when an AI system places no hard limits on how much compute, memory, or money a single interaction can consume — making exhaustion, not exploitation, the attack.

What OWASP LLM10 actually covers

OWASP LLM Top 10 — 2025 edition is the industry’s canonical list of the ten most critical vulnerabilities in large language model applications. Entry LLM10:2025, Unbounded Consumption, was broadened from the older “Model Denial of Service” entry to explicitly include four distinct resource-exhaustion patterns that every developer needs to know:

The 2025 edition also names a fifth pattern: Denial of Wallet (DoW) — a deliberate financial attack on pay-per-use deployments. DoS targets your uptime; DoW targets your bank account. In practice, the same flood achieves both.

OWASP Agentic Top 10 (published 2025) reinforces the same concern at the agent layer, where runaway loops and unbudgeted tool chains create an additional cost-amplification surface that standard API-level rate limits do not cover.

The four flood types, drawn

ATTACKER
    │
    ├──[1] TOKEN FLOOD ──────────────────────────────────────────────►
    │       ░░░░░░░░░░░░ many cheap requests ░░░░░░░░░░░░             cost meter: ███████ SPIKE
    │
    ├──[2] RECURSIVE CONTEXT ────────────────────────────────────────►
    │       one request [ small ] → grows → [ m e d i u m ]
    │                              → grows →  [  L  A  R  G  E  ]    tokens/call: climbing
    │
    ├──[3] RUNAWAY AGENT LOOP ───────────────────────────────────────►
    │       agent → tool → agent → tool → agent → tool → (no exit)   meter: spinning freely
    │                  ^___________________________|
    │
    └──[4] MODEL EXTRACTION ─────────────────────────────────────────►
            query ──► output ──► harvest ──► synthesize shadow model  IP: draining
            query ──► output ──► harvest ─/
            query ──► output ──► harvest /

Each attack hits a different layer and requires a different cap. A rate limit stops pattern 1. An input-size cap stops pattern 2. A loop-depth limit stops pattern 3. Watermarking and output-rate controls slow pattern 4.

Why reasoning models make this worse

Large Reasoning Models (LRMs) — models that produce a chain-of-thought trace before answering — introduce a qualitatively new risk surface. In February 2026, researchers published ReasoningBomb (arXiv 2602.00154), a reinforcement-learning framework that generates short, benign-looking prompts (256 tokens) that induce pathologically long reasoning in the target model: an average of 19,263 reasoning tokens across tested LRMs, a 38% improvement over prior attacks. The paper tested ten commercial and open-source models including Claude 4.5, GPT-5, and Gemini 3. Under standard content filters, ReasoningBomb prompts were flagged only 0.2% of the time and achieved a 98.4% bypass rate against dual-stage defenses.

The economic asymmetry is stark: the user pays a fixed-rate subscription or per-request fee; the provider bears a variable cost that scales with reasoning trace length. An attacker exploiting a reasoning model is not just consuming tokens — they are invoking a compute-intensive internal monologue that your billing system may not even surface separately.

Sysdig researchers documented real-world cases as early as 2024 where victims were hit with tens of thousands of dollars in charges within three hours from a single burst of automated calls; separate operations exceeded $100,000 per day (Sysdig Threat Research, 2024). By early 2026 the attack had commercialized: stolen API access is resold through underground reverse proxies, with scanning now targeting exposed MCP (Model Context Protocol) endpoints, not just model APIs (OrcaRouter Threat Report 2026).

How to defend: bound every resource, fail closed

Defense here is not a single control — it is a layered stack of hard limits. The table below maps each flood type to its primary and secondary controls.

The single most important rule: fail closed, not open. When a cap is hit, the request or loop terminates. It does not degrade gracefully into an uncapped mode and it does not retry without a back-off policy. A fail-open rate limiter is not a rate limiter.

Concrete implementation checklist

INPUT LAYER
  [ ] max_tokens_per_request = hard limit, enforced before the call reaches the model
  [ ] input_size_bytes = reject oversized payloads at the API gateway, not the model
  [ ] rate_limit = requests/minute per authenticated key (not per IP alone)

EXECUTION LAYER
  [ ] output_token_cap = set stop criteria; never let the model self-determine length
  [ ] agent_loop_depth = maximum recursion / tool-call hops per session
  [ ] per_step_timeout = abort if a single tool call exceeds N seconds

BUDGET LAYER
  [ ] cost_budget_per_key = daily hard cap in USD/credits; triggers circuit breaker
  [ ] cost_budget_per_user = separate cap for multi-tenant systems
  [ ] billing_alert_threshold = alert at 50% and 80% of budget, not just at 100%

MONITORING LAYER
  [ ] latency_spike_alert = p99 latency deviation triggers investigation
  [ ] token_count_anomaly = flag requests that exceed 2x the typical token count
  [ ] output_rate_monitor = detect systematic query-harvest patterns

NIST AI RMF (AI Risk Management Framework, 2023) maps this squarely to the Measure and Manage functions: quantify resource usage baselines, set thresholds, and operate automated responses when thresholds are crossed. The companion NIST AI 600-1 Generative AI Profile (July 2024) adds availability and robustness as explicit trustworthiness properties that organizations must actively manage for generative AI deployments.

The EU AI Act, now fully enforceable for high-risk AI systems from 2 August 2026, requires robustness, accuracy, and cybersecurity controls for high-risk applications — availability attacks that make a system fail unpredictably directly implicate those requirements. Fines reach EUR 35 million or 7% of global annual turnover for the most serious infringements.

On the CIA triad for AI, unbounded consumption is the Availability attack: sponge attacks, energy-latency attacks, and token floods all aim at the same property — denying the system’s capacity to serve legitimate users.

Common misconceptions

• “Rate limiting solves this.” Rate limiting stops token floods (pattern 1), but it does nothing for a single malicious request that causes recursive context expansion or triggers a runaway agent loop. You need rate limits and per-request token caps and loop-depth limits. One control is not a stack.

• “My LLM provider handles this.” API providers implement their own service-level protections, but they protect their infrastructure, not your application budget. A provider throttle that triggers at 1,000 requests/minute still lets a single crafted prompt burn your monthly budget in one session. Cost caps and loop limits are your responsibility as the integrator.

• “This only matters at massive scale.” The Sysdig cases involved small to mid-sized API consumers. And the ReasoningBomb research showed that a single short prompt — indistinguishable from a legitimate user message — can generate nearly 20,000 reasoning tokens in one call. You do not need scale to be damaged; you need one attacker and one uncapped endpoint.

• “Model extraction is a separate category from DoS.” OWASP LLM10:2025 explicitly includes model extraction via excessive querying under Unbounded Consumption, not under LLM02 (Sensitive Information Disclosure). The extraction mechanism is resource exhaustion; the result is IP theft. Tag it as LLM10, and defend it with the same output-rate and anomaly controls that cap the other floods.

Frequently asked questions

What is “denial of wallet” and how is it different from denial of service? Denial of service (DoS) makes a system unavailable — requests time out, queues fill, legitimate users get errors. Denial of wallet (DoW) is the financial variant: the attacker does not need to take the service down; they just need to make it serve expensive requests until the API credit balance or monthly budget is exhausted. In pay-per-use deployments, the service may stay technically “up” while racking up costs that the operator must pay. Both attacks can be launched with the same request flood; the difference is which damage you measure.

Can reasoning models be exploited differently than standard LLMs? Yes, and more severely. Standard LLMs have roughly predictable input-output token ratios. Reasoning models produce a “thinking” trace before the answer, and that trace can be made pathologically long by specially crafted prompts. The ReasoningBomb paper (arXiv 2602.00154, February 2026) demonstrated average completion token counts of 18,759 from 256-token inputs. Standard rate limits, which count requests rather than compute, do not account for this amplification. You need reasoning-token budgets as a separate control if you expose reasoning models.

How do I set a meaningful cost budget if my usage is unpredictable? Start with your maximum acceptable monthly spend divided by 30 to get a daily ceiling. Set a per-key daily hard cap at a fraction of that ceiling (e.g., 10–20% for any single key). Set billing alerts at 50% and 80% of the daily budget, not only at the limit itself. Monitor the p99 cost per request over a rolling 24-hour window; a sudden increase in that metric often signals exploitation days before the budget is exhausted. Adjust caps upward as you build a baseline, not before.

Does this apply to internal-only AI tools? Partially. Internal tools are less likely to face external denial-of-wallet attacks, but runaway agent loops and expanding-context bugs are not attacker-dependent — they can be triggered by unusual but legitimate inputs, or by bugs in the agent’s stop-condition logic. The loop-depth limit and per-step timeout are engineering hygiene, not purely security controls, and they belong in every agent regardless of exposure.

What is the MCP connection to this attack? MCP (Model Context Protocol) servers extend agents with file system access, API calls, and other tools. A malicious or compromised MCP server can embed hidden instructions in tool responses that steer the agent into repetitive, expensive tool chains — a 2026 variant of the runaway loop attack. The OrcaRouter Threat Report 2026 documents active scanning of exposed MCP endpoints for this purpose. Apply the same loop-depth limits and cost budgets at the MCP orchestration layer, not only at the LLM API layer.

What does OWASP’s 2025 update actually change from the older “Model Denial of Service”? The older LLM04 “Model Denial of Service” entry focused narrowly on availability: making the model slow or unavailable. LLM10:2025 Unbounded Consumption broadens the scope to financial impact (denial of wallet), model extraction via excessive querying, and the cascading effects in multi-tenant environments where one user’s flood degrades service for others. It also explicitly calls out autonomous agent loops and recursive context expansion as distinct vectors. The rename signals that the threat is resource governance, not just uptime protection.

Where this fits in the series

Unbounded Consumption sits at Stage 4: Inference in the AI attack surface model — the same runtime stage as prompt injection, but targeting a different asset: availability and cost rather than data or behavior. If you have not read the prompt injection attack flow tutorial, note that prompt injection and unbounded consumption often combine: an injected command that triggers a runaway tool loop is both attacks simultaneously.

The runaway agent loop variant connects directly to Excessive Agency — an agent with too many tools and no loop limit is vulnerable to both attacks. And because MCP servers are now a live attack surface for resource exhaustion, the AI Supply Chain and MCP Security tutorial covers the endpoint-hardening side of the same problem.

Once you have bounded your resources, Zero Trust for AI frames the broader principle: fail closed, minimal privilege, and continuous verification — all of which apply as much to cost budgets as to data access. Browse all tutorials to follow the full series.