Is this only a risk for public-facing AI applications, or does it apply to internal tools too?

Internal tools are exposed too, through a different threat model. A public-facing application faces external attackers; an internal tool faces the risk of a misconfigured or compromised internal service, a runaway agent loop with no termination condition, or simply an employee unaware that a particular usage pattern, batch-processing a large document set through a reasoning-heavy model configuration, is generating cost far beyond what the task justified. The economic mechanism, cost committed per token regardless of intent, applies equally whether the requester is malicious, compromised, or just uninformed about what a request actually costs.

Can provider-side spending caps solve this without needing a request-layer control?

Provider-side spending caps are a real and useful backstop, and most teams should have them configured regardless of anything else. Their limitation is granularity: a global account-level cap stops the bleeding once the entire organization's budget is exhausted, but it cannot distinguish between one compromised identity driving the spend and normal usage across every other legitimate user, and it typically triggers only after a meaningful fraction of the budget is already gone. Per-identity, per-request policy evaluated before the call is a finer-grained control that can stop a single bad actor without capping everyone else's access.

How does this attack class relate to prompt injection?

They can compound, though they are mechanically distinct. Prompt injection can be a vector for triggering a denial-of-wallet pattern indirectly, for example, injecting an instruction that causes an agent to enter a recursive loop or repeatedly re-process a large document, which turns a content-manipulation attack into a cost-amplification one. The defenses are related but not identical: injection defenses focus on what content a model is allowed to treat as instructions, while denial-of-wallet defenses focus on consumption volume and request cost regardless of how that consumption was triggered.

What does a reasonable consumption policy actually look like in practice?

A reasonable starting policy sets a maximum context size and maximum output length appropriate to each use case, a per-identity request-rate ceiling calibrated to that identity's normal usage pattern rather than a single organization-wide number, and an explicit cap on recursive or chained calls for any agentic workflow, since unbounded agent loops are one of the least-monitored cost sources in current deployments. The specific numbers depend entirely on the use case; the structural point is that the policy needs to be enforced per identity and per request type, not as a single blanket limit that either blocks legitimate heavy users or fails to catch a narrow but expensive abuse pattern.

LLM Denial of Wallet Does Not Need to Overwhelm Anything

In 2021, The Register covered a paper describing a "theoretical Denial-of-Wallet attack" against serverless cloud functions, a decade after the term itself first appeared. The logic was economic, not architectural: pay-per-invocation billing means an attacker does not need to exhaust a server's capacity the way a traditional denial-of-service attack does. They only need to trigger enough billable invocations to make the bill unsustainable. OWASP's current LLM10:2025 category, Unbounded Consumption, applies the identical logic to pay-per-token LLM APIs, and the underlying economics have not changed at all in the decade between them.

TL;DR

LLM denial of wallet exploits pay-per-token pricing, not compute capacity, so it does not require overwhelming anything to be damaging.
The term predates generative AI: a 2021 Register piece traced the same economics in serverless cloud billing.
Expensive individual requests, long context, recursive agent loops, complex reasoning, drain a budget at normal traffic volume.
Cost accrual is committed the moment a request reaches the model, which means the only place to cap it is before that point.

Why this is not the same problem as a traditional DoS

A traditional denial-of-service attack degrades availability by overwhelming capacity: enough simultaneous requests that legitimate traffic cannot get through. Denial of wallet does not need that volume, because the target is not capacity, it is the bill. A relatively modest number of requests, each engineered to be maximally expensive, a long input context, a request that triggers an extended reasoning chain, an agent loop that calls the model recursively before returning, can generate a cost impact wildly disproportionate to the request count.

This distinction matters operationally because the monitoring most teams already have, request-rate alerting, capacity dashboards, is built to catch volume-based DoS. It is not built to catch a low-volume, high-cost-per-request pattern, which can run for hours generating an enormous bill before anyone notices a problem, because nothing about the traffic pattern looks anomalous by request-count metrics alone.

Where the expense actually comes from

Three request shapes account for most of the documented cost-amplification patterns. Long-context requests exploit models that accept very large context windows, where cost scales with tokens processed, so a request stuffed with maximum-length input costs proportionally more regardless of what it actually asks. Reasoning-heavy requests exploit models with extended reasoning or chain-of-thought modes, where the model's internal token generation before it produces a visible answer is billed the same as visible output, sometimes generating far more billable tokens than the user-facing response suggests. Recursive agent loops exploit multi-step agent architectures where a single triggering request can cause the agent to call the model many times in sequence, pursuing a task, each call billed independently, before the loop terminates or hits an internal limit, the same runaway-loop failure mode covered in agentic AI runtime security.

None of these three requires an attacker to find a bug. Each is a legitimate capability of the system used at its most expensive setting, repeatedly, which is what makes the pattern hard to distinguish from a legitimate heavy user without a policy that actually looks at consumption per identity.

Why the fix has to happen before the model call, not after

The defining property of this attack is that the cost is committed the instant the request reaches the model API. A provider bills for tokens processed regardless of whether the resulting output turns out to be useful, malicious, or ignored entirely. Rate limiting or budget alerts configured to fire after a spend threshold is crossed are a detection control, useful for stopping an ongoing attack from getting worse, but they cannot undo the spend that already happened before the alert fired.

The only point in the request lifecycle where cost accrual can actually be prevented rather than merely detected is before the request leaves the calling application's boundary: evaluating whether this identity, at this volume, requesting this context size or reasoning depth, is consistent with policy, and denying the request if not, before it becomes a billable call. That is the same before-the-model timing argument behind inline enforcement generally: a blocked request never reaches the model, and in this case, never reaches the invoice either.

DeepInspect

This is the specific control DeepInspect enforces at the one point where a decision still changes the outcome: the HTTP request on its way to the model. DeepInspect evaluates every outbound call against identity and policy before the request reaches the model API, which means consumption limits, maximum context size, request frequency per identity, recursive-call thresholds for agentic workflows, are enforced as a pass or block decision at the one moment the cost has not yet been committed.

Every decision, permitted or denied, writes a signed per-decision record, so a finance or security team investigating an unusual spend has an exact account of which identity generated which calls, at what volume, and which the gateway denied before the meter started running. That record is also what separates an actual attack from a legitimate heavy workload that policy needs to be adjusted for, a distinction that raw billing data alone does not make, and it is the same action-lineage record a runaway agent investigation needs regardless of whether cost or data exposure is the concern.

If your AI spend has ever spiked without a corresponding spike in request count, that gap between requests and cost is worth investigating before it happens again. Book a demo today.