Why are five cyber agencies treating AI tokens as an operational risk?
A joint guide warns that agent loops, repeated context and hostile traffic can exhaust AI quotas or budgets and disrupt critical services. It offers practical controls, but no incident dataset or universal thresholds.
The short version
- What happened
- Cyber agencies in New Zealand, the United States, Australia, Canada and the United Kingdom have jointly framed AI-token consumption as a service-availability, cost and security issue.
- Who it affects
- People relying on AI-supported public or critical services need a fallback when quotas, rate limits or budgets are exhausted. Priority rules should not quietly exclude lower-volume users or remove human review from consequential decisions.
- What remains unproven
- This is consensus operational guidance, not a controlled study or an incident report.
Keep in mind
This is consensus operational guidance, not a controlled study or an incident report.
It provides no denominator of organisations, attacks, exhausted quotas, financial losses or disrupted services.
The illustrated 70%, 80% and 90% alert points are examples for local adaptation, not evidence-based universal thresholds.
All sources are participating government cyber agencies; the document includes no independent evaluation of the recommended controls.
Token prices, limits and system architectures vary substantially by provider and deployment, so risk cannot be inferred from token count alone.
Source analysis · 2 linked sources. Primary analysed source date: 23 October 2026.
Read the full report · 5 min The evidence, methods, implications and limitations
A pricing unit becomes a continuity dependency
Five national cyber agencies have issued joint guidance asking organisations to manage AI tokens as part of operational resilience. The 23 October document comes from New Zealand's NCSC with the US CISA and cyber authorities in Australia, Canada and the United Kingdom. Its central point is practical: when a service is limited or billed by the amount of data a model processes and produces, token consumption can affect availability as well as cost.
The risk grows with system design. Large inputs and outputs, uncached reference material, repeated conversation history, connected-platform payloads and multi-step agents can all multiply consumption. A workflow that continually feeds previous output back into a model may keep spending without delivering proportionate value. If the same quota supports a critical function and routine experiments, lower-priority work can also crowd out the service that matters most.[1][2]
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]
The distinction that matters
How token consumption becomes an operational incident
The joint guidance connects system design and hostile use to two kinds of exhaustion.
Normal growth
Long context, repeated data and agent steps multiply tokens
Costs rise and critical requests may hit shared limits
Token attack
Hostile traffic deliberately consumes allocations or rate limits
Legitimate users may lose access
Wallet attack
Inputs or loops maximise pay-per-use processing
Bills rise even if the service remains online
Resilience
Prioritise, cap, monitor, cache and preserve fallback routes
Intended to contain impact; effectiveness is not evaluated here
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]