Denial-of-Wallet and AI Agent Cost Runaway: Limits

Pay-per-use AI services turn every uncontrolled request into a bill, so an attacker, a stolen key or a looping agent can run up large costs long before a monthly budget alert fires. Denial-of-wallet (DoW) is the deliberate version: an attacker drives volume to exploit the cost-per-use model, which OWASP lists as an example of LLM10:2025 Unbounded Consumption. AI agent cost runaway is the self-inflicted version: an agent that retries, loops, fans out or reserves far more tokens than it needs. Both are stopped by the same controls: limits enforced close to the request, keyed on identity, with detection that works in minutes rather than the day or more that billing data can take. This guide covers cost drivers, why cloud budgets are alarms rather than brakes, a layered limit design, detection and response, and how to measure it. It is for platform, FinOps, AI engineering and security teams running LLM applications or agents on metered APIs.

Key takeaways

Budgets alert, they do not stop. Azure states budgets do not affect resources or stop consumption, and a Google Cloud alerts-only budget does not cap spending. Hard stops need provider spend limits, gateway quotas or automation you build.
Billing data is too slow for DoW. Azure cost data typically arrives within 8 to 24 hours and AWS Cost Anomaly Detection can take up to 24 hours to see an anomaly. Detect from token counters at the gateway, not the invoice.
Limit per identity, not per organisation. One shared key or project means one runaway agent or one stolen key consumes everyone's budget. Key quotas on the agent, user or tenant.
Stolen credentials are the main DoW path. LLMjacking and the Sourcegraph incident both turned leaked keys into someone else's compute. Key hygiene is cost control.
Retries multiply cost silently. Failed requests still count against rate limits, SDK and application retries stack, and spend-cap errors should never be retried.

Denial-of-wallet and cost runaway explained

OWASP LLM10:2025 Unbounded Consumption describes applications that allow excessive and uncontrolled inference, leading to denial of service, economic loss, model theft and service degradation. Denial of wallet is one of its listed examples: a high volume of operations that exploits the cost-per-use model of cloud AI services. MITRE ATLAS tracks the attacker behaviour as AML.T0034 Cost Harvesting, and service disruption as AML.T0029 Denial of AI Service. When the attacker is using your cloud account rather than your application, ATT&CK v20 covers it as T1496.004 Cloud Service Hijacking under Resource Hijacking.

Scenario	Who pays	Entry point	Key control
External DoW against an AI feature	You, through your provider bill	Public chatbot, API or agent endpoint	Per-user and per-tenant token quotas, input size limits, authentication
Stolen or leaked API key (LLMjacking)	The key owner	Key in a repository, image, log or endpoint	Secret scanning, short-lived credentials, per-key quotas, usage alerts
Compromised cloud account	The account owner	Cloud access keys used to call managed model services	Restrict who can invoke models, service control policies, anomaly alerts
Agent cost runaway	You	Loop, retry storm, fan-out, oversized context	Turn caps, per-run token budgets, concurrency caps
Hijacked agent	You	Prompt injection that makes the agent do expensive work	Per-run budgets, tool allow lists, input provenance
Model extraction by volume	You, plus loss of IP	High-volume structured querying	Rate limits, output restrictions, anomaly detection

The serverless version of DoW, where function invocations rather than tokens are the meter, is covered in the Serverless Security Guide.

What actually drives the bill

Cost controls fail when they meter the wrong thing. A request count limit does little against one request with a huge context; a monthly token quota does little against a burst that spends it in an hour.

Input tokens and context growth: agents resend conversation history and tool results on every turn, so cost per turn grows as the run gets longer. OWASP LLM10 lists continuous input overflow, inputs that exceed the context window, as a vulnerability example.
Output tokens: usually priced higher than input. On Amazon Bedrock some models consume TPM quota at an output burndown rate of 5x, 10x or 15x, although billing is for actual tokens only.
max_tokens reservation: Bedrock reserves input tokens plus max_tokens against the TPM quota when a request starts and returns the unused part at the end; OpenAI calculates rate limit usage as the larger of max_tokens and the estimated token count. An oversized max_tokens exhausts quota and concurrency early. Anthropic states that max_tokens does not affect its output token rate limit, so behaviour differs by provider.
Retries: OpenAI notes failed requests still count toward per-minute limits and warns that application retries on top of SDK retries multiply requests.
Tool calls and downstream services: each agent tool call can trigger search, vector store, code execution or third-party API charges that never appear in token counts.
Fan-out: an orchestrator that spawns a sub-agent per item turns one request into hundreds of model calls.
Embeddings and ingestion: Bedrock throttles embedding models by requests per minute rather than tokens, and OpenAI applies a separate limit to vector store file ingestion. Bulk ingestion jobs need their own caps.

Why cloud budgets are alarms, not brakes

Most teams discover during their first incident that the budget they configured only sends email. The table summarises what each control actually does, from the providers' own documentation.

Control	Stops spend?	Latency and caveats	Use it for
Azure Cost Management budgets	No: resources are not affected and consumption is not stopped	Cost data typically within 8 to 24 hours; budgets evaluated every 24 hours; action groups (subscription and resource group scope) can call Azure Functions or webhooks	Backstop alert and trigger for custom automation
Google Cloud alerts-only budget	No: does not cap usage or spending	Several hours before the first notification; Pub/Sub messages several times a day; spend cap budgets exist for eligible services and pause them until lifted	Alerts, and Pub/Sub automation such as disabling billing on a project
AWS Budgets actions	Partly: can apply an IAM policy or SCP, or target specific EC2 or RDS instances	Runs automatically or after manual approval; depends on billing data refresh	Deny further provisioning or invocation after a threshold
AWS Cost Anomaly Detection	No	Runs about three times a day; detection can take up to 24 hours after usage; new services need 10 days of history	Catching unexpected services, accounts or regions, including third-party Bedrock models
OpenAI spend alert and hard spend limit	Alert: no. Hard limit: yes, requests return HTTP 429	Organisation and project scope; separate from the approved monthly usage limit	Project-level ceiling per application or agent group
Anthropic spend limits	Yes	Tier cap returns 429 with no `retry-after`; a customer-set limit returns 400; workspace limits isolate groups, but the default workspace has no spend limit	Per-workspace ceilings for teams or agent families
AI gateway token quota (for example Azure API Management `llm-token-limit`)	Yes, per counter key	`tokens-per-minute` breach returns 429, `token-quota` breach returns 403; concurrent requests can briefly exceed; each gateway counts independently	Per-agent, per-user or per-tenant enforcement

Disabling billing is a last resort: Google's documented pattern of removing the billing account from a project with a Cloud Run function shuts down all resources, may lose them permanently, and still incurs charges because notifications are delayed. Use it only on isolated sandbox projects.
Automation needs privileged identities: the Google example grants the function's service account Billing Account Administrator, and AWS Budgets actions need a role able to attach policies. Treat those identities as privileged NHIs and restrict who can change them.

A layered limit design

No single limit is fast, fine-grained and impossible to bypass. Layer them so each catches what the one above misses, and set every layer below the one above it.

Layer	Limit	Enforced by	Catches
Request	Maximum input size, sensible `max_tokens`, timeouts	Application and gateway	Oversized inputs, expensive single calls
Run	Maximum turns, graph steps, tokens and tool calls per run	Agent framework (for example `max_turns`, `recursion_limit`) and gateway	Loops and runaway agents
Agent identity	Tokens per minute and per day, concurrency	AI gateway keyed on agent identity	Fan-out, hijacked agents, misbehaving releases
User or tenant	Tokens and requests per period	AI gateway or application	External DoW, abusive users, free-tier abuse
Project or workspace	Hard spend limit and rate limits	Model provider	Gateway bypass, stolen project keys
Cloud account	Who may invoke models; budget actions; anomaly detection	Cloud IAM, SCPs, budgets	Compromised cloud credentials, unexpected regions
Compute	Function or container concurrency	Platform (for example AWS Lambda reserved concurrency)	Serverless fan-out

Choose the counter key carefully: APIM's counter-key accepts a policy expression; key it on the agent's or tenant's identity, not on a shared subscription, or one caller exhausts everyone's quota.
Estimate before the call where it matters: with estimate-prompt-tokens set to false, a prompt can reach the backend after the limit is exceeded and only later requests are blocked. Estimating first avoids backend cost at some performance cost.
Cap total actions: OWASP LLM10 recommends restricting queued and total actions, not only rates. A per-run token budget stops a slow loop that never trips a per-minute limit.
Degrade gracefully: when a limit trips, fall back to a cheaper model, a cached answer or a queued job rather than an outage, as OWASP LLM10 also advises.

Approval thresholds for agents that spend money directly (purchases, payments, paid APIs) belong in the AI Agent Action Approvals and Spending Limits Guide. For gateway placement and features, see the AI Gateway and LLM Gateway Guide.

Retries, backoff and error handling

Honour Retry-After: OpenAI and Anthropic both return it on temporary limits. Treat it as a minimum wait and add jitter.
Fall back to capped exponential backoff: cap both the number of attempts and total retry time, as OpenAI advises.
Never retry spend or quota errors: Anthropic's tier spend-cap 429 has no retry-after and retries fail until access resumes; OpenAI says quota and billing errors need user action. An agent that treats these as transient will loop.
Count retries once: if the SDK retries and your orchestrator also retries, and the agent then re-plans the failed step, one failure can become dozens of calls. Disable one layer or make them aware of each other.
Ramp gradually: both providers apply acceleration limits that can return 429 on sharp increases within normal limits. A batch job that starts at full speed will retry storm itself.

Where identity fits

Most real DoW events start with a credential. In the LLMjacking cases, attackers used stolen AWS access keys to call Bedrock InvokeModel and resell access, with more than 75,000 invocations logged in a short period. In August 2023 Sourcegraph disclosed that a site-admin token committed to a repository was used to raise API rate limits for some users, and a proxy app let others call its APIs and the underlying LLM; Sourcegraph responded by temporarily reducing free-tier rate limits and expanding secret scanning.

Keys are spending authority: treat every model API key as a payment instrument with a limit. Store it in a secrets manager, scope it to one project and rotate it. See the LLMjacking Guide.
Restrict model invocation in the cloud: only named roles should be able to invoke managed models, and an SCP or IAM deny can block regions and models you do not use (ATT&CK T1078.004 Cloud Accounts is the access path).
Protect limit configuration: whoever can raise a rate limit or spend limit can authorise unlimited spend, as the Sourcegraph token showed. Put limit changes behind privileged access and alert on them.

Detection and response

Detection must run on near-real-time usage data. Billing and anomaly services remain useful as a backstop, for spend outside the gateway, but their latency is measured in hours.

Gateway token telemetry: tokens consumed per agent, user, tenant and model per minute, with alerts on sudden ratio changes against the previous hour and day.
Provider response headers: OpenAI x-ratelimit-* and Anthropic anthropic-ratelimit-* headers show remaining capacity; a fast-falling remainder is an early warning. Anthropic also returns anthropic-workspace-id, useful for attribution.
Limit events: every 429, 403 quota response, MaxTurnsExceeded or budget threshold should be a metric, not just a log line.
Cloud audit logs: model invocation calls from unexpected principals, regions or source addresses; LLMjacking reporting describes attackers testing Bedrock in several regions.
Configuration changes: raised quotas, new projects or workspaces, new keys and removed limits.

Trigger	Automated response	Human follow-up
Single agent above token rate	Throttle that agent at the gateway	Review recent runs and prompts
Per-run budget exceeded	Terminate run, preserve state	Fix the loop or stop condition
Usage from unknown principal or region	Disable the key or apply an IAM deny	Treat as credential compromise, rotate and investigate
Tenant or user abuse	Apply quota, require stronger authentication	Review terms and abuse handling
Project spend at threshold	Budget action or provider hard limit	Decide whether to raise the limit with an owner's approval
Serverless fan-out	Set reserved concurrency to 0 to stop processing	Fix the trigger, then remove the throttle

Containment for a misbehaving agent, beyond cost, is covered in the AI Agent Kill Switch and Containment Guide, and the behavioural signals in the Rogue and Runaway AI Agent Detection Guide.

Choosing controls for your size

Provider limits or a gateway: provider spend limits are simple and impossible to bypass for keys in that project, but coarse. A gateway gives per-agent and per-tenant control but can be bypassed by anyone holding a direct provider key. Use provider limits as the ceiling and the gateway for fine-grained control, and do not issue direct keys to agents.
Small organisations: one provider project or workspace per application with a hard spend limit, sensible max_tokens, turn caps in the agent framework, and a daily usage email. This covers most runaway risk without a gateway.
Large organisations: central AI gateway with identity-keyed quotas, workspaces per business unit, budget actions and anomaly detection per cloud account, chargeback by agent identity, and SOC alerts on configuration changes.
Public, unauthenticated AI features: the highest DoW exposure. Require sign-in or bot protection, strict per-session quotas and input size limits; see the Rate Limiting and API Abuse Guide.
Batch and background work: OpenAI suggests the Batch API for non-urgent work so it does not consume synchronous limits; give batch jobs their own project and limits so they cannot starve interactive traffic.

Implementing limits step by step

Map spend paths. List every model provider, project, workspace, key and cloud account that can incur AI cost, and who owns each.
Set hard ceilings first. Apply provider spend limits per project or workspace, including the default workspace, and budget alerts with actions per cloud account.
Measure normal usage. Collect tokens per run, per agent and per tenant for two to four weeks with limits in log-only mode.
Introduce identity-keyed quotas. Route traffic through the gateway, set per-agent and per-tenant limits at a multiple of observed peaks, and enable blocking in a pilot ring.
Fix retry behaviour. Audit SDK and application retry settings, add jitter and caps, and stop retrying spend errors.
Wire detection and automation. Alerts on rate changes, limit events and configuration changes; automated throttle for single agents.
Test. Run a controlled loop and a simulated stolen-key burst in a sandbox project and confirm each layer trips and alerts as designed.
Plan rollback. Document how to raise a limit quickly with owner approval when a legitimate peak is blocked, and log every such change.

Measuring whether it works

Coverage: percentage of AI spend flowing through a project or gateway with a hard limit. Target 100%.
Time to throttle: from start of abnormal consumption to automated throttle. Minutes for gateway-detected events.
Cost of the largest incident: spend from the worst runaway or abuse event per quarter, compared with your per-agent ceiling.
Retry ratio: retried requests as a share of all requests per agent. A rising ratio predicts runaway cost.
Attributed spend: share of AI spend attributable to a named agent, tenant or user. Unattributed spend is where stolen keys hide.
Unauthorised limit changes: quota or spend limit increases without an approved request. Should be zero.

Framework mapping

Framework	Reference	Relevance
OWASP LLM Top 10 2025	LLM10 Unbounded Consumption	Defines denial of wallet; rate limits, quotas, timeouts, action limits
OWASP API Security Top 10 2023	API4:2023 Unrestricted Resource Consumption	Limits on API calls and billable integrations
MITRE ATLAS	AML.T0034 Cost Harvesting, AML.T0029 Denial of AI Service	Attacker behaviour against AI services
MITRE ATT&CK v20	T1496.004 Cloud Service Hijacking, T1078.004 Cloud Accounts	Abuse of your cloud account and its credentials
NIST SP 800-53 Rev. 5	SC-5, SC-6, SI-4, AC-6	Denial-of-service protection, resource availability, monitoring, least privilege
NIST CSF 2.0	PR.IR-04, DE.CM-09, RS.MI-01	Capacity for availability, monitoring runtime environments, containment

Common failure patterns

Treating a budget as a cap: an email at 100% arrives hours after the spend, while the agent keeps running.
The unlimited default workspace or project: limits are set on new workspaces but test keys live in the default one, which has none.
One key for everything: a single organisation key shared by all agents means no per-agent limits, no attribution and an outage when it is revoked.
Retrying spend errors: agents and wrappers that treat every 429 as transient retry forever once a hard limit trips.
Leaked keys with no quota: keys in repositories, images or client code with organisation-wide limits, as in the LLMjacking cases.
Oversized max_tokens defaults: copied from examples, reserving quota that throttles legitimate traffic on providers that count it.

Practitioner checklist

Set a provider hard spend limit on every project and workspace, including the default one.
Issue one key or identity per agent and application, never a shared organisation key.
Enforce per-agent and per-tenant token quotas at a gateway, keyed on identity.
Cap turns, graph steps, tokens and tool calls per agent run.
Set max_tokens close to expected output and limit input size.
Honour Retry-After, cap retries and never retry spend or quota errors.
Alert on token rate changes within minutes; keep budgets and anomaly detection as the backstop.
Restrict which cloud principals can invoke models and alert on new regions or principals.
Put quota and limit changes behind privileged access and log them.
Test a simulated loop and a stolen-key burst in a sandbox each quarter.

Denial-of-Wallet and AI Agent Cost Runaway Guide: Limits and Detection