Denial of wallet

What is denial of wallet?

Denial of wallet is an attack, or an accident, that costs you money instead of costing you availability. Someone drives usage of something you pay for per use, the invoice climbs, and the service never falls over. Every dashboard stays green while the meter runs.

The shift is in how you buy compute. When you rented a server, an attacker had to exhaust it: enough traffic to fill the CPU and your site went down. When you pay per token, per function invocation or per API call, there is nothing to exhaust. The platform scales, quietly and correctly, and every extra request is another line on the bill. That smooth scaling is not a side effect here. It is the mechanism.

The name comes out of serverless computing. A team at the University of Galway defined it in a 2021 paper as aiming traffic at pay-per-use endpoints to drive up the owner's bill, and showed that defences built for denial of service do not necessarily catch it. Generative AI made the idea far more attractive, because one request to a large model costs far more than one function invocation.

OWASP has it on the list. The entry Unbounded Consumption, in the OWASP Top 10 for LLM Applications, names denial of wallet as one of its attack types: attackers exploiting the cost-per-use model of cloud AI services until the bill stops being sustainable. That entry was LLM10 in the 2025 edition and moved up to LLM06 in the 2026 edition, published in August 2026, so quote the year with the number.

The three ways it happens

Three causes produce the same invoice, and they need different answers.

1. A deliberate attack on a public endpoint. Your demo chatbot, your free-tier API, your public search box. The attacker needs no vulnerability and never has to get in. Sending normal, valid requests is the whole attack, which is why nothing in your logs looks wrong.

2. A stolen credential running somebody else's workload. A key in a public repository, a leaked configuration file, a compromised laptop. The attacker uses your paid model access and often resells it. That pattern has its own name, LLMjacking.

3. Your own bug, with no cap on it. A retry loop with no ceiling, an agent that decides it needs another twenty rounds, a scheduled job firing every ten minutes at an empty queue.

The third is by far the most common, and the one nobody budgets attention for. Security teams model attackers; almost nobody models their own retry logic. If you only put one control in place, put it where it catches all three, which means at the spend rather than at the attacker.

The line between them is thin. In 2024 a developer got a bill of around 1,300 US dollars in two days on an empty S3 bucket, from close to 100 million write requests sent by an open source tool whose default configuration happened to name that bucket. The requests were rejected as unauthorised and billed anyway. AWS changed that rule in May 2024, but the point outlives the fix: a public endpoint with a price per request is exposed to traffic nobody aimed at you.

A public demo endpoint over one weekend

Four properties together make an endpoint worth abusing: it is public and unauthenticated, the output length is unbounded, there is an expensive model behind it, and the cost per request is high enough that a modest rate hurts. A demo assistant on your marketing site usually has all four, because asking visitors to log in would kill the demo.

Say each request sends roughly 1,500 input tokens and the answer is capped at 2,000 output tokens. At Anthropic's list price for Claude Sonnet 5 on 4 September 2026, 2 US dollars per million input tokens and 10 per million output, that is 0.003 dollars of input and 0.02 of output. Call it 2.3 cents. Prices move, so redo the sum with whatever your provider charges today.

Now add a rate a single script sustains without effort: two requests per second. Somebody starts it on Friday evening and you notice on Monday morning, 62 hours later. That is 446,400 requests, and 446,400 times 0.023 is about 10,270 dollars. Nothing went down and response times were fine.

Two changes move that a long way. Cap the answer at 300 output tokens and the weekend costs about 2,680 dollars. Send anonymous traffic to a cheap model as well, say Claude Haiku 4.5 at 1 and 5 dollars per million, and it costs about 1,340 dollars, roughly an eighth of where you started. A hard spend limit beats both: Anthropic's Start tier caps monthly spend at 500 dollars and stops requests there, which ends this weekend about three hours after it began.

Denial of wallet versus denial of service

The two look identical on the wire. What separates them is what the attacker is trying to exhaust.

A denial of service attack exhausts a finite resource: connections, CPU, memory, a rate limit, a licence count. Success is visible, because the resource runs out and users get errors. Your monitoring is built to notice that, and your autoscaling exists to prevent it.

A denial of wallet attack exhausts your budget, which is not finite in any way your infrastructure knows about. The autoscaling that saves you from the first attack is what delivers the second one, and the ideal traffic pattern for the attacker is one that stays under every threshold you set. Anti-DDoS protection counts requests and will absorb a flood, but it has no idea what a request costs you.

The controls, in the order they help

Authentication first. Everything below assumes you can tell callers apart. If your expensive endpoint is public, put a login, an issued key or an email step in front of it.

A hard spend ceiling that stops, not one that warns. This decides your worst case, and providers differ sharply. Anthropic enforces a monthly spend cap per tier and lets you set a lower one yourself, per organisation or per workspace, after which requests fail. Google Cloud has spend cap budgets that pause new usage of a service, currently for a short list including its model APIs and Cloud Run. Azure is explicit that its budgets do not: notifications fire, and in Microsoft's own wording, resources are not affected and your consumption is not stopped.

Quotas per key and per user. One global limit tells you nothing about who spent the money. A quota per API key or per session turns one bad actor into one blocked key instead of a company-wide outage. A rate limit helps and is not enough on its own, because a rate low enough to protect the bill is often too low to be usable.

A cap on output length. Set the maximum output tokens on every call. One parameter, no cost, and it moves the worst case more than most of the clever controls.

A cheaper model for untrusted traffic. Route anonymous traffic to a small model and keep the expensive one for signed-in users.

Alert on the rate of spend, not the monthly total. Half your monthly budget gone in an afternoon is the signal. Ninety percent gone on day 27 is normal.

What to watch out for with denial of wallet

Billing data arrives too late to save you. Azure documents cost data as typically available within 8 to 24 hours, with budgets evaluated every 24 hours, and AWS refreshes budget information up to three times a day. The signal has to come from a counter you own: requests per key per minute, tokens per hour, calls per endpoint, out of your own application or a gateway.

Ask the hard cap question before you launch anything public. Whether your provider offers a stop or only a warning moves your worst case from a few hundred euro to an open-ended number. Ask it while you are still choosing, along with who may raise the cap.

If it happens, act in this order. Rotate the credential, then cap or disable the endpoint, then work out which of the three causes it was. Doing the diagnosis first is the expensive mistake, because the meter runs while you investigate.