Model Denial of Service: The Costly Loop Bug Quietly Draining LLM Budgets 💸

In November 2025, a production multi-agent pipeline got stuck in a loop — agents endlessly re-checking each other's output.

Nobody caught it for 11 days.

The bill: $47,000.

No breach. No stolen data. No malware. Just a loop that was never told to stop, burning tokens every second nobody was watching.

This is Model Denial of Service — and in the 2025 OWASP Top 10 for LLM Applications, it was renamed and widened from the old LLM04:2023 "Model Denial of Service" into LLM10:2025 "Unbounded Consumption" — one risk category now covering outages, denial-of-wallet, and even model theft via excessive querying.

⚡ Why It's Not Like Normal DoS

Classic DoS floods a server until it falls over. Model DoS floods a billing meter until your company does.

LLMs are billed per token — input, output, even internal "thinking" tokens. Nothing needs to break. The system just needs to keep generating. Across the industry right now, the conversation has shifted from writing good prompts to designing the loops that run them — which quietly makes a bad loop a bigger risk than a bad prompt.

🔄 Three Ways a Loop Gets Expensive

1. Tool-call loops 🛠️ Agent calls a tool → gets an unclear or empty result → retries → repeats. One reported case had an agent call the same file-listing function 14,000 times in a single overnight run — a classic symptom of a tool that never returns a clean "done" signal.

2. Reasoning loops 🧠 No tools involved at all — the model just keeps "thinking." One documented case logged 847 reasoning steps at roughly $47/minute, without ever producing a final answer.

3. Context-accumulation loops 📈 Every step in an agent loop resends the entire conversation so far. By step 20, you're re-paying for the same 8,000+ tokens you already paid for at step 1. That's a core reason agents now burn roughly 50x more tokens than a single chat turn for equivalent work.

🚨 It's a Filed, Real Vulnerability — Not Theory

CVE-2026–55446: an unauthenticated DoS in Langflow, filed under CWE-400: Uncontrolled Resource Consumption. One request, oversized multipart form boundary, zero login required — and the app became unusable for every user, indefinitely.

If you test LLM-backed apps for a living, this is one of the easiest categories to actually prove end-to-end — no exploit chain needed, just patience and a timer.

Test it responsibly: stay inside scope, confirm the target's tolerance for repeated or heavy requests before you send them. The goal is proving the gap exists, not actually taking the service down.

🛡️ How to Actually Stop It

A billing alert is not a defense. By the time the email lands, the loop has already run for another twenty minutes.

✅ Enforce limits outside the agent — never just in its system prompt. A task-motivated agent will ignore "stop at $10" the moment stopping gets in the way of finishing. ✅ Hard iteration caps — e.g. max 3–5 tool calls per task, no exceptions. ✅ Circuit breakers on token velocity, not just request count. ✅ Repetition detection — same tool, same arguments, three times in a row = kill the session. ✅ Context pruning + prompt caching, so step 20 isn't re-billing step 1. ✅ Tiered hard caps: soft alert → forced downgrade to a cheaper model → full stop requiring human approval.

A minimal version, in code:

if session.tokens_spent > budget_cap:
    halt_agent()
if same_tool_call_repeated(times=3):
    halt_agent()

if session.tokens_spent > budget_cap:
    halt_agent()
if same_tool_call_repeated(times=3):
    halt_agent()

Two lines. Most production agents still don't have them.

📌 TL;DR

Model DoS doesn't need an attacker. A confused agent and a missing stop condition are enough. The fix isn't "watch the bill" — it's making the loop physically incapable of continuing past a hard limit.

I catalog real-world vulnerabilities like this — across web, API, mobile, cloud, and AI/LLM security — inside 150DaysWithAppSec: 300 vulnerabilities, one repo.

Anand Prajapati 🔗 LinkedIn: linkedin.com/in/anand-prajapati-7a265a369 🔗 GitHub: github.com/anand87794