Token Torching: Why Attackers Care About Your Usage Limits

AI is becoming part of almost everything: customer support, security operations, software development, research, analytics, internal workflows, and, most importantly, drafting emails. AI is increasingly embedded in real business processes, and that creates new risks, not to mention the level of unprecedented access mainly of these platforms to our data. Token torching (a type of Denial-of-Wallet (DoW) attack) is one emerging AI risk.

What is token torching?

At a basic level, token torching is when someone abuses an AI system in a way that forces it to burn through tokens, time, and money. It may not look as dramatic as ransomware. It doesn’t involve stealing a database, encrypting servers, or taking down a website. But that doesn’t diminish the danger. In an AI-driven environment, tokens represent business cost, capacity, and performance. If an attacker can force your AI system to waste enough of them, that becomes a real problem. 

This risk lines up with OWASP’s LLM10:2025 category, Unbonded Consumption. OWASP describes token torching as a situation in which an LLM allows excessive or uncontrolled interference, creating risks such as denial of service (DoS), economic loss, unauthorized usage, and service degradation. In other words, this isn’t just an annoying finance issue. 

Tokens are tiny, until they are not

A single AI request may not seem like a big deal. A prompt here, a response there, a few follow-up questions, maybe some context pulled in from another system. Nothing too scary. But those small little requests add up fast, and they eat up available tokens. Imagine a threat actor intentionally designing prompts or workflows that make an AI system do way more work than it needs to. Maybe the system generates huge responses, pulls in massive amounts of context, calls tools over and over again, summarizes documents that did not need to be summarized, or gets stuck in a loop. Maybe an attacker hides confusing, contradictory, or overly complex instructions in a document, PDF, webpage, or other piece of content the AI is asked to read. The AI may not know it is being baited into doing extra work. It may just try to resolve the mess, reason through it, or generate way more output than the user actually needed. All of those actions can and will eat up tokens.

I imagine this would be really fun for a nefarious actor or a bored person, but it is not fun for the person or company footing the bill. One request can be expensive, a hundred requests become very expensive. Thousands of requests can impact budget, performance, and potentially availability. And availability is not just a technical detail; it is one of the core tenants of cybersecurity’s CIA triad. This goes beyond just using up tokens, it potentially limits a user's ability to leverage AI platforms, ultimately impacting output. The attacker does not always need to “break” the model. Sometimes they just need to make the model do exactly what it is allowed to do, but in the most wasteful way possible.

How does a token torching attack work? 

Token torching can happen in a few different ways: 

• One method is contradiction injection, where an attacker hides conflicting facts or instructions in text. The AI may try to reconcile the contradictions, explain both sides, or keep reasoning through something that was designed to waste time, and tokens. 
• Another method is decoy injection, where hidden logic puzzles, complex math problems, or overly detailed instructions are placed into documents, websites, PDFs, or other content the AI may ingest. The user may think they simply asked for a general summary, but behind the scenes, AI may have been maliciously prompted to solve something much more complex and unnecessary. 
• Then there is prompt manipulation, where the attacker directly crafts prompts that push the AI to write long, repetitive, wildly complex, or tool-heavy responses. 

These methods are unfortunately very effective in burning through tokens.

This is not always a classic cyber attack

When people think about cyber attacks, they usually think about malware, stolen credentials, phishing, ransomware, data theft, or someone in a dark hoodie typing. You know, the usual. Token torching, however, is new and different.

The attacker may not need to exploit a traditional vulnerability or bypass authentication. The request may not even look obviously malicious. In some cases, the request may look completely normal. The system may process it normally and the model may respond exactly how it was designed to respond. This makes token torching difficult to spot. If an AI system has little restriction on token consumption, pulls in a lot of context, calls tools, or performs expensive actions without strict limits, an attacker can turn normal functionality into a cost problem and go relatively unnoticed. Unnoticed until tokens run out or finance starts asking questions. This isn’t a typical breach in the sense of encryption followed by a ransom demand, it's more of an “I made your system light money on fire” attack. 

MCP makes this more complicated

Model Context Protocol, or MCP, is designed to help AI systems connect with tools, data, and services and can be extremely useful. It can make AI agents more helpful, more contextual, and more capable. But more capability also means more ways to spend resources. If an AI system can search data, retrieve documents, call tools, trigger workflows, or pass information between services, attackers may look for ways to abuse those connections. A prompt that seems simple on the surface could cause a lot of activity behind the scenes.

This is where token torching becomes an architecture issue. Because the risk is not just the model writing a long answer. The risk is the entire system around the model doing too much work because no one sets clear limits on what “too much” actually means.

Why are attackers targeting tokens? 

Attackers do not always need to steal something to hurt an organization. Sometimes disruption is enough. If they can force AI systems to burn through usage limits, they may slow down legitimate users. If they can drive up costs, they may create financial pressure. If they can overwhelm systems, they may reduce availability. If they can create enough noise, they may distract security and engineering teams. And if AI is embedded in important workflows, that can be detrimental to an organization. This shifts from being an inconvenience and expensive bill to “our team cannot rely on this system when they actually need it.”

The scary part is that it can look normal

One of the hardest parts of token torching is that abusive usage may not look abusive right away. A user asking for multiple summaries, revisions, or tool-assisted answers may be doing real work. AI systems are literally designed to take messy input and turn it into something useful. I myself am guilty of throwing a poorly worded and verbose prompt into an AI platform. Security teams cannot just block every long request. On the other hand, how do you know which prompts or requests are running up the bill or slowing the system down for real users? By the time you figure it out, the tokens have already been torched.

Organizations need to understand what normal AI usage looks like before they can spot what abnormal usage looks like. What does a normal request consume? Which users, tools, agents, or workflows are the most expensive? Where are the spikes? Where are the loops? Where are the requests that technically worked, but absolutely should not have cost that much? Without that visibility, token torching can hide in plain sight.

Guardrails matter, but they need to be realistic

AI can be incredibly useful, and most organizations are not going to stop using it because attackers found another way to leverage AI. Shocking, I know. Part of defending against such attacks is implementing the right guardrails. That means setting token limits, request limits, rate limits, and cost thresholds. Watching for unusual spikes in usage, limiting how much context can be pulled into a single request, controlling which tools an AI system can access and when, ensuring agents cannot get stuck in expensive loops, and most importantly, logging activity in a way that security, engineering, product, and finance teams can actually understand.

Prompt filtering can help, but token torching is not always about someone typing something obviously malicious. It can be about volume, repetition, automation, excessive context, unnecessary tool calls, poorly bounded workflows, or systems that keep saying yes when they really should stop.

Cost is part of the threat model now

For a long time, cybersecurity conversations focused on confidentiality, integrity, and availability. Is the data protected? Has it been altered? Can people access the systems they need? AI adds another question: how expensive is this interaction allowed to become? That may sound like a finance problem, but it is also a security problem. If attackers can abuse your systems to create significant cost, that is impact. If they can drain usage limits and deny service to legitimate users, that is availability. If they can force teams to disable AI features because costs are out of control, that is operational disruption. Cost has been and continues to be a huge part of risk discussions. 

The real issue is uncontrolled amplification

Token torching is not scary because one person can ask a chatbot a long question. It is scary because AI systems can amplify work really quickly. A single prompt triggers a long response, which triggers more processing. A tool call retrieves more data. More data creates more tokens. An agent repeats steps. A workflow loops. A system can keep spending resources because no one told it when to stop. You get the picture. Attackers are looking for places where AI systems are powerful, connected, and poorly bound. Defenders need to find those places first.

Why this matters

Token torching is a reminder that AI security is not just about jailbreaks, prompt injection, or data leakage. Those risks matter, obviously, but they are not the whole picture. AI systems also create operational risks. When something goes wrong, the impact may show up as cost, latency, degraded service, exhausted limits, or overwhelmed workflows. That does not make AI too dangerous to use. It means AI needs to be managed like the important business system it is becoming. Because when attackers cannot break through the front door, they may look for another way to cause damage. And sometimes, that means making your AI system politely, obediently, and very expensively burn through its own budget.

How Bitsight can help

Token torching is hard to spot as it may not look like a traditional attack. A request can appear normal, the AI system can behave exactly as designed, and the real damage may show up later as cost, latency, exhausted usage limits, or degraded availability. That is why external visibility matters. OWAP recommends controls such as rate limiting, user quotas, resource allocation management, timeouts, throttling, sandboxing, logging and monitoring, anomaly detection, access controls. Bitsight can support this broader risk management effort by helping organizations identify exposed credentials, unmanaged internet-facing assets, shadow infrastructure, and third-party exposures that may make token torching easier to execute. 

• External Attack Surface Management: Bitsight can help organizations continuously map internet-facing assets, cloud services, SaaS exposure, shadow IT, exposed services, and other unmanaged systems. In an AI environment, that visibility can help security teams find infrastructure that may include exposed AI services, developer tools, notebooks, dashboards, agent endpoints, or MCP-connected systems that were not properly governed.
• Attack Surface Intelligence: Bitsight can help discover and classify unknown or unmanaged external assets, giving organizations a clear view of what’s exposed in their supply chain. 
• Identity and Threat Intelligence: Exposed credentials, compromised accounts, leaked access tokens, or developer secrets can create an opportunity for attackers to abuse legitimate access. An exposed credential does not prove token torching is happening, but it is a clear warning sign that an organization may be vulnerable to unauthorized AI usage, cost abuse, or service exhaustion.
• Third-Party Risk Management: Even if an organization has strong internal controls, vendors and partners may still expose systems, credentials, development environments, or software integrations that introduce AI-related risk. Bitsight can help organizations monitor vendor and fourth-party cyber risk across the extended digital supply chain.
• Predictive Threat Prioritization: Not every exposed system carries the same risk, not every critical vulnerability will apply to every organization. Bitsight allows organizations to prioritize external exposures based on threat context, asset visibility, and dark web telemetry that may indicate where an attacker is focused. 

In other words, Bitsight can help by identifying the external exposures, compromised credentials, shadow infrastructure, and third-party risks that make token torching easier. And with the right integrations, those insights could help organizations connect external risk signals with abnormal AI usage before the issue becomes expensive, disruptive, or business-critical.