Rate Limits, Budgets, and Denial-of-Wallet Defense for LLM Apps

Denial of wallet is a resource-governance failure in which malicious use, a defect, a retry storm, or a runaway workflow produces disproportionate model, tool, compute, or third-party cost. It is not a label for every legitimate traffic spike. The defensive goal is to make expensive work intentional, bounded, attributable, and stoppable.

Requests per minute are useful, but insufficient for an LLM application. One request can carry an enormous context, select an expensive model, generate a long response, invoke many tools, start a recursive agent, fetch remote content, or enqueue background work. A practical design controls the whole budget envelope rather than only the front-door request rate.

Map the cost surface before setting limits

Inventory the resources each endpoint and workflow can consume: requests; input and output tokens; context-window size; model tier; agent steps; tool calls; concurrent runs; execution time; retrieval queries; network calls; storage; queue work; external API spend; and retry attempts. Record which principal, tenant, endpoint, tool, model, and job created that consumption.

This inventory separates ordinary demand from failure amplification. A user may make few requests while a planning loop creates dozens of model calls. A retrieval feature may be cheap until a large upload produces many embeddings. An outage can become expensive when every worker retries an already-failing provider. The right limit depends on the workload’s value, reversibility, data sensitivity, and external side effects—not an arbitrary universal dollar amount.

AI resource budget envelope

REQUEST ├─ Token budget ├─ Time budget ├─ Agent-step budget ├─ Tool-call budget ├─ Concurrency budget ├─ External-cost budget └─ Retry budget

Treat these as independent limits with an explicit owner. A token limit protects model usage but not a paid lookup API. A concurrency cap protects shared capacity but not a single long-running job. A retry budget prevents error amplification but cannot replace idempotency. The orchestrator should carry a bounded workflow identifier and decrement the relevant budgets in trusted application code, not ask the model whether it has spent too much.

Apply limits at several scopes

Per-user limits contain a compromised account or abusive client, but shared workspaces need per-tenant limits as well. A tenant budget prevents one customer from monopolizing a provider quota, worker pool, or expensive tool. Global limits protect the application and downstream services when aggregate traffic rises.

Add endpoint and tool-specific limits. A lightweight completion endpoint, an image-generation operation, an open-web fetch, and a code sandbox have different cost shapes. A high-cost or high-impact operation should not inherit a generic chat allowance just because it was proposed in the same conversation. Tie limits to an authenticated principal and tenant, and do not accept usage labels supplied by model output.

For multi-tenant systems, the policy belongs beside the trusted tenant context described in multi-tenant LLM security. It should be possible to see whether a budget was charged to a user, service account, tenant, or internal test workload.

Bound model and agent work

Set maximum input tokens, output tokens, and combined workflow tokens deliberately. Context trimming, retrieval limits, and output-length controls can reduce cost, but do not silently remove information that makes a transaction unsafe. Reject or require a different workflow when the minimum useful context exceeds a policy limit.

Agent systems need a step budget in addition to a token budget. Bound planning cycles, sub-agent spawning, tool iterations, recursion depth, and repeated repair attempts. Put wall-clock deadlines around model calls, tools, and the overall workflow. An agent that has not reached a result within its declared envelope should stop with a clear state, not continue indefinitely because it can still generate another proposal.

Tool-call budgets should cover count, risk class, and expected cost. A model may need several read calls to assemble a report but should not make unlimited paid searches or repeated destructive attempts. Pair budget controls with the containment principles in sandboxing AI agents and generated code: an isolated environment still needs limits on time, processes, egress, and downstream work.

Control concurrency, queues, and retries

Concurrency limits prevent fan-out explosions. Apply them per user, tenant, workload type, and service where needed. A global cap may preserve the provider; a per-tenant cap preserves fairness; a per-tool cap protects a scarce downstream dependency. Queue systems also need bounded depth, worker concurrency, backpressure, job expiration, and cancellation. Queuing an unbounded number of expensive jobs merely moves the denial of wallet into the future.

Retries deserve their own budget. Distinguish transient failures from permanent validation or authorization failures, then limit attempts with backoff and jitter where appropriate. Never retry an irreversible side effect blindly; use idempotency keys and reconcile ambiguous outcomes. When a provider is failing, a circuit breaker can pause a model, tool, tenant route, or workflow after a threshold rather than multiplying charges and latency.

Provider quotas are useful external guardrails, not a complete application policy. They may be shared across tenants, operate on a different time window, or fail only after expense has already accumulated. Track application-level budgets before invoking the provider, and handle quota responses as a signal to degrade or stop safely.

Use hard and soft limits deliberately

Hard limits reject or stop work once a threshold is reached. They fit irreversible actions, strict tenant contracts, unsafe recursion, and service-protection ceilings. Soft limits warn, require confirmation, reduce optional enrichment, delay a batch, or route a low-risk task to a less expensive model. The user experience should be honest: do not silently pretend that a shorter or downgraded result is equivalent to the requested work.

Model routing can be a budget control when a lower-cost class still satisfies a defined task. Keep routing policy visible, test quality for each route, and reserve the expensive tier for cases that justify it. Do not make cost the only criterion when the result controls security, health, legal, or financial decisions.

Possible graceful-degradation actions include shorter outputs, a smaller retrieval set, deferred nonessential enrichment, a lower-cost model for low-risk work, delayed batch processing, or a rejection with a clear retry time. Never degrade by bypassing authorization, removing tenant filters, or executing unreviewed tools.

Detect abnormal use and preserve evidence

Watch for sudden token growth, a rising prompt-to-output ratio, repeated expensive endpoints, tool-loop patterns, a high error/retry ratio, unusual model tiers, many concurrent agent runs, and a tenant’s rapid approach to its budget. Combine cost telemetry with security observability: AI agent observability explains how to connect requester, policy decision, model, tool, and result without indiscriminately storing sensitive content.

Each event should carry a correlation key and enough dimensions to reconstruct cost: principal or workload, tenant, request/workflow ID, endpoint, model, token counts, tool name, queue job, policy decision, result, and estimated or actual spend when available. Protect those records from alteration and avoid logging credentials or full private prompts simply to obtain billing detail.

Denial-of-wallet control matrix

Resource	Failure or abuse mode	Limit	Detection	Response	Evidence
Requests	rapid client abuse	user, tenant, global rate limits	burst and denial rate	throttle or challenge workflow	principal and route
Tokens	oversized prompt or output	input, output, workflow caps	token growth and truncation	reject, shorten, or escalate	model and counts
Agent steps	loop or recursion	step and sub-agent maximum	repeated state/tool pattern	stop run and preserve state	run ID and step count
Tools	paid or repeated calls	per-tool count and spend	tool frequency and errors	disable tool or require approval	tool decision log
Concurrency	fan-out	user, tenant, and global caps	active-run saturation	queue, shed, or cancel	scheduler state
Queue	backlog amplification	depth, TTL, worker limits	age and retry backlog	backpressure or dead-letter	job lifecycle
Retries	provider outage storm	bounded attempts and backoff	error ratio and breaker state	pause dependency	retry history
External spend	unexpected paid API use	workflow and tenant ceiling	spend attribution	block route or notify operator	cost ledger

Operate a stop-capable system

When a workflow becomes abnormal, operators should be able to cancel the run, pause model traffic, disable an expensive tool, reduce concurrency, apply an emergency tenant limit, revoke scoped credentials, and preserve evidence for investigation. Define who can take each action and how the application tells an affected user what happened. A model instruction to stop is not an emergency control.

Run incident drills for a runaway agent, a tool outage, an accidental retry storm, an exhausted tenant budget, and a global provider quota event. After containment, identify the trigger, affected scope, policy gap, cost, and whether retry or attribution data were missing. Add a regression test before restoring the permissive path.

Testing checklist

Test oversized prompts, maximum outputs, rapid requests, high concurrency, recursive plans, repeated tool failures, queue fan-out, cancellation, per-user and per-tenant exhaustion, global ceilings, quota responses, idempotent retries, and legitimate peak traffic. Verify not only that a limit denies work, but that the denial is attributable, safe to retry where appropriate, and does not leak one tenant’s state to another.

Sources

OWASP API Security guidance, OWASP GenAI Security Project, the NIST AI Risk Management Framework, and official model-provider quota documentation provide the control baseline. The resource envelope and control matrix are PermsAI’s architecture synthesis.