Solutions / Token torching
Nothing was stolen. Everything was spent.
Token torching turns your own AI against your budget. Attackers push agents and LLM endpoints into oversized prompts, runaway loops, and expensive completions until the spend is the damage. Cerberus baselines token consumption per actor and catches the burn as it starts.
throttlecap spendalertIllustrative product interface. The figures shown are an example of how Cerberus presents a detection, not benchmark or performance results.
Every request is valid
Authenticated, well-formed calls to an endpoint you built. Nothing for a WAF to match.
Rate limits count requests
A few giant-context calls outburn thousands of small ones. Request counts miss the cost.
The bill arrives later
Without spend monitoring, the first alert is the invoice, weeks after the burn.
How it works
Spend is a behavior. Cerberus reads it.
Token consumption is baselined per actor, so a burn stands out in minutes, not on the invoice.
Coverage
What Cerberus catches here.
Denial-of-wallet
Floods of expensive completions that run up spend until the budget is the casualty.
Context stuffing
Oversized prompts engineered to maximize the cost of every request.
Runaway agent loops
An agent stuck or steered into recursive calls, burning tokens on repeat.
Model extraction runs
High-volume systematic querying that distills your model at your expense.
Amplification abuse
One cheap request that fans out into a chain of expensive model calls.
Prompt-injected burn
Injected instructions that turn a cheap task into an expensive one.
FAQ
Common questions
What is token torching, or denial of wallet?
It is driving an application to burn metered inference until the cost itself becomes the damage. OWASP tracks the category as LLM10:2025 Unbounded Consumption; the name token torching was coined by Bitsight in 2026 for the deliberate case. Unlike most attacks it targets availability and cost rather than confidentiality, which is why it is so often noticed by finance rather than by security.
How is it different from a legitimate traffic spike?
A real spike is distributed across many actors and looks roughly like your ordinary usage, only more of it. Torching concentrates: one actor, or a small set, generating requests whose shape is wrong. Long contexts, deep retry loops, and prompts engineered to maximise output tokens all cost far more per request than normal traffic does. Volume alone will not tell those apart, which is why the baseline has to be per actor and denominated in spend rather than in requests.
Can rate limits solve this on their own?
Only partly, because a rate limit counts requests and the bill counts tokens. A handful of requests with very large contexts can outspend thousands of ordinary ones while sitting comfortably inside any per-minute cap. Rate limits are still worth having as a blunt ceiling. They are not a substitute for watching what each actor actually spends.
Who usually notices first?
The invoice, which is the problem. Inference spend is typically reconciled monthly, so an attack that starts on the second of the month has four weeks of runway before anyone with a reason to care sees the number. Closing that gap is most of the work: a per-actor spend baseline turns a billing-cycle detection lag into a minutes-long one.
Catch the burn, not the bill.
See Cerberus read your own traffic, human and agentic, in one walkthrough tailored to your stack.
