Why are five cyber agencies treating AI tokens as an operational risk?

Abuse can target the quota or the bill

The agencies distinguish two hostile patterns. A denial-of-tokens attack tries to burn through allocations or rate limits so legitimate users lose access. A denial-of-wallet attack exploits consumption-based pricing to impose financial harm, for example by sending complex requests, demanding long outputs or creating automated loops. Both depend on ordinary service mechanics, which means traditional uptime monitoring may miss the financial signal until a limit or bill is reached.

The guide recommends progressive alerts and illustrates them at 70%, 80% and 90% of an organisation's chosen quota. Those numbers are examples, not measured universal thresholds. A hospital, utility or government service may need tighter reserve capacity than a non-critical drafting tool, while a fixed-budget pilot may tolerate interruption but not an uncontrolled bill.[2]

Controls begin with inventory, priority and bounded automation

Organisations are advised to identify mission-critical AI dependencies, monitor consumption by application and user, assign budgets or quotas, cache reusable context, remove unnecessary data and choose smaller or local models when they meet the task. For agentic workflows, a defensible implementation would also bound the number of steps, detect loops, rate-limit public interfaces and require approval before expensive or consequential actions continue.

The document also pushes buyers to examine pricing and usage terms before signing contracts. Useful service-level evidence would separate input, output and cached tokens; show consumption by application; warn before budgets or rate limits are exhausted; and explain which requests are throttled first. Procurement teams would then be able to compare the provider's commercial limits with the organisation's own recovery objective instead of discovering the dependency during an outage or cost spike.

For workers and service users, the important question is what happens when the model becomes slow or unavailable. Continuity plans should preserve a manual or non-AI route for essential decisions and make priority rules visible rather than silently delaying less powerful users. The guidance is useful as a checklist, but it supplies no dataset of attacks, affected organisations, losses or evaluated interventions. Confidence will depend on incident reporting and tests showing that limits preserve critical work without simply moving failure elsewhere.[2]