Cost and consumption controls are the limits that bound how much compute, quota and money one caller or one runaway process can consume through an AI feature. The concern has a name in the serverless world, denial of wallet, coined around 2018 when pay per request billing first made spend an attack surface, and OWASP calls the AI version unbounded consumption. It rose from tenth to sixth on the 2026 list for LLM applications, and it moved because people started shipping agents. Cost belongs on a safety course because an attacker who can make a system spend money denies service to everybody else without breaching a single control, and a runaway loop does the same by accident.
The sections below say why consumption is a safety concern, where the money in a run actually goes, which mechanisms bound it, where consumption meets confidentiality, why the ceiling is set in advance, and end with a five minute worst case calculation.
Why consumption is a safety concern
Denial of service used to mean traffic. Against an AI feature it means spend, since inference costs real money per request and providers enforce quotas the whole account shares. Exhaust the quota or trip the budget and the feature stops answering, while the data, the model and the infrastructure were never touched.
The accidental version is more common than the deliberate one. An agent retrying a tool call that will never succeed, two agents handing work back and forth, a loop whose termination condition a long document never satisfies. Each of those has produced a bill in the thousands overnight for teams that thought they were running a chatbot.
Where the money actually goes
The unit of cost is the run, with the call a poor proxy for it. A run pays for a system prompt and a tool schema on every step, plus a conversation that grows as each tool result is appended to it, so cost climbs with the square of the step count, with no straight line anywhere. Retries multiply it again, and retrieval adds to it quietly, since every retrieved passage is an input token somebody pays for. Output tokens cost several times what input tokens cost on every major platform, so a verbose model in a long loop is the expensive combination.
The mechanisms that bound it
Six mechanisms bound a run, and they belong in the loop and never in the prompt.
Per user and per key limits. Requests per minute and tokens per day, applied to the identity making the request and never to the account as a whole. Without them one caller consumes the capacity everybody shares, and the team learns about it from support tickets.
Token and step budgets for agent runs. A hard maximum on steps, on total tokens and on tool calls, enforced by the loop. When a budget is reached the run should stop and say so, which is better than a run that quietly continues.
Timeouts. On each call and on the whole run, since a request nobody is waiting for any more is pure cost.
Caps on retrieval. A limit on the number of passages and on their combined length. An uncapped retrieval step is the usual explanation for a bill that does not match the request count.
Circuit breakers. When the error rate against a dependency crosses a threshold, the loop stops calling it for a while. Retrying into a failing tool is the fastest way to spend money achieving nothing.
Alerting on spend. Daily at worst, with the alert on the rate and never on the total, because discovering the number when the invoice arrives means the exposure lasted a month.
Where consumption meets confidentiality
One of those mechanisms does double duty. Model extraction is the case where the two concerns become one control. An attacker with enough queries can use the responses to train a substitute model, recover the substance of a system prompt, or map a retrieval index by asking about it systematically, and a 2016 paper showed the first of those working against commercial prediction APIs with a few thousand queries. None of that requires a breach and all of it requires volume, which is what a per caller limit removes.
The signal worth watching is therefore one identity producing unusual volume with unusually systematic inputs, and no single request will show it. It is visible only where the team records who called and how often.
Setting the ceiling in advance
A system with no ceiling has its ceiling set by whoever is most willing to abuse it. Every limit above is a decision about what the worst case looks like, and the choice is between making it calmly in advance or having it made by a stranger who found the feature interesting.
The corollary is that limits have to be tested. A budget nobody has ever reached is an assumption and no control, so a run is driven over the line in a test environment and the stop is confirmed.
Practise this
The exercise needs the agent or feature the team runs, the provider's price list, and five minutes with Python or a calculator.
Work out the worst case cost of one run, using the loop's maximum step count and leaving the typical run out of it.
steps = 12 # the loop maximum, not the average
prompt_tokens = 1500 # system prompt plus tool schemas, sent every step
growth = 800 # tokens each tool result adds to the context
output_tokens = 400 # per step
input_total = sum(prompt_tokens + growth * i for i in range(steps))
output_total = output_tokens * steps
# Replace with the provider's prices per million tokens.
cost = input_total / 1e6 * 3.00 + output_total / 1e6 * 15.00
print(f"worst case run: {input_total} in, {output_total} out, {cost:.2f}")
Compare the number with what the team assumed a run costs, then multiply it by how many runs one user could start in an hour under the limits in place today. Where that second number cannot be stated, the ceiling is currently whatever a determined person decides it should be.
It teaches that the figure worth knowing is the worst case, because the average is what users produce and the worst case is what an attacker or a stuck loop produces.