Detecting Denial-of-Wallet Attacks Against Customer-Facing AI Agents

What Denial-of-Wallet means for agentic AI

OWASP's AI Agent Security Cheat Sheet lists Denial of Wallet (DoW) as a key risk and describes it as attacks that cause excessive API or compute cost through unbounded agent loops. OWASP community guidance maps it to LLM10:2025 Unbounded Consumption. The category is consumption abuse, not data theft or model compromise. The attacker needs no access to anything sensitive. Making each call expensive, or making the agent call more often than it should, is enough.

Customer-facing agents are exposed because they hand metered resources to anonymous or low-trust users. One request can trigger model inference, several tool calls and downstream API invocations, and each carries a price. OWASP community guidance describes the attacker as inflating cost per call rather than degrading serve rate. Availability dashboards stay green while cost climbs, so the attack resembles legitimate demand.

That is why this is a runtime security problem. A budget alert reports that money was spent. It does not stop the loop that is spending it.

Signals that separate abuse from legitimate demand

OWASP guidance names a small set of monitoring signals: tokens-per-request outliers, P99 latency, cost per call measured against an SLO, and tool-loop depth. These are a sound starting point because they sit at the interaction and tool-call level, where the cost is created. Aggregate request volume is a weak signal on its own, since a successful campaign and a legitimate spike both raise it.

Other signals follow from how the attacks work. They are engineering judgment rather than published thresholds, so calibrate each against your own baseline traffic and expect false positives. A long-document workflow or a popular launch can look like abuse on any single measure, which is why signals work best in combination.

• Tokens per request and per session: Outliers against the normal distribution for the same agent and user tier. Sponge-style inputs aim to maximize tokens consumed per call.
• Request-to-output ratio: Short prompts that provoke very long outputs, or the reverse, suggest inflation. Legitimate summarization and generation tasks can also produce skewed ratios.
• Tool-call recursion and fan-out: Loop depth, repeated identical calls and one request spawning many downstream invocations. A depth cap turns this signal into a hard limit.
• Anomalous context length: Inputs or accumulated context far above what the use case needs. Compare against the agent's purpose, not a global number.
• Identity and session patterns: New, unverified or anonymous identities with high session counts, high concurrency or uniform timing. Treat trust level as an input to every threshold.

From detection after the fact to enforcement at runtime

Detection that only reports is a forensic tool. Enforcement means a detected condition changes what happens to the next interaction or tool call, in the same path. Three actions cover most cases.

Rate limiting is the default for ambiguous signals. OWASP guidance recommends per-tenant limits on tokens, requests, concurrency and spend, and, in agent payments guidance, stricter limits for unverified or low-trust identities than for verified ones. Applying that idea to anonymous customer users is an inference, but a reasonable one. Returning remaining quota and reset time lets legitimate clients adjust.

Blocking suits unambiguous conditions, such as a tool-loop depth cap being exceeded. OWASP's bot management guidance includes a section titled "Response Strategy: Don't Always Block", a useful reminder that graduated responses protect real users from false positives.

Escalation for human approval fits high-cost actions where the signal is suspicious but not conclusive. OWASP community guidance also suggests keeping a rules-based fallback ready as a kill-switch, so a full stop does not mean a full outage. Test these thresholds before deployment with sponge-input exercises.

What a detected incident should leave behind

A Denial-of-Wallet event should leave a record that lets someone reconstruct it without relying on memory. As a practical baseline, retain the identity and trust tier involved, the signal that fired and its threshold, the interaction or tool call affected, the policy that applied, the action taken (allow, rate limit, block or escalate), who approved or declined any escalation, and timestamps. Retain the policy version too, so a reviewer can tell what the rules were at the time.

This is a recommendation based on incident response practice, not a requirement drawn from a specific framework. Map it to your own incident response procedures and your NIST AI RMF program.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Policy actions include allow, redact, block, rate limit and escalate for human approval, enforced at runtime, not reviewed after the fact. That enforcement generates audit-ready evidence mapped to frameworks including NIST. Correlating coordinated activity across many anonymous sessions still depends on identity and edge telemetry alongside the enforcement point.