Denial of Wallet: How One Prompt Can Cost 3,000x More Than It Should

OWASP now formally tracks this as LLM10: Unbounded Consumption. A single crafted prompt, hitting an LLM endpoint with no output token ceiling, can cost 3,000 times more than a normal request — not through anything clever, just through the absence of a limit that was never set.

What "Denial of Wallet" Actually Is

Security researchers have coined the term Denial of Wallet (DoW) for a specific class of attack: instead of overwhelming a server with traffic like a classic denial-of-service attack, an attacker overwhelms your bill. Every LLM query forces the model to process an expensive operation — and if there's no ceiling on how long or complex that operation can get, a single request can be engineered to consume vastly more compute (and cost) than a normal one. OWASP's Top 10 for LLM Applications now lists this formally as LLM10: Unbounded Consumption, describing exactly this pattern: pay-per-token or pay-per-inference systems with no input or output limits, generating "unsustainable financial costs" from otherwise legitimate-looking traffic.

The number that should stop any team shipping an LLM feature: one malicious prompt can cost 3,000x more than a normal request, purely because nothing was capping the output.

Why This Isn't Just a "Malicious Actor" Problem

It's tempting to file Denial of Wallet under "attacker problems, not my problem" — but the code-level cause is identical whether the trigger is malicious or entirely benign:

• A support chatbot, internal tool, or agent with no max_tokens set will happily generate an enormous response if the model decides the answer warrants it — no attacker required.
• A crafted prompt designed to trigger the most expensive possible generation path (long reasoning chains, exhaustive structured output, deeply nested retries) is just an adversarial version of the exact same missing guardrail.
• Fixing it once, at the code level, defends against both cases simultaneously — there's no separate "attacker mitigation" needed beyond the fix you should already have shipped.

// no output ceiling — cost is entirely open-ended
const response = await openai.chat.completions.create({
  model: 'gpt-4',
  messages: [{ role: 'user', content: userSuppliedPrompt }],
  // max_tokens intentionally omitted, or just forgotten
});

How Thuban Cost Guard Catches This

This is exactly the failure TCG-201 (Missing Output Token Limit) was built for. Cost Guard's static analyzer checks every OpenAI, Anthropic, and Vercel AI SDK call site for a real output ceiling — max_tokens, max_completion_tokens, maxTokens, maxOutputTokens, or the provider-equivalent. No ceiling means a MEDIUM finding on its own; a MEDIUM finding on a call that's also inside an unbounded loop (TCG-101) escalates automatically to HIGH, because the two risks compound — an unlimited-length response, repeated indefinitely, is the worst version of this problem.

Sources

• Hiflylabs: Unbounded Token Consumption — How Not to Burn All Your Money on LLM API Costs
• StackHawk: Understanding and Protecting Against LLM10: Unbounded Consumption
• A10 Networks: LLM Unbounded Consumption & DoS Attacks (OWASP LLM10)

npx thuban protect