Denial of Wallet in LLM Applications: Detecting Resource-Draining Prompts

The short answer

A Denial of Wallet (DoW) attack abuses the cost and capacity model of an AI service. The attacker does not need to break the model. They send inputs that consume excessive tokens, inference time, retries, retrieval work, tool calls, or paid downstream APIs. The result can be a billing spike, exhausted quota, degraded service, or an incident response problem.

The OWASP Top 10 for LLM Applications includes model denial of service as a risk category. Resource exhaustion is not limited to unusually long prompts: a short request can trigger a long agent loop or expensive retrieval path.

Where the cost accumulates

Map the full request path before choosing a detection rule.

One request can multiply across these layers. A prompt that asks an agent to “try again until the result is perfect” may create a loop, while a document-summarization endpoint may spend most of its budget parsing and embedding input before the model answers.

What a resource-draining prompt looks like

Do not rely on a keyword list. Detect behavior and context:

• request size or output budget is far above the user’s normal pattern;
• the same identity submits many near-duplicate tasks in a short window;
• a task creates unusually deep plans, retries, or tool calls;
• a single tenant consumes a disproportionate share of model or API capacity;
• the request mixes a long context with high-cost tools or multimodal inputs;
• an agent continues after a tool timeout or policy denial;
• traffic rotates accounts or IPs while preserving the same workflow signature.

Semantic rate limiting can help, but it should be combined with identity, tenant, route, and cost signals. A legitimate legal or research workflow may be long once; a rotating burst of equivalent workflows is a different pattern.

Controls that work outside the model

Hard budgets

Set maximum input and output tokens, context size, file bytes, image count, plan depth, tool calls, retries, wall-clock time, and concurrency. Enforce the limits in the gateway and orchestrator, not only in a system prompt.

Use separate budgets for interactive users, batch jobs, and internal evaluation. A global limit can make a single customer’s workflow affect everyone else.

Cost-aware authorization

Require stronger approval for expensive models, large context windows, high-cost tools, or external actions. A user may be allowed to ask a question but not to trigger a batch inference job or a paid data-enrichment API.

Adaptive throttling

Throttle by authenticated principal and tenant, then add route and device signals where appropriate. Preserve a safe low-cost response or queue path so abuse does not become a total outage. Do not use IP-only limits as the primary control when traffic can come through shared networks.

Loop breakers

Record a trace-wide step count and stop the workflow when the maximum is reached. Treat repeated tool arguments, alternating failures, and unchanged context as signals to pause for human review. A timeout should reduce authority, not trigger unlimited retries.

Billing and quota alerts

Compare actual spend and token use with a baseline for the same route, tenant, model, and time period. Alert before the provider quota is exhausted. Keep a runbook for disabling a route, lowering the model tier, revoking a credential, and preserving evidence.

Detection engineering

Create a per-request cost envelope:

estimated_cost = input_tokens × input_rate
               + output_tokens × output_rate
               + tool_costs
               + retrieval_cost

The exact rates change by provider, so store the rate card version with the event. The envelope is an estimate used for control; it is not a substitute for the provider invoice.

At minimum, emit a trace ID, principal, tenant, route, model digest, input/output token counts, duration, step and retry counts, tool calls, estimated cost, limit decisions, and final status. Redact prompt content unless a documented investigation requires a protected copy.

Useful alerts include:

• a sudden increase in p95 tokens or duration for one route;
• a tenant crossing its rolling cost envelope;
• repeated requests that reach the same maximum step or timeout;
• high tool-call volume with little successful business output;
• cost or token use continuing after user cancellation.

Safe test methodology

Use a staging provider account or a local model with synthetic data. Define a small budget and an automatic stop condition before testing.

1. Establish normal token, duration, step, and tool-call ranges for each workflow.
2. Submit approved long-context, repeated, and recursive test cases at low volume.
3. Verify that gateway and orchestrator limits trigger before provider quotas.
4. Confirm that the event reaches monitoring with the correct tenant and trace ID.
5. Exercise cancellation, credential revocation, queue cleanup, and recovery.
6. Record false positives: legitimate large jobs should be handled by an approved batch path, not silently blocked.

Never test a live account by intentionally creating a bill spike. A bounded test demonstrates the same control path without transferring risk to customers.

Metrics for a mature control

Track rejected and completed requests by reason, p95 and p99 tokens, average steps per successful task, cost per business outcome, time to alert, time to throttle, and time to recover. Review the metrics by tenant and workflow; global averages hide abuse.

The CVSS value in this article is a reference for a potential high-impact resource-exhaustion scenario. The final severity depends on authentication, quotas, financial exposure, and whether the service remains available.

Frequently asked questions

Is every long prompt an attack?

No. Length is one signal. Context, identity, repetition, tool use, and cost determine whether the behavior is suspicious.

Should a WAF block resource-draining prompts?

A WAF can enforce basic request-size and rate rules, but it cannot see token use, agent steps, or downstream tool cost by itself. Pair it with application and provider telemetry.

Can model-side token limits solve DoW?

They reduce one cost path but do not stop retries, retrieval, image processing, or external tools. Budgets must cover the complete workflow.

What should happen when a limit is reached?

Stop or queue the task, return a clear error, emit an auditable event, and preserve a safe recovery path. Continuing silently is the failure mode to avoid.

Related reading

• Automated Red Teaming for Agentic AI Workflows
• Securing Agentic AI: Where MLSecOps Meets DevSecOps
• AI Security Risk Report: Fast-Growing Runtime Threats