Denial of Wallet on Metered AI Services

Finance noticed the bill because the host sent a courtesy mail at four times the monthly estimate. Nobody had attacked a secret. Somebody had written a loop, and a student group had shared the hostname. The model host was happy to sell tokens until a card failed. The department's card did not fail in time.

Denial of wallet is the name practitioners use for resource exhaustion against a metered control plane — usually a hosted model API, sometimes a translation API, sometimes embeddings. It is not a CERT-In annexure heading. If the same event is also a volumetric attack on your application, map that effect separately. Do not invent a DoW type code.

This explainer is for CIOs and finance on 17 August 2026. Not legal advice. The rate-limit guide is the brake design. The TCO calculator is the cell where the ceiling lives. This page is why those two pages are not optional colour.

Prcept prefers on-prem units with GPU-hour caps for citizen desks that could be flooded. Hosted meters can still be honest if they fail closed. Honesty is the product. Infinity is the incident.

How the bill moves

A public URL plus a share button. No sophistication required.

A planner loop: the model keeps calling a billed tool or keeps retrying itself. Autonomy without a step cap is a furnace.

A hostile user who pastes enormous contexts. Long context is a price list. Indic voice can be expensive per turn. Design for that.

An insider who points a batch job at the host to evaluate. Eval without a ceiling is how a lab spends the year's citizen budget on a weekend.

A fail-open when the limiter is unhappy. We have already told that story. It ends with Monday.

Ceilings are a control

Hard monthly rupee or token ceiling on the account that serves citizens. Soft alerts at 50 and 70 percent. Hard stop at 100. Degrade to a static certified page. Do not hope the host will call you first.

Per-request and per-session token ceilings so one paste cannot eat the month.

Per-identity ceilings so one principal cannot eat the district.

A separate, smaller ceiling for eval and staging. Labs do not share the citizen card.

An owner who receives the SMS, with a deputy, including weekends. A ceiling nobody watches is a spreadsheet.

Meter versus rack. Both can be denied. Both need a cap.

Path	How DoW arrives	Cap that bites
Hosted tokens	Flood, loop, long context	Rupee ceiling + per-request tokens, fail closed
Hosted embeddings	Bulk re-embed	Job quota, not cron-on-everything
On-prem GPUs	Loop cooks the rack	Max steps, max concurrent, thermal/power alert
Translation API	Pasted books	Per-session character cap

Procurement and propriety

An unbounded meter is hard to defend as prudent under ordinary financial rules. You do not need a special AI GFR. You need a number and an owner. Put the number in the TCO sheet and in the work order.

Introductory credits expire. Night-time prices change. Write the worst public overage into the sheet. Credits are not a control.

If the unit of work never earned a model, DoW is what you pay for a fashion. The cost opinion at the start of this batch is the prior question.

• No public desk on a meter without a hard stop.
• No shared card between lab and citizen.
• No infinite planner steps.
• No fail open.
• No 'the host will warn us' as the only alert.

Is it a cyber incident?

Sometimes the flood is also an attack on the application or a denial of service as Annexure I uses those ideas. Sometimes it is a missing ceiling and a popular link. The SOC and counsel map the effect. The finance controller maps the rupees. Both meetings should happen. Neither should wait on an official denial-of-wallet drop-down.

Keep the 180-day logs of 429s, cap trips, and spend. They explain the Monday bill and, if needed, the report.

If the same flood caused a fail-open leak, you have left the wallet story. File the leak.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

A hard stop will embarrass us mid-campaign.

A surprise bill and a fail-open leak will embarrass you more. Campaigns get a dated, raised ceiling, not infinity.

On-prem cannot be denial-of-wallet.

It can be denial-of-rack and denial-of-service to every other workload on the node. Cap steps and concurrency. Wallet is a metaphor for scarce resource.

The amounts are small.

Until they are not. Public URLs change the distribution. Write the cap while the amounts are small.

Our host offers intelligent spend protection.

Read whether it fails closed. Read the delay. Then still put your own brake in front. Their protection optimises their estate.

A seven-day ceiling

Do this before the hostname or the next invoice, whichever is sooner.

1. Day 1: list every metered key. Split lab and citizen.
2. Day 2: set hard ceilings and 70 percent SMS. Name the weekend deputy.
3. Day 3: per-request and per-session token caps. Planner max steps.
4. Day 4: fail closed to static. Test by blowing a tiny staging ceiling.
5. Day 5: write the rupee number into the TCO sheet and the work order.
6. Day 6: decide CERT-In mapping for a hostile flood versus a popular hour.
7. Day 7: finance and CISO initial. Remove any key with no ceiling.

How this shows up in the file

Subject: Spend ceiling — agent [name].

Citizen meter: hard stop [rupees or tokens / month], alerts at 50/70 percent to [posts]. Lab meter: separate, [rupees]. Per-request cap: [n] tokens. Planner max steps: [n]. Fail closed to [static page]. Keys with no ceiling: none. Popular-hour procedure: dated raise, not infinity. CERT-In: map hostile floods to existing types; no invented DoW code. Not legal advice.

A courtesy email from the host is not listed as a control.

Split the cards

Lab and citizen must not share a metered key. The eval weekend that darkens the public desk is self-inflicted denial of wallet. Pay for staging. Give it a smaller ceiling. When the host throttles, only the lab should go dark.

Count locally if the host bills with a week of delay. Their courtesy mail is not your brake. Hard-stop on your side. Reconcile later. Credits expire. Worst public overage is the number that belongs on the TCO sheet.

Do not invent a CERT-In DoW drop-down. If the flood is also an attack on the application, map that effect. Finance still owns the rupees. Infinity is not a campaign plan. Dated raises are.

This article is informational field guidance for Indian public institutions, not legal, procurement, security-accreditation or engineering advice. Confirm against the current Gazette, GFR, GeM term, CVC instruction, CERT-In direction, DPDP text, departmental manual and your counsel before you file it.

How to fail this before citizens do

“Denial of Wallet on Metered AI Services” is a path problem. A P1 CIO/CTO should be able to name the tool, the identity, the secret and the egress that would make “denial of wallet attack” real. If the only control is a network diagram from last year, you have a story, not a threat model.

Denial of wallet is a flood against your meter. It does not need to steal data. It needs you to have no ceiling and a public URL. Air-gap is not automatically secure. Prompt injection is not a conference joke when the agent can write a ticket. CERT-In still wants specified logs in India and incidents on a six-hour clock. Write those clocks into the runbook.

1. Red-team the write tools, not only the chat UI.
2. Kill undeclared outbound paths on staging.
3. Redact personal data from logs you will actually keep.
4. Scope a pentest that includes RAG and connectors.
5. Cap metered spend so a loop cannot empty a budget.

Close this loop before the next CAB

Put “Denial of Wallet on Metered AI Services” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P1 CIO/CTO, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “denial of wallet attack” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.

What the next file must contain

“Denial of Wallet on Metered AI Services” earns a line in the noting only if a P1 CIO/CTO can attach proof of “denial of wallet attack.” A heading is not proof. A vendor slide is not proof. A workshop photograph is not proof.

Write three dated sentences: what was decided, who owns it after the next posting order, and when it will be re-checked. If you cannot write the three sentences, you are not ready to buy, to sell, or to go live.

Leave unsourced percentages out of the note. DPDP is not a blanket localisation statute. The November 2025 AI governance text is guidance, not an Act. CERT-In’s 28 April 2022 directions still set specified incident and log clocks. A PAC, when lawful, lives in GFR Rule 166.

• Name the designation that owns “denial of wallet attack.”
• Attach one artefact a stranger can open next year.
• Record the instrument you are actually using.
• Revisit when the model, the SI, the notice or the posting changes.