Acronis denial-of-wallet protection: Managing runaway AI usage before costs spike

Author: Alexander Ivanyuk, Senior Director, Technology

With most cyberattacks, the problem announces itself. A service goes down. A user cannot log in. An alert fires. Denial-of-wallet is different. The application keeps working normally while the cost of running it climbs in the background. That is what makes it a security problem and not only a budgeting one. The goal is not to take a system offline. It is to make the system do expensive work that nobody asked for.

In a GenAI environment, every prompt, response, retry, tool call and agent step consumes billable resources. Most of that consumption is legitimate: employees summarizing documents, drafting responses, analyzing data and troubleshooting issues. The problem starts when usage becomes automated, repetitive or unbounded, because nothing inside the system objects to doing more work than the task required.

For managed service providers (MSPs) and small and medium deployments (SMDs), this matters because GenAI has moved out of experimentation and into daily work. Once technicians, employees, customer-facing assistants and automated workflows all rely on AI, consumption stops being a productivity metric and becomes something that needs monitoring, policy and enforcement.

Denial-of-wallet is related to denial-of-service, but the target is different. A denial-of-service attack exhausts resources so the application becomes unavailable. A denial-of-wallet attack triggers excessive consumption so the organization pays more than it should. The service stays up, the users stay productive and the damage only appears when someone reviews token usage, compute consumption, API calls or the cloud bill.

Button

Button

Industry frameworks now track this as a named risk category, which is a useful signal that it has moved past a theoretical concern. OWASP lists it in the GenAI security Top 10 as Unbounded Consumption (LLM10:2025), a broadened successor to what used to be called Model Denial of Service. MITRE ATLAS tracks the same behavior under AML.T0034, Cost Harvesting. Researchers studying the same effect on inference infrastructure call it an energy-latency attack. The labels differ, but they describe one set of economics: Inference costs money, and inflating it does real damage without breaching anything.

This is practical rather than theoretical because LLM systems run on usage-based pricing. An attacker does not need to break the application. They only need to make it work harder than the task requires, and the system will comply.

In GenAI systems, tokens are the unit that consumption is measured in. A token is a fragment of text processed by the model. Prompts consume tokens, responses consume tokens, and the context window consumes tokens on every turn. Long conversations, large documents, repeated retries and verbose output all push up the count. Agents and automated workflows push it up fastest, because they generate many steps without a human reviewing each request.

That makes token flow the primary signal, and three properties of it matter.

1. Rate: Tokens per minute and per hour.
2. Duration: How long an elevated rate is sustained.
3. Correlation: Whether consumption still tracks the work that is supposed to be driving it.

Any of the three on its own is noisy, because a single long prompt is often perfectly legitimate. Read together, they separate a busy afternoon from a workflow that has stopped producing value and kept spending.

Button

Button

This is a different job from after-the-fact usage reporting. A monthly report tells the organization what happened after the money is gone. In the broader market, runtime controls can look for abnormal consumption while it is happening. Acronis takes a preventive approach at another control point: the prompt itself, as described below.

Not every denial-of-wallet event starts with an attacker. An AI agent is handed a task that sounds simple: analyze a ticket, search for related information, draft a response, update a record. If the workflow has no boundary, the agent keeps asking follow-up questions, retrying tool calls, re-reading content it has already processed, and producing output longer than the task ever required. It is still working. It has simply stopped producing value for the tokens it spends.

Document analysis compounds the same way. A user uploads a large file, asks for a summary, then asks for rewrites, translations, and alternative formats, and each request sends the document through the model again. One person doing this is a rounding error. A team doing it across unapproved tools, or an automation doing it on a schedule, is not.

Prompt injection contributes directly. A hostile instruction does not have to target data or safety rules. It can simply demand length: exhaustive answers, repeated sections, reasoning the question never needed. Nothing leaves the environment, so no data-loss alert fires. The damage lands on the invoice.

As GenAI usage matures, so do the techniques for inflating its cost. The crude version, a prompt telling the model to repeat itself forever, still exists and is the easiest pattern to catch. Recent research describes techniques that do not look like an attack at the prompt level at all.

The clearest example is reasoning-token amplification. Reasoning-capable models generate internal thinking tokens before producing a visible answer, and those tokens are billed at output rates even though the user never sees them. Research published as OverThink (arXiv 2502.02542) showed that decoy problems planted in retrieved context, in one case a Sudoku grid, pushed a model to spend roughly 21,000 reasoning tokens before answering, more than it spent on a genuine Olympiad problem. The visible answer looked entirely normal. Nothing in the output showed where the money went.

A second pattern escalates across turns instead of inside a single prompt. Each message looks reasonable on its own, while the conversation fills the context window and pushes the model toward longer output with every exchange. Because each turn resends the conversation so far, input cost grows as the session lengthens.

Prompt caching reduces that cost but does not remove it, since cached context is still billed, only at a lower rate. The same entry point exists in connected tools: a browsing plugin, a document connector, or an integration feeding content into the model can carry instructions inside what looks like an ordinary tool response. The model processes all of it. The user sees a clean summary and pays for the rest.

A third surface is opening as assistants add image, video and voice generation alongside text. The economics change sharply at that boundary. A single high-quality image generation call costs a few cents against a fraction of a cent for a short text completion, and video generation is higher again. An assistant that can be talked into illustrating every paragraph, or diagramming every item in a list, turns one ordinary-looking request into a bill that no text-only threshold would have caught.

These techniques will keep changing, and the list above will date. What they have in common is unnecessary AI work. At the infrastructure level, one durable defense is to watch whether consumption still matches the work being done. At the prompt layer, another is to stop instructions that clearly or semantically demand excessive, repetitive, or unbounded work before the model acts on them.

Large enterprises run separate teams for cloud cost, security alerting, and application telemetry, and they can absorb a surprise while they investigate it. SMDs cannot. They need a small number of controls that answer three questions: Is AI usage normal, is it unusual, and should it be stopped?

MSPs carry a harder version of the same problem, because they manage many customer environments at once. They need to see consumption patterns across tenants, explain those patterns to customers who did not expect an AI line item, and identify abnormal usage before it arrives as a support ticket or a billing dispute.

That is a customer conversation most MSPs are not having yet. GenAI adoption discussions today cover which tools are approved and whether sensitive data is protected. They rarely cover whether consumption is bounded. The argument fits in one sentence: A customer who would not leave a cloud workload running unmonitored should not leave AI usage running unmonitored either.

Treating denial-of-wallet as a billing problem misses where it comes from. Cost is the visible outcome. The cause is upstream: A manipulated prompt, an unbounded workflow, an automation nobody owns, a credential being used by something that is not a person. Finance sees the number. Only security and IT can explain why it changed.

That is why it belongs with the other GenAI controls rather than in a quarterly cost review. DLP asks whether sensitive data is leaving. Prompt injection protection asks whether the model is being manipulated. Usage monitoring asks where AI is being used and by whom. Denial-of-wallet prompt protection asks whether an instruction is trying to make the AI perform excessive or unbounded work. Four questions, one environment, one set of AI interactions to inspect.

Acronis GenAI Protection helps reduce denial-of-wallet risk as part of a broader GenAI security control model. Instead of monitoring token consumption or runtime cost anomalies, it inspects GenAI interactions for risky content and harmful prompt patterns that can drive excessive or unintended model behavior. This lets Acronis intervene at an important control point: before the risky instruction reaches the AI model.

The first part is visibility and governance. MSPs need to understand which GenAI applications are being used across customer environments and whether that use aligns with policy. Acronis GenAI Protection provides visibility into GenAI adoption and application usage as part of the existing Acronis platform, giving administrators context for policy decisions and review.

The protection itself happens at the prompt level. Acronis analyzes prompts for harmful patterns, including instructions that demand excessive output, repeated work, recursive processing, unnecessary expansion or other unbounded behavior. This is important because the prompt itself can be the trigger for excessive AI work. An attacker or unsafe automation can drive cost simply by making the model do far more work than the business task requires.

When a prompt matches a harmful pattern, Acronis can apply policy before the request proceeds. Prompts designed to trigger excessive or unbounded AI work can be detected or blocked, with the event recorded for review. That preventive control matters because it stops the risky instruction at the point of entry rather than trying to infer a runtime loop from token or billing telemetry later.

Button

Button

Denial-of-wallet protection sits inside the same Acronis GenAI Protection platform as usage visibility, DLP, prompt injection protection, and the AI Security Engine. The analyses are different: DLP looks for sensitive data, prompt injection protection looks for malicious instructions, and denial-of-wallet prompt protection focuses on instructions that can trigger excessive or unbounded AI work. Using the same protection and event model makes these risks easier for MSPs to manage without reconstructing the story across separate tools.

The pattern is easiest to see in a concrete case. An MSP customer uses an AI assistant for support work, where employees ask it to summarize tickets, draft customer updates, and explain technical issues.

A user or automation submits a prompt that asks the AI to produce exhaustive output: expand every ticket field into a detailed explanation, repeat each recommendation in several formats, and continue generating until explicitly told to stop. The request may look like a productivity task, but the instruction pattern is designed to maximize model work rather than complete a useful business task efficiently.

What makes this relevant to denial-of-wallet is the instruction itself. The prompt is asking the model to spend far more tokens and compute than the task requires. The same pattern can appear in malicious prompt injection, poorly designed automation, or accidental over-prompting.

Acronis GenAI Protection analyzes the prompt before it proceeds. If the instruction matches harmful or abusive prompt patterns, policy can detect or block it, the event is recorded, and the MSP has evidence showing which interaction triggered the control. This prevents the risky instruction from reaching the AI model rather than trying to infer the problem later from token or billing telemetry.

Denial-of-wallet is the part of GenAI security that does not announce itself. There is no outage to page anyone, no data leaving the building, and no complaint from availability monitoring. There is only consumption that keeps climbing while everything appears to be working correctly.

The techniques will keep moving, from crude repetition prompts to reasoning-token amplification and poisoned tool responses, which is why OWASP and MITRE ATLAS both track this as a live category rather than a solved one. Acronis addresses an important preventive control point: prompts that attempt to force excessive, repetitive, or unbounded work can be treated as risky before the model spends resources executing them.

For MSPs and SMDs, that is a practical path to safer AI adoption: visibility into GenAI use, clear policy, and prompt-level protection that can stop abusive instructions before they turn into unnecessary AI work.

The goal is simple: keep AI working for the business, not against the budget.