Denial of wallet

Denial of wallet is an attack whose objective is your bill. Rather than exhausting a fixed resource until the service falls over, the attacker exploits the fact that a metered, auto-scaling service will keep serving — and keep charging — for as long as requests keep arriving.

LLM applications are unusually exposed to it, and OWASP folds the class into LLM10:2025 Unbounded Consumption.

Why LLM endpoints are the ideal target

• Cost per request is attacker-controlled. The bill scales with input and output tokens, and both are influenced by the caller. A long input plus a prompt that induces a long answer can be orders of magnitude more expensive than a typical request while looking, in a request-count graph, identical.
• Agents multiply. One user turn in an agent loop can fan out into dozens of model calls plus tool calls plus retrieval. A prompt that induces a loop is a cost amplifier with a small input.
• Retrieval widens the input. Anything that grows the retrieved context grows the token count for every subsequent turn in the conversation.
• Rate limits are usually set in requests. Requests per minute does not bound spend when spend per request is unbounded.

Controls that actually bind

• Budget in tokens and in currency, not in requests. Per user, per tenant, per API key, per day. This is the control that matters; everything else is supporting.
• Cap max_tokens explicitly on every call, and cap input length before the call is made.
• Bound agent loops — maximum iterations, maximum tool calls, maximum wall-clock time per task.
• Alert on spend rate, not only on spend. A monthly budget alert tells you about a weekend incident on Monday.
• Cache aggressively, and require authentication before any endpoint that reaches a paid model. An unauthenticated public demo in front of a metered API is a standing invitation.

The failure mode to design against is not the malicious one. It is the retry loop in a client someone shipped on a Friday.