💸 Unbounded Consumption and Denial of Wallet (LLM10): How to Protect an AI System from Runaway Spend and Financial Exhaustion

Who this is for: Teams operating LLM services and AI agents on pay-per-token / pay-per-inference pricing — where every request to the model costs money, and an uncontrolled stream of calls turns from an availability incident into direct financial damage.

Unbounded Consumption (formerly Model Denial of Service) is a class of vulnerabilities in which an application permits excessive and uncontrolled model output: an overwhelming number of requests, context inflation, resource-heavy computation. The outcomes are denial of service (DoS), service degradation, model theft, and — often the scariest for a business — economic damage, "Denial of Wallet" (DoW): the attacker doesn't take the service down but generates a volume of billable calls that hands the company an unpayable bill. This class is recorded in the OWASP Top 10 for LLMs 2025 as LLM10:2025 Unbounded Consumption. This page walks through the overspend vectors and shows how SYNTREX — the defense layer of the Spectorn platform (a set of detection-and-blocking engines that runs inside Spectorn and deploys standalone on the customer's internal perimeter) — closes them off. An honest framing up front: the actual load limiting — rate limiting, quotas, token budgets, and timeouts — lives at the infrastructure gateway (gomcp), not in the detection engines. SYNTREX's role here is detection and correlation: recognize a flood or inflation pattern and raise an alert so the gateway and the playbook apply throttling.

Part of the threat series: OWASP LLM Top 10 · Autonomous AI Agents · Excessive Agency · Data Exfiltration.

What Denial of Wallet Is and Why Tokens = Money

In the classic DoS model the attacker's goal is to exhaust a compute resource and make the service unavailable. In the LLM world the economics are different: model output is billed by the unit — for input and output tokens, per inference call, per GPU-second. That shifts the attack's center of gravity.

DoS — overload the system so it stops answering legitimate users (degradation, queues, refusals).
Denial of Wallet (DoW) — don't take the service down at all, but make it run dutifully at maximum billable load. The service is "healthy," but at the end of the month a bill arrives that can shut the company down. On pay-per-token pricing this is the most insidious form: availability metrics are green while the financial pull is red.
Model theft — extract a model's behavior/weights through a series of expensive requests; this is both overspend and intellectual-property theft at once.

Why agentic systems are especially exposed. An autonomous AI agent (see Autonomous AI Agents) doesn't make one call — it recursively plans, invokes tools, reads their output, and queries the model again. A single top-level command unfolds into dozens or hundreds of nested inference calls and API requests. Here DoW can occur even without an attacker: a well-meaning employee asks the agent to "research every competitor and assemble a complete report" — and a poorly designed human-in-the-loop launches hundreds of recursive tool calls, each of which costs money. Overspend is not only malice but also an architectural defect in recursion control.

This is exactly why protection against unbounded consumption is two distinct layers that must not be conflated: infrastructure limiting (the gateway throttles the stream) and behavioral detection (the engine and SOC see that the stream is anomalous and raise an alarm). SYNTREX owns the second layer and feeds signals to the first.

🛑 Overspend Vectors and How SYNTREX Closes Them

1. Token/input flooding — a flood of requests and inflated input

Risk: The attacker generates a high volume of requests — many back-to-back calls or individual giant prompts with variable-length input deliberately tuned to maximize the number of billable tokens. The goal isn't so much to take the service down as to spin up the meter: on pay-per-token pricing, every extra token turns into money. The stream may come from a single source or be spread across sessions to evade naive thresholds.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

SYNTREX defense:

Engines/components: resource_exhaustion, SOC Correlation Engine, Decision Logger.
resource_exhaustion recognizes resource-heavy input — an abnormally large prompt and patterns aimed at exhausting a resource — and flags the request before it is sent to the model.
Serial flooding is visible not in a single event but in its frequency: the SOC Correlation Engine catches a spike of same-shape requests from one sensor/session (the ALERT_FLOOD rule), and the Decision Logger records an immutable trail for review.

What SYNTREX honestly does NOT replace: the rate limiting itself. Rate limiting, per-tenant quotas, and token ceilings are settings on the API gateway (gomcp) that physically throttle traffic. SYNTREX recognizes that the stream is anomalous and raises an alert; the gateway performs the throttling per the playbook. The engine does not "brake" traffic on its own.

2. Recursive context expansion — inflating the context window

Risk: The attacker forces the system to expand the context again and again: each response is fed back into the input, documents are recursively appended, the conversation history balloons to the window limit. Because inference cost grows with context length, this "winding up of the window" (context-window flooding) turns a single conversation into an expensive funnel — the token count multiplies at every step.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

SYNTREX defense:

Engines/components: resource_exhaustion, SOC Correlation Engine.
resource_exhaustion recognizes patterns of avalanche-like input expansion and instructions aimed at winding up the context, flagging them as resource-exhausting.
Growth in request length within a single session is correlated in the SOC as a context-flooding indicator, so the gateway can apply a length/context ceiling.

What SYNTREX honestly does NOT replace: a hard ceiling on context size and request length. The maximum window, history truncation, and an input-token limit are settings on the gateway and the application itself, not on the detection engine. SYNTREX signals the inflation; the infrastructure enforces the limit.

3. Recursive agent cost attack — recursive agent overspend

Risk: The agent is given a task that unfolds into an uncontrolled tree of calls: "research every competitor and assemble a complete report," "crawl the entire site and index every page." The agent recursively plans, invokes tools, reads the output, and queries the model again — hundreds of nested inference calls and API requests for one command. The danger is that the initiator can be either an attacker or a well-meaning employee: a single poorly designed human-in-the-loop with no recursion ceiling can trigger a DoW event. The agent drifts away from a predictable goal into a mode of endless expansion, sometimes "spinning" with no real progress.

OWASP LLM10:2025 Unbounded Consumption, LLM06:2025 Excessive Agency · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

SYNTREX defense:

Engines/components: goal_predictability, false_completion, SOC Correlation Engine.
goal_predictability is a behavioral heuristic engine: it flags patterns in the agent's commands that drive it off its intended goal into a runaway-expansion mode — a recursive "crawl everything" is flagged as such a pattern long before the bill balloons.
false_completion catches loops with no real progress: the agent reports advancement or spins in place without getting closer to completion — a behavioral marker of cost runaway. The SOC correlates the pairing "goal drift + call spike."

What SYNTREX honestly does NOT replace: hard recursion limits and human control. A ceiling on agent depth/step count (max-recursion, max-steps), a budget on the number of tool calls, and a mandatory human-in-the-loop on expensive branches are controls of the gateway and the agent orchestrator. SYNTREX recognizes runaway behavior and raises an alarm; the infrastructure stops the chain per the playbook. Least privilege and human-in-the-loop remain mandatory organizational measures (see Excessive Agency).

4. API key theft → Denial of Wallet

Risk: The attacker obtains a stolen API key (leaked in a repository, in logs, via data exfiltration or a confused deputy) and runs a mass stream of expensive inference requests through it — on your dime. This is no longer hypothetical but a documented real incident. According to Sysdig's LLMjacking research, the use of compromised cloud credentials against AWS Bedrock drove costs on the order of $46,000 per day. In another reported case (March 2026) a stolen Google Gemini API key ran a bill up to roughly $82,000 over 48 hours. The service stays "healthy" throughout — the attack hits the wallet, not availability.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

SYNTREX defense:

Engines/components: SOC Correlation Engine, Decision Logger, resource_exhaustion.
A sudden mass stream from one key/sensor is visible to the SOC as ALERT_FLOOD (100+ events from one sensor in 60 seconds) — an early indicator of a compromised key, well before the bill arrives.
The Decision Logger maintains an immutable chain of decisions (SHA-256/HMAC): a provable trail of "when the anomalous stream began and from which source" for forensics and bill disputes. resource_exhaustion flags the resource-heavy requests in that stream.

What SYNTREX honestly does NOT replace: key management and financial safeguards. Key rotation and revocation, billing circuit breakers (an automatic stop when the budget is exceeded), per-tenant quotas, and spend alerts are controls of the provider, the gateway, and your billing plane. SYNTREX detects the anomalous stream and raises an alarm; the gateway and provider perform key revocation and spend cutoff.

5. Resource-intensive queries — crafted resource-heavy requests

Risk: The attacker shapes individual requests so that each forces the model into prolonged processing: tasks that provoke long generation, multi-step "reasoning," calls to heavy tools. Even a moderate number of such requests yields disproportionate load and cost — many expensive output tokens and a long hold on compute per call.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0029 (Denial of ML Service), AML.T0034 (Cost Harvesting).

SYNTREX defense:

Engines/components: resource_exhaustion, cognitive_guard, SOC Correlation Engine.
resource_exhaustion recognizes input aimed at exhausting a resource — constructs that provoke disproportionate processing — and flags it before execution.
cognitive_guard signals abnormally heavy requests that fall outside the normal profile; the SOC correlates a series of such events so the gateway can apply a timeout and a cost ceiling per call.

What SYNTREX honestly does NOT replace: timeouts and per-call limits. Maximum request processing time (request timeout), an output-token ceiling, and a limit on "reasoning" depth are settings on the gateway. SYNTREX recognizes a resource-heavy request and raises an alert; the infrastructure aborts the overrunning processing on timeout.

🛠️ Recommended Configuration

A protection profile against unbounded consumption is built from two layers: the SYNTREX engines detect the anomaly, and the gateway section (executed by gomcp) limits the stream. This split is not cosmetic but the essence of the honest model: the engine does not perform throttling.

YAML

# syntrex.yaml — unbounded consumption protection profile (LLM10 / Denial of Wallet)
version: "1.0"
mode: consumption_guard

engines:
  resource_exhaustion:
    action: alert                  # resource-heavy input: a giant prompt, context inflation
    max_input_tokens: 8000         # threshold above which input is flagged as abnormally large
    detect_expansion: true         # avalanche-like context-window expansion
  goal_predictability:
    action: alert                  # behavioral heuristic: agent drift into runaway recursion
  false_completion:
    action: alert                  # loops with no real progress (agent cost runaway)
  cognitive_guard:
    action: alert                  # abnormally heavy requests that fall outside the profile

# === Spend control — NOT engines, but gomcp gateway settings ===
# SYNTREX detects and correlates; the actual throttling is performed by the infrastructure.
gateway:
  enforced_by: gomcp               # these limits are set and enforced by the API gateway, not detection
  rate_limit: 60/min               # request-rate ceiling per source
  quota:
    per_tenant_tokens: 1_000_000   # per-tenant token budget (period)
    per_tenant_requests: 10_000    # per-tenant request-count budget
  timeout: 30s                     # maximum processing time for a single request
  max_recursion: 25                # ceiling on agent depth/step count
  billing_circuit_breaker: true    # auto-stop when the spend budget is exceeded

audit:
  decision_logger: true            # immutable chain (SHA-256/HMAC) for bill forensics

🚨 Correlation Rules (SOC)

Overspend almost always shows up as anomalous frequency: a spike of same-shape requests from one source, or an avalanche of tool calls in a short window. The SOC raises an alert; the playbook asks the gateway for throttling.

JSON

{
  "name": "ALERT_FLOOD_SENSOR",
  "description": "An anomalous spike of events from one sensor/session — an indicator of flooding or a compromised key",
  "condition": "count(events[source='sensor'], window=60s) >= 100",
  "severity": "HIGH",
  "playbook": "throttle_source_and_alert_soc"
}

JSON

{
  "name": "AGENT_RECURSION_COST_RUNAWAY",
  "description": "An avalanche of tool calls from one agent session in a short window — recursive overspend (DoW)",
  "condition": "sequence(goal_predictability[match=true] OR false_completion[match=true], count(tool_calls[session=same], window=120s) >= 50)",
  "severity": "CRITICAL",
  "playbook": "kill_agent_session_and_alert_soc"
}

❓ Frequently Asked Questions (FAQ)

What is Denial of Wallet (a wallet attack)? Denial of Wallet (DoW) is an attack in which the adversary doesn't take the service down but generates a volume of billable model calls (tokens, inference) that hands the company an unpayable bill. On pay-per-token pricing this is especially dangerous: the service is formally "healthy," availability metrics are green, yet the financial load can shut the business down. DoW is the key emphasis of the OWASP LLM10 Unbounded Consumption class. SYNTREX detects the anomalous stream (resource_exhaustion, SOC ALERT_FLOOD), while the gateway limits spend through quotas and circuit breakers.

What is unbounded LLM consumption (LLM10)? Unbounded Consumption (formerly Model Denial of Service) is the OWASP LLM10:2025 class in which an application permits uncontrolled resource spend: an overwhelming number of requests, context inflation, resource-heavy computation. The outcomes are denial of service (DoS), degradation, model theft, and economic damage (Denial of Wallet). It is especially dangerous for agentic systems with recursive calls, where one command unfolds into hundreds of billable requests.

How do I protect against token overspend and runaway API costs? It's two layers. The infrastructure layer is mandatory: rate limiting, per-tenant quotas, token ceilings, timeouts, and billing circuit breakers on the API gateway (in our topology, gomcp). The behavioral layer is SYNTREX detection: resource_exhaustion flags resource-heavy input, goal_predictability and false_completion catch a runaway agent, and SOC ALERT_FLOOD correlates a load spike. The engines see the anomaly and raise an alarm; the gateway throttles the stream. Without infrastructure limits, detection alone won't stop overspend.

Can an AI agent cause a Denial of Wallet on its own? Yes, with no attacker at all. An autonomous agent recursively plans, invokes tools, and queries the model again — one command, "research every competitor and assemble a report," unfolds into hundreds of nested inference calls. If the design has no recursion ceiling and no human in the loop on expensive branches, a well-meaning employee can trigger a DoW event themselves. goal_predictability heuristically flags the agent's drift off its intended goal into runaway expansion, and false_completion catches loops with no progress; a hard max-recursion and human-in-the-loop are set on the gateway.

Does SYNTREX do rate limiting? No — and this is a fundamentally honest boundary. SYNTREX owns detection and correlation: the engines recognize flooding, context inflation, and runaway agent behavior, and the SOC correlates the spike and raises an alert. The actual throttling — rate limiting, quotas, timeouts, recursion ceilings — is performed by the API gateway (gomcp) as an infrastructure control. SYNTREX feeds the gateway signals of "the stream is anomalous, throttle it," but it does not brake the traffic itself. Don't trust framing in which a detection engine "limits load" — that's the gateway's job.

How do I detect a flood attack on an LLM? A flood is visible by frequency, not by a single event. The baseline indicator is the SOC rule ALERT_FLOOD: 100+ events from one sensor/session in 60 seconds. At the input level, resource_exhaustion flags abnormally large and resource-heavy requests, and correlation in the SOC distinguishes a legitimate peak from a stream spread across sessions. The Decision Logger preserves an immutable trail for review. From there the playbook asks the gateway to throttle the source.

What do I do if an API key is stolen? Immediately: revoke and rotate the key, stop spend with the billing circuit breaker, check the tenant's quotas — these are infrastructure actions on the provider and gateway side. SYNTREX helps detect the incident early: a sudden mass stream from one key is visible to the SOC as ALERT_FLOOD before the bill arrives, and the Decision Logger provides a provable "when and from where" trail for forensics and spend disputes. Real incidents (Sysdig's LLMjacking — on the order of $46,000/day on AWS Bedrock; a stolen Gemini key — roughly $82,000 over 48 hours) show that the bill spins up within hours, which is why early detection is critical.

📚 Sources

OWASP LLM10:2025 — Unbounded Consumption — the primary source on the unbounded consumption class and Denial of Wallet.
OWASP Top 10 for LLM Applications (2025) — the LLM01–LLM10 risk catalog.
MITRE ATLAS — AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).
Sysdig — LLMjacking: stolen cloud credentials used in new AI attacks — research on real overspend incidents (on the order of $46,000/day on AWS Bedrock).
NIST AI Risk Management Framework (AI RMF 1.0) — managing AI-system availability and resilience risks.
NIST AI 600-1 — Generative AI Profile — generative AI risk profile, including resource exhaustion.