TL;DR - On 22 October 2026, CISA and the Canadian Centre for Cyber Security published joint guidance that treats AI token consumption as an operational resilience problem. Run the tokens dry and you have an outage. Someone else can run them dry for you, on your invoice. What you need to do: tier your AI workloads by business impact, alert at 70, 80 and 90 percent of quota, right-size the model to the task, bind your agent loops, and feed token telemetry into the monitoring you already run.
| Figure | Value | Source |
|---|---|---|
| Publish date | 22 October 2026 | CISA / Cyber Centre joint release |
| Guidance ID | ITSM.00.125 | Canadian Centre for Cyber Security |
| Token tiers recommended | 3 - mission-critical, operational, productivity | ITSM.00.125 |
| Tokens for a simple Q&A | hundreds | ITSM.00.125 |
| Tokens for a multi-step agent workflow | tens of thousands | ITSM.00.125 |
| Recommended alert thresholds | 70% info, 80% warning, 90% critical | ITSM.00.125 |
| Unauthorised spend in one real key-theft case | US$281 overnight, single user | OpenCode disclosure, October 2026 |
I read a lot of government guidance. Most of it goes in the agree-file-move-on pile. This one made me get up and check the little box that runs my AI gateway.
CISA and the Canadian Centre for Cyber Security released joint guidance on 22 October 2026 called Managing AI Token Consumption for Operational Resilience. The premise is simple and a bit uncomfortable: if your operations depend on AI services, your token budget is an availability surface. Exhaust it and your AI-dependent workflows stop, same as if a server died. And you don't have to exhaust it yourself - the guidance names two attack types that do it deliberately.
The reason this one landed for me: I run a gateway exactly like the one the guidance describes. Every AI call from my tools goes through one point that meters spend per model, enforces per-model quotas, and writes it all to logs I can query. I built it for cost reasons, because the invoices were getting interesting. Two national cyber centres now describe the same architecture as a resilience control. I had it filed under budget tools.
I've spent fifteen years in cloud and security architecture, and the closest analogue to this problem is bandwidth. We learned the hard way that consumption you don't meter is consumption somebody else can spend. Tokens are this decade's version of that lesson, and this guidance is the first time I've seen two national cyber centres say it out loud.
Let me walk you through what the guidance actually says, why the attack names matter more than the cost advice, and what to do about it this week.
Tokens stopped being a licence fee
Traditional software bills per seat or per licence. You buy 50 licences, you know the number, the number doesn't move because someone asked longer questions.
AI services don't work that way. They bill per token - a token being a chunk of text, a few characters or a short word, that the model reads or writes. You pay for what goes in, what comes out, and increasingly for cached context you reuse. The guidance's point is that this pricing is harder to predict than seat licensing because consumption moves with the work: prompt length, response length, how much history rides along, and how many steps a workflow runs.
The scale ranges matter. A simple question might burn hundreds of tokens. A multi-step agent workflow - the kind more teams are wiring up every month - can consume tens of thousands, because each step reprocesses the prior steps' output. The guidance calls this compounding out plainly: agentic workflows reprocess prior content and tool outputs at every hop, so cost grows with depth as much as volume.
That's the structural shift. Your AI spend used to be a procurement decision. Now it's a consumption meter, and consumption meters need what every other consumption meter has: baselines, alerts, and somebody who notices at 9pm when the graph goes vertical.
Six ways token spend breaks things
The guidance lists six risks. The first four are the ones every finance team already believes:
- Rising and unpredictable costs. Complex workflows and automated processes make the bill hard to forecast.
- Reduced access to critical services. Without prioritisation, low-value work consumes the capacity your important work needs.
- Limited visibility. No monitoring means nobody can spot inefficiency or abuse.
- Degraded performance. Bigger prompts mean slower responses and inconsistent output quality.
The last two are where it stops being a finance problem:
- Token exhaustion. You hit a quota, rate limit, or budget ceiling and AI-dependent operations fail. Not degrade - fail. The guidance recommends progressive alerts so somebody hears about it at 70 percent of quota (informational), 80 percent (warning), and 90 percent (critical) rather than at 100 percent, when the outage is already happening.
- Deliberate attacks. Which deserve their own section.
Denial-of-wallet: the attack that arrives as an invoice
The guidance names two attack types, and the naming is the part I'd underline.
A denial-of-tokens attack exhausts your token allocation. The attacker triggers automated prompts, abuses a public AI interface, or manipulates an AI-enabled workflow into processing huge volumes of data. When the quota is gone, your legitimate users lose the service.
A denial-of-wallet attack skips the quota and goes for money. The guidance's examples: inputs crafted to demand heavy analysis and long outputs, and - this is the clever one - induced loops, where the AI feeds its own output back in as input, billing you for every revolution.
If neither of those sounds theoretical, it's because a version of this already happened. In October 2026, an attacker compromised a legacy system run by OpenCode and stole stored API keys; one user woke up to US$281 of unexplained usage overnight, another to US$1,700, before anyone had published anything. That was theft of credentials rather than abuse of an exposed interface, but the economics are identical: consumption-based billing converts access into an invoice that runs itself.
There's a supply-side reason to expect more of it, too. In August 2026, CISA, the NSA and the FBI warned that China-based companies had extracted billions of tokens from US frontier models through industrial-scale distillation campaigns. The labs responded - Anthropic described fingerprinting distillers and cutting the reasoning tokens an average attacker could pull from thousands of times their quietest day to a fraction of that. When the front door gets bricked up, demand moves to the soft targets. Your token budget is a soft target.
The uncomfortable part of consumption pricing is that the meter runs in both directions. Anyone who can pull the lever spends your money.
The tier system: ration by business impact
The core organisational recommendation is a three-tier allocation model, and it's more interesting than it first looks:
- Tier 1 - Mission-critical. Cyber defence, incident response, threat intelligence. Highest priority for token availability and continuity.
- Tier 2 - Operational. Essential business processes: compliance work, policy analysis, core processing. Monitored and managed.
- Tier 3 - Productivity. Everyday drafting, summarising, research. First in line for usage limits when demand spikes.
The resilience logic: when tokens get scarce, tier 3 throttles before tier 1 even notices. The guidance is upfront that dedicated capacity per tier can cost more, and frames that as an availability purchase rather than waste. If you've ever run out of API quota during an incident because last month's marketing automation ate the budget, you already understand the argument.
For critical infrastructure operators there's a second layer: map which business functions depend on AI, then plan for reduced AI availability the same way you plan for reduced power or connectivity. The guidance even suggests keeping manual or non-AI fallback processes alive. Degrade gracefully on purpose, rather than accidentally.
The controls that actually bite
Under the strategy talk there's a set of concrete controls. These are the ones worth stealing:
- Right-size the model. Stop routing everything to the biggest model you can access. Small, cheap or locally-run models handle classification, extraction and summarisation fine, and the guidance explicitly says to pick the lowest-cost model that meets the requirement and to turn reasoning effort down where it isn't needed.
- Cache static context first. LLM providers bill cached input tokens at lower rates. Put your stable, reusable context - system instructions, reference material - at the front of the prompt where the cache can absorb it, and keep the changing parts at the end.
- Bind the loops. Agentic workflows need hard iteration limits, output caps, and human checkpoints at consequential decisions. An unbounded agent loop is a denial-of-wallet you built yourself.
- Send excerpts, not documents. The single cheapest prompting habit: give the model the relevant section instead of the full 90-page PDF.
- Route across providers. Multi-provider architecture means one vendor's outage or quota wall becomes a routing decision instead of a stoppage.
- Put token telemetry in the SIEM. This is the sleeper recommendation in the whole document: treat unusual token-consumption spikes as a potential indicator of data exfiltration, the same way abnormal bandwidth spikes flag unauthorised transfers. Then correlate token telemetry with identity, cloud and API logs.
- Use a gateway. The guidance's own words: AI proxies are becoming a practical way to monitor consumption, enforce quotas, apply guardrails and support chargeback.
That last one deserves a note. Every one of these controls gets easier when all AI traffic passes through one measurable point - the same consolidation that network teams did with web proxies fifteen years ago. Centralise the traffic, and tiers, thresholds and telemetry all become configuration instead of policy wishes.
Why this could be good
None of this is bad news for teams that have already been having the cost conversation. The guidance hands you cover for three things that are normally hard to get budget for:
First, metering. If you've been trying to justify an AI gateway or usage dashboards and getting nowhere, you can now cite two national cyber centres calling it a resilience control.
Second, the tiering conversation. "Marketing's summarisation jobs throttle before the SOC's threat hunting does" is an argument you can win in one meeting with the tier table on a slide.
Third, and quietly the biggest: the exfiltration signal. Security teams have been looking for useful AI-specific detection telemetry since the first prompt-injection advisory. Token velocity per identity is free to collect once traffic is centralised, and it correlates with exactly the behaviours that matter - an agent suddenly processing ten times its normal volume is either misconfigured, looped, or being used to move data.
The concerns
Honest list, because the guidance isn't perfect:
- Token telemetry is sensitive. Prompts are in those logs, and prompts contain business secrets and sometimes personal information. Feeding token telemetry into a SIEM creates a new high-value log source that needs its own access control and retention decisions. The guidance doesn't dwell on this.
- Tiering gets political. Deciding that the sales team's AI copywriting is tier 3 and the security team's is tier 1 is an organisational fight wearing a technical costume. Expect the meeting to take longer than the implementation.
- It's written for big organisations. The tier model assumes you have a governance working group and critical functions to protect. A ten-person team can still use the shape - prioritize, meter, alert, right-size - but shouldn't build a bureaucracy around it.
- "Super intelligence" framing. The document leans on the SI label, which most working IT people don't use and which risks dating the guidance fast. The substance underneath survives the vocabulary.
What you should do right now
- Inventory your AI dependencies. Which workflows, teams and customer-facing functions stop working if the AI quota hits zero? That list is your tier 1, and I promise it's shorter than you expect.
- Find your consumption numbers. Whatever you use - provider dashboards, an existing gateway, billing exports - get tokens per day per workload for the last 30 days. You can't tier what you can't see.
- Set progressive alerts at 70/80/90 percent of every quota that matters, routed to a human who can act, not a shared inbox that filters them.
- Check your agent loops for bounds. Every automated AI workflow needs a maximum iteration count, an output cap, and a rule for what happens when a step fails twice.
- Right-size one workload this week. Pick the noisiest low-stakes workload and move it to the cheapest model that does the job acceptably. Measure the difference. That number funds the rest of the programme.
- Baseline token velocity per identity or per service account, and decide now what "weird" looks like, so the exfiltration signal has a threshold before you need it.
Key takeaways
- CISA and Canada's Cyber Centre published joint token-consumption guidance (ITSM.00.125) on 22 October 2026, framing AI token spend as an operational resilience problem.
- Token exhaustion is an outage. Quota limits, rate limits and budget ceilings all stop AI-dependent work, so capacity needs the same planning as any other dependency.
- Denial-of-tokens and denial-of-wallet are named attack types - adversaries exhaust your allocation or inflate your invoice through crafted inputs and induced loops.
- Tier allocations by business impact: mission-critical, operational, productivity - so scarcity throttles the right workloads in the right order.
- The control list is concrete: right-size models, cache static context, bind agent loops, send excerpts, route across providers, alert at 70/80/90 percent.
- Token telemetry belongs in security monitoring, because unusual consumption spikes are a data-exfiltration indicator before they are a budget anomaly.
- A gateway or proxy is the enabling architecture - metering, quotas, guardrails and chargeback all become configuration once traffic is centralised.
FAQ
What is a denial-of-wallet attack? An attack that exploits consumption-based pricing to run up your costs. Examples include inputs crafted to produce maximum analysis and output, and induced loops where the AI processes its own output repeatedly. The goal is financial harm, not data theft.
What is token exhaustion? Hitting a token quota, rate limit or budget threshold so that AI-dependent operations fail or degrade. The guidance recommends alerting at 70, 80 and 90 percent of quota so someone can act before the outage.
What exactly is an AI token? The chunk of text - a few characters or a short word - that language models read and write. Providers bill separately for input tokens, output tokens and cached tokens, so usage maps directly to invoice.
How do you monitor AI token consumption? Either through provider dashboards and billing exports, or centrally through an AI gateway or proxy that meters every call. The guidance recommends feeding that telemetry into dashboards with thresholds, and into your SIEM for security correlation.
Does this guidance apply to small teams? The shape does, even if the bureaucracy doesn't. Prioritise what matters, meter consumption, alert before limits hit, and right-size models. A ten-person team can do all of that in a week.
What's the difference between token exhaustion and a denial-of-tokens attack? Exhaustion is accidental - legitimate demand, poor optimisation or an unexpected spike. A denial-of-tokens attack is deliberate - an adversary burns your allocation on purpose to take the service away.
My take
The cost advice in this document is sensible and most mature teams have heard versions of it. That's not the story.
The story is the classification. Two national cyber centres just put AI token consumption in the same mental bucket as power, bandwidth and staff: a resource that runs out, that somebody can drain on purpose, and that needs metering, baselines and alerts. Once a resource is in that bucket, the conversations change. Nobody has to argue for monitoring a metered resource; you just do it, the way you watch disk space.
The line I'd tape to the monitor is the exfiltration one. Token velocity per identity is the first AI-specific detection signal that's cheap to collect and correlates with behaviour that matters. Everyone's been waiting for the AI-era equivalent of a suspicious login. It might turn out to be a suspicious invoice.
Mathew Clark Founder, SecureInSeconds Currently: tiering the coffee budget and finding it already sits at 90 percent
Drafted with AI assistance - read, verified, and fixed by a human.
Further reading
- Managing AI Token Consumption for Operational Resilience - CISA
- Managing AI token consumption for operational resilience (ITSM.00.125) - Canadian Centre for Cyber Security
- Joint guidance on the careful adoption of agentic AI services - Cyber Centre
- CISA AI guidance hub
- Australian Cyber Security Centre - AI security guidance
- When an AI agent deleted a TV season: least privilege for autonomous tools
- OpenAI's boardroom bug hunters and what the rules say about your AI use
- Your Microsoft Copilot rollout is a security disaster
