Safeguard
AI Security•

Denial of wallet: spend controls for LLM applications

Denial of wallet means attackers or bugs run up pay-per-use inference bills. The OWASP controls: limits, quotas, timeouts, alerts, graceful failure.

Safeguard Security Team
3 min read

Denial of wallet is when high volumes of operations exploit pay per use pricing until the cost is unsustainable. OWASP lists it under Unbounded Consumption. The defence is a set of ordinary limits applied early: input size caps, per user quotas, timeouts, anomaly alerts and graceful degradation.

What OWASP describes

Unbounded Consumption happens when an application lets users run excessive, uncontrolled inferences. Outcomes include denial of service, economic loss, model theft and degraded service. The page notes that the compute demands of LLMs, especially in cloud settings, make them easy to exploit.

Related patterns from the same page:

  • Floods of inputs of varying length.
  • Inputs that repeatedly overflow the context window.
  • Resource heavy queries that run long or fail.

Controls that map to each

  1. Input limits. Validate inputs against reasonable size limits before they reach the model.
  2. Rate limits and quotas. Per user, per key and per tenant, so one source cannot consume the budget.
  3. Timeouts and throttling. Cap processing time for expensive operations.
  4. Monitoring. Log resource use and alert on unusual consumption.
  5. Graceful degradation. Limit queued actions and fail safely under load.
  6. Sandboxing. Restrict the model's network and internal service access.

OWASP also recommends strong access controls and a centralised model inventory, which makes it possible to know what is running up the bill.

Do not forget agents

Loops are a quiet cause of spend. An agent that retries a failed tool call, or two agents that hand work to each other, can burn through a budget with no attacker involved. Set a maximum number of steps and a maximum spend per task, and stop the run when either is hit.

Where to set the limit

Put hard caps in your own gateway or service, not only in a provider dashboard. Provider side alerts are useful for noticing a problem, but your application should refuse work once a user or a task passes its budget.

Pick numbers by measuring normal use first. Set the cap above the heavy but legitimate user, then review it monthly. Pricing and limits change, so check your provider's current terms rather than copying a figure from an article.

Safeguard's usage and policy controls are aimed at the software side. For LLM spend, keep cost enforcement in your own request path.

Alerts that help. Set alerts at several levels: spend per hour, spend per key and spend per task. A single monthly threshold tells you about a problem after the money is gone. Add an alert for a sudden change in average tokens per request, which often signals a prompt change or a loop. Test the kill switch before you need it, so that someone on call knows how to disable a key or a feature quickly.

Quick check

Is this only a cost problem?

No. OWASP also lists service degradation and denial of service among the outcomes.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.