Model Denial of Service
An attacker does not need to break a language model to hurt you. They just need to make it do a lot of expensive work. Models are slow and priced by the token, so wasted work is wasted money, and enough of it is an outage.
This is risk LLM04 in the OWASP Top 10 for LLM Applications, and it is the quietest one, because nothing looks broken. The system does exactly what it was asked. It was just asked to do far too much.
What it is
Two shapes.
Resource exhaustion: huge inputs, or outputs forced to be huge, or requests crafted to take the most expensive path through the model. Each one ties up capacity and runs up the bill.
Loops: an agent or chain where the model’s output feeds back in as input, around and around. One request can spin into hundreds of model calls if nothing caps the loop.
The attacker’s cost is one request. Yours is all the work it triggers.
Why it bites harder than normal denial of service
A classic denial of service floods you with traffic. This is worse in one way: a model request is expensive by design, so the attacker needs far less volume to do damage. A few very long inputs, or a handful of recursive agent tasks, can exhaust a metered, GPU-bound service that a plain web server would shrug off. And because you pay per token, the attack has a second edge. Even if you stay up, you can wake to a bill that was the real attack.
This is the same shape as the gas limit bug in smart contracts: when the cost of an operation is controlled by the person calling it, cost itself becomes the weapon.
The fix
Cap everything an attacker can inflate.
- Limit input size before it reaches the model. A hard ceiling on tokens in.
- Limit output length. Do not let a request ask for an essay when it needs a sentence.
- Rate limit per user, not just globally, so one caller cannot monopolize capacity.
- Cap loops. Any chain that can call the model repeatedly needs a hard maximum number of steps, no exceptions.
- Set a spending limit with an alert. A daily cap and a page when it trips. The bill is part of your attack surface. Monitor it like one.
The point
None of this is new. Rate limiting and input caps have protected web services forever. The model just raises the stakes, because each unit of work is slow and metered, so the gap between a bit of abuse and an outage, or a shocking invoice, is much smaller than you are used to.
So the question for your own system is simple: for every way a request can make the model work harder, is there a number that stops it? If any input, output or loop is unbounded, that is the one an attacker will find, and you will hear about it from your monitoring, or your bill.