How it works
Long contexts, recursive agent behaviour, expensive multimodal work or tool chains that never terminate consume compute, memory, third-party quota and money out of all proportion to the volume of requests submitted.
The cost is set by the caller
Conventional application requests vary in cost, but within a bounded range the operator controls. Inference does not behave that way: the caller chooses the input length, and cost scales with it — steeply, since attention cost grows faster than linearly with context.
A single request at maximum context can cost hundreds of times an ordinary one while counting as one request against any rate limit. Where the model is agentic, one user instruction may expand into dozens of inference calls plus the tool invocations between them, so the multiplier is not bounded by anything the caller had to send.
Request-count rate limiting therefore provides almost no protection here. The unit that must be limited is tokens, inference calls and spend.
Denial of wallet
The most distinctive property of this category is that the damage often shows up as a bill rather than an outage.
Against a metered provider, an attacker who cannot exhaust capacity can still exhaust budget. Where the platform scales automatically, the service stays up and the cost accrues; where a spending cap exists, hitting it takes the service down for everyone. Both outcomes are attacker-selected.
Third-party quota is the same problem one step removed. If inference or a tool depends on an external provider with a rate limit, an attacker who consumes that quota denies the capability to every legitimate user, and the provider may throttle the account for a period that outlasts the attack.
This is why inference spend belongs on a security dashboard rather than only a finance one. A sharp rise in cost per user, or one identity dominating spend, is an incident signal that finance review will surface days too late.
Agent loops
Agentic systems introduce a failure mode with no real analogue in conventional applications: the system can decide to keep working.
An agent that plans, acts, observes and re-plans may fail to converge. Two agents or tools invoking each other can recurse. A task that is subtly impossible produces indefinite retrying, because from the model's perspective one more attempt is always reasonable.
These loops are frequently triggered accidentally, which is worth stating plainly — this is a reliability problem before it is a security one, and an attacker only needs to find the inputs that reach it deliberately.
Bounds are the only reliable answer, and they must be absolute rather than heuristic: a maximum number of steps per task, a maximum total tool calls, a recursion depth limit, and a wall-clock deadline on the outermost task. A model must never be able to grant itself more budget, which means the limit has to be enforced by the orchestration layer and not expressed as an instruction.
Controls that work
The pattern is to make cost explicit and bounded at every layer.
- Per-identity budgets denominated in tokens and currency, refreshed on a window, with expensive operations refused once exhausted while cheap ones continue.
- Hard caps on input length, and on output length, enforced before the request is dispatched.
- Step, tool-call and depth limits on any agentic workflow, enforced outside the model.
- Timeouts at every layer, including one on the whole task — per-call timeouts do not bound a loop.
- Caching for repeated and near-identical prompts, which is unusually effective because automated abuse tends to repeat.
- Spend and token-rate alerting treated as security telemetry, with a defined threshold and an owner.
Also known as
What defenders may observe
- Token, tool-call or inference spend spikes without user growth
- Agent loops repeat without making progress
- Queue latency grows from a small number of requests
- Context lengths cluster at the maximum permitted
- A single identity accounts for a disproportionate share of spend
Prevention and mitigation
- Budget per identity in tokens and currency, not in requests
- Bound agent steps, recursion depth and total tool calls per task
- Set timeouts at every layer including the outermost task
- Cap input length and reject rather than truncate silently where correctness depends on it
- Cache aggressively for repeated or near-identical prompts
- Alert on spend rate as a security signal, not only as a finance one
Initial response priorities
- Disable unsafe model actions or affected data connectors.
- Preserve prompts, retrieved content, tool calls and model outputs.
- Revalidate trust boundaries, permissions and human approvals before restoration.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.