Denial of Wallet: When the Bill Is the LLM Attack

Q: What is a Denial of Wallet attack?

A Denial of Wallet attack abuses a legitimately-exposed, pay-per-use service — most acutely a pay-per-token LLM endpoint — to run up unsustainable financial cost, and its defining characteristic is that it succeeds by keeping your service up rather than taking it down. Traditional denial of service aims for downtime: flood a fixed-capacity server until it falls over. Denial of Wallet aims for the invoice: send load that looks entirely legitimate to an endpoint that scales elastically and charges per request or per token, so the service keeps responding normally while the bill climbs to a ruinous level. OWASP formalised this under LLM10:2025 Unbounded Consumption, the category that replaced the narrower 2023 Model Denial of Service entry precisely because starving a metered AI service of money is a more modern and more damaging threat than knocking it offline. The reason it is a 2026 problem rather than an old one is the pricing model: a per-token endpoint has no natural capacity ceiling to hit, so the elasticity that makes serverless inference attractive is exactly what turns an unbounded or unauthenticated endpoint into a cost furnace an attacker controls. The symptom is financial, not operational — there is no outage to alert on, only a spike on the bill — which is why detection has to watch cost, and defence has to bound spend.

Q: How is Denial of Wallet different from LLMjacking?

They produce a similar painful invoice through completely different entry points, and confusing them leads to defending the wrong thing. LLMjacking is credential theft: an attacker steals your API keys or cloud credentials and runs their own inference workloads on your account, so you pay for compute the attacker consumes for their purposes, often reselling access. The defence for LLMjacking is credential hygiene — rotation, scoping, secret detection, anomaly detection on key usage — because the root cause is a stolen key. Denial of Wallet needs no stolen credentials at all. It abuses an endpoint you deliberately exposed to the world or to your users — a public demo, a preview feature, an authenticated but unbudgeted API — by sending high volumes or expensive requests through the front door you left open on purpose. Rotating secrets does nothing against it, because no secret was compromised. The defence is bounding consumption: authentication on every path so every caller is identified, rate and concurrency limits, input and output token caps, and above all a per-identity spend budget with a circuit breaker. In short, LLMjacking is about who is allowed to hold the key, while Denial of Wallet is about how much anyone holding a legitimate identity is allowed to spend. A complete posture defends both, but with different controls.

Q: Why do normal rate limits fail to stop Denial of Wallet?

Because the most damaging vectors are expensive per request rather than numerous, so a limit expressed in requests per second simply does not see them. Standard rate limiting assumes the cost of each request is roughly uniform, so capping requests-per-second caps cost. That assumption breaks for LLM endpoints, where the cost of a single request varies enormously with the number of tokens processed and generated. Two vectors exploit this directly. Context-window saturation sends oversized inputs — a request stuffed with the maximum tolerable context — so each individual call consumes a large number of input tokens, and even a low request rate racks up enormous cost. Expensive-generation prompts are crafted to trigger the most computationally costly behaviour: long reasoning chains, maximal output length, intricate structured outputs, so the model spends a fortune of compute per response. An attacker combining both sends a small number of requests, each maximally expensive, and sails comfortably under any requests-per-second threshold you set. The fix is to denominate your limits in the unit that actually costs money: tokens and dollars. That means validating and capping input size, capping output tokens per response, timing out long generations, and enforcing a spend budget per identity — so the control is measuring the same thing the attacker is exploiting, rather than a request count that has decoupled from cost.

Q: What controls actually stop a Denial of Wallet attack?

A layered set, where the load-bearing control is a per-identity spend budget, and the precondition is that every inference path is authenticated. Start with authentication: no route that reaches a model may be callable anonymously, because an anonymous caller who can spend your tokens is a blank cheque, and this is the single most common enabler. Next, centralise enforcement behind an AI gateway so every request passes one place that can apply the rest of the controls, rather than scattering limits across services where one path inevitably lacks them. Then apply limits denominated in the right units: rate and concurrency limits to stop flooding, input size validation to stop context-window saturation, output token caps and generation timeouts to stop expensive-prompt attacks, and loop and tool-call budgets to stop recursive agent runaway. The control that bounds the worst case is a hard spend budget per identity — a dollar or token ceiling that, when hit, stops serving that identity rather than continuing to bill — paired with a circuit breaker that trips on cost and real-time cost anomaly alerting. That last combination matters because Denial of Wallet has no operational symptom: there is no outage, so the cost curve itself is your intrusion-detection signal. Together these convert an unbounded, silent financial loss into a bounded, alerted, recoverable event. The OWASP mitigations for Unbounded Consumption map directly onto this: input validation, rate limiting, and user quotas.

Q: Do I need to protect my own AI agents against Denial of Wallet?

Yes, and it is one of the most overlooked cases, because a recursive agent with no budget is a self-inflicted Denial of Wallet attack launched from inside your own trust boundary. An autonomous agent that plans, calls tools, and invokes the model, then re-plans and repeats, can enter a loop where it re-calls the model and tools without bound — and because it is your own authenticated automation, it passes every authentication check and looks entirely legitimate. Economically the result is identical to an external cost-exhaustion attack: the meter runs up a ruinous bill while everything appears to be functioning. The defence is to treat your own automation as a threat model. Every agent task needs a token budget (a ceiling on total tokens the task may consume), a tool-call budget (a ceiling on how many tool invocations it may make), and a wall-clock budget (a timeout on the whole task), plus the same spend circuit breaker you apply to external callers. This is especially important as agent fleets scale, because a bug or an adversarial input that pushes one agent into a loop, multiplied across a fleet, is a large and fast financial loss. The principle is that authentication tells you the caller is allowed to act, but it says nothing about how much they are allowed to spend, and that is true whether the caller is a stranger or your own agent. Budget both.

Q: What is OWASP LLM10:2025 Unbounded Consumption?

LLM10:2025 Unbounded Consumption is the tenth entry in the 2025 OWASP Top 10 for LLM Applications, and it defines the risk that arises when an LLM application allows users to conduct excessive and uncontrolled inferences, leading to denial of service, economic loss, model theft, and service degradation. It deliberately replaced the 2023 edition narrower Model Denial of Service category, broadening the scope from just availability to the full spectrum of resource abuse — because for metered AI services the economic dimension is often the more serious threat. Under this umbrella OWASP explicitly names Denial of Wallet as an attack that targets pay-per-token or pay-per-inference pricing by generating high volumes of requests to create unsustainable cost, alongside related patterns: context-window saturation with oversized inputs, prompts engineered to trigger the most computationally expensive operations, and model extraction that systematically queries the endpoint to clone its behaviour. The recommended mitigations are concrete and architectural: strict input validation so inputs cannot exceed reasonable size limits, rate limiting and per-user quotas to restrict how much any single source can consume, and monitoring — and OWASP notes these overlap with the controls for Excessive Agency, since bounding tool invocation is part of the same discipline. Treating Unbounded Consumption as a first-class design constraint, rather than a billing surprise to be reconciled after the fact, is the shift the category is pushing teams to make.

Q: How do I detect a Denial of Wallet attack if there is no outage?

You detect it on the cost curve, because for Denial of Wallet the spend itself is the intrusion signal — there is no downtime, no error spike, and no availability symptom to trip a conventional alert. This is the crucial mindset shift: cost has to be treated as first-class security telemetry, monitored in real time and reviewed alongside traditional signals, not left as a monthly finance reconciliation that surfaces the attack weeks after it happened. Practically, instrument token consumption and spend per identity, per endpoint, and in aggregate, and set anomaly detection on those streams — a sudden rise in tokens-per-request, a single identity spending far above its baseline, or total spend accelerating faster than traffic are all signals. Pair the detection with a spend circuit breaker so the system can act on the signal automatically: when an identity crosses its budget or the anomaly detector fires, inference for that identity (or globally, in the worst case) stops rather than continuing to bill. The reason automated action matters is speed — a Denial of Wallet attack can run up a five-figure loss in hours, faster than a human on-call can investigate a cost dashboard, so the circuit breaker bounds the damage while the alert brings a human in to confirm and respond. In short: meter everything, alert on cost anomalies, and wire the alert to an automatic spend cutoff, because the bill is both the target and the only symptom.

Q: Is Denial of Wallet only a risk for public or unauthenticated endpoints?

Public and unauthenticated endpoints are the most acute and common case, but Denial of Wallet is not limited to them, so authentication alone is necessary but not sufficient. An unauthenticated inference path is the worst case because literally any anonymous caller can spend your money, which is why authenticating every path is the first control. But three authenticated scenarios remain exposed if you stop there. First, a compromised or malicious legitimate user: an authenticated account with no spend budget can still run up unbounded cost, deliberately or through a compromised session. Second, a legitimate user driving expensive requests unintentionally — a poorly designed client, a retry storm, or a user pasting enormous inputs — can cause the same financial damage without any malice. Third, and most overlooked, your own authenticated automation: a recursive agent or a batch job with no task budget is a self-inflicted attack from inside the trust boundary that passes every authentication check. The unifying insight is that authentication answers who is allowed to call the endpoint, but Denial of Wallet is about how much any allowed caller can spend, which authentication says nothing about. So the complete defence pairs authentication on every path with a per-identity spend budget, token and rate limits, and a cost circuit breaker that applies regardless of whether the caller is anonymous, an authenticated human, or your own agent. Treat every identity as budgeted, not just every stranger as blocked.