Skip to main content
  • AI Security Academy

    AI Security Academy

    What is AI Security

    AI security is not a neat, one-line definition you can slap on a slide.

    AI Security Glossary

    Explore some of the most common terms in AI Security

    AI Usage Stats

    Explore current AI usage trends.

  • Tools

    AI Security Tools

    OneClaw

    Track and analyze OpenClaw deployments in your org

    ClawSec

    Secure your OpenClaw, NanoClaw, and Hermes agents.

    Prompt Fuzzer

    Get our AI vulnerability assessment open source tool

  • Blog
  • Startup Map
  • Learn More
    Book a Demo
  • AI Security Academy

    AI Security Academy

    What is AI Security

    AI security is not a neat, one-line definition you can slap on a slide.

    AI Security Glossary

    Explore some of the most common terms in AI Security

    AI Usage Stats

    Explore current AI usage trends.

  • Tools

    AI Security Tools

    OneClaw

    Track and analyze OpenClaw deployments in your org

    ClawSec

    Secure your OpenClaw, NanoClaw, and Hermes agents.

    Prompt Fuzzer

    Get our AI vulnerability assessment open source tool

  • Blog
  • Startup Map
  • Learn More
    Book a Demo
Skip to main Content
Back to Blog
AI Risks

Denial of Wallet in AI: When Cost Exhaustion Becomes Downtime

Written by: 
Itamar Golan
January 7, 2024

An attacker does not need to steal data or take control of an AI application to cause damage. They may only need to keep it working until the bill spikes, capacity is exhausted, or legitimate users lose access.

In AI systems, this kind of abuse has a name: denial of wallet. Rather than breaking the application, the attacker forces it to perform expensive work at the organization's expense. As consumption grows, the same attack can become a denial-of-service problem too.

Much of that work happens where the user never sees it, making the prompt only the beginning of the system's total cost.

The Cost Extends Beyond Model Tokens

A single user interaction may consume resources across multiple services:

  • Multiple model calls
  • Large context windows and lengthy outputs
  • Retrieval and vector database queries
  • Image, audio, or video generation
  • Code interpreters and sandbox environments
  • Paid search, data, or software APIs
  • Queued jobs, retries, and background processing

OWASP describes this broader risk as unbounded consumption, which includes uncontrolled resource usage, service degradation, and unexpected financial costs.

Because that work spans multiple services, excessive consumption can create both financial and operational pressure across the application.

When One Request Becomes Many

Agentic systems add another layer of amplification.

AI agents can plan tasks, maintain state, call tools, retry failed actions, and delegate work to other agents. A task that looks small at the application layer may generate dozens of model interactions and tool calls behind the scenes.

Once an agent can call tools and act autonomously, excessive agency and unbounded consumption can compound each other. The more actions an agent is permitted to take, the more cost a task can generate when those actions are repeated or manipulated.

An attacker may try to push an agent into:

  • Repeating a task without reaching a stopping condition
  • Retrying a failing tool call indefinitely
  • Delegating the same work across multiple agents
  • Continuously retrieving or processing new data with no natural endpoint

Uncontrolled workflows can quickly exhaust resources, particularly when multiple agents, models, or external services participate in the same task.

With AI agents, a denial-of-wallet attack may be amplified inside the workflow rather than through a visible flood of incoming requests.

Not Every Cost Spiral Starts With an Attacker

Deliberate abuse is only one side of the problem.

An agent with unclear completion criteria may continue working after it should stop. A failed API may trigger an aggressive retry loop. Two agents may repeatedly hand the same task back and forth. A configuration change may route routine traffic to a more expensive model or tool.

Attackers can exploit missing consumption boundaries deliberately, but the same gaps can produce damaging cost spirals through faulty workflows, configuration errors, or unexpected system behavior.

Controls need to address both. Abuse protections can stop deliberate activity, while architectural limits prevent the application from amplifying mistakes and failures.

Why Request Rate Limits Are Not Enough

Traditional rate limiting measures how often someone reaches the front door. It does not necessarily measure what happens after they enter.

Ten inexpensive requests and ten requests that each launch a multi-step agent workflow should not receive the same treatment. A user may stay within an allowed request volume while still triggering excessive model calls, tool invocations, retries, or downstream costs.

What matters is the work performed throughout the execution path, not just the number of incoming prompts.

Organizations should establish:

  • Per-user and per-tenant limits for requests, tokens, concurrency, and spend
  • Maximum input, output, and context sizes
  • Hard limits on agent steps, tool calls, retries, recursion, and chain depth
  • Timeouts and budgets for external tools and background jobs
  • Least-privilege access to models, tools, and paid services
  • Alerts for unusual cost, latency, failure, or tool-use patterns
  • Circuit breakers or kill switches that stop abnormal workflows

These protections should also be tested. AI red teams need to evaluate whether an application can be manipulated into performing disproportionate work, not only whether its model can be jailbroken or prompted to produce unsafe content.

Protect the Budget and the Service Together

Budget and availability need to be managed as one control problem. In agentic systems, one input can expand into a chain of model calls, tool use, retries, and actions across several systems, allowing a small trigger to produce a disproportionate operational impact.

Security teams need visibility into how each interaction expands across models, tools, and services, along with enforceable limits that stop abnormal activity before it becomes self-amplifying.

Whether the trigger is an attacker, a user, or a faulty workflow, the control objective is the same: no single prompt, user, or agent should be able to trigger unbounded work.

Last Updated:
August 9, 2026

Share this post
Summarize this Post
On This Page

TOC Element

Related Posts

View All Posts

ChatGPT Security Guide: Enterprise Risks, Incidents, and Practitioner Guidance

AI Risks

AI Resources

Jun 29th, 2026

What security teams actually need to know about ChatGPT: data handling, documented incidents, CISO guidance, and API risks.

The Agentic AI Attack Surface: Where Risk Lives Beyond the Prompt

AI Risks

Agentic AI

May 5th, 2026

Technical analysis of agentic AI security boundaries covering content ingestion, context translation, tool execution, and behavioral constraints in AI runtimes.

From Trivy to LiteLLM: Expanding the LLM Supply Chain Threat Model

AI Risks

Industry News

Mar 25th, 2026

The Trivy breach and LiteLLM compromise show how LLM supply chain risk now extends from malicious packages to CI, middleware, prompts, and data.

Log In
Learn More
Book a Demo

Resources

Blog
AI Security Glossary
What is AI Security?
PromptCast: The Voice of AI & Security
ClawSec
OneClaw
Prompt Fuzzer
AI Security Startup Map
© {{year}} Prompt Security. All Rights Reserved.
Privacy Policy
Terms of Service

Follow Us