AI Token Exhaustion: Build Resilience Against Denial-of-Wallet

AI availability can fail long before a model or provider goes offline. An unbounded agent loop, oversized retrieval payload, leaked API credential, or burst of low-priority requests can consume the token capacity and budget needed by incident responders. New joint guidance from CISA and partner cyber agencies reframes this as an operational-resilience problem, not just a cloud-cost problem.

This guide turns that advice into an engineering plan for AI gateways, platform teams, security operations centers, and business-continuity owners. It explains how to separate workloads by criticality, build measurable guardrails, feed token telemetry into a SIEM, and test a safe offline audit before changing production controls.

What the joint guidance changes

The publication, Managing AI token consumption for operational resilience, was co-authored by the U.S. Cybersecurity and Infrastructure Security Agency, the Australian Cyber Security Centre, the Canadian Centre for Cyber Security, the United Kingdom National Cyber Security Centre, and New Zealand’s National Cyber Security Centre. CISA listed the resource on October 22, 2026, while the New Zealand publication page is dated October 23.

The document distinguishes input, cached, and output tokens, then connects consumption to five operational outcomes: unpredictable cost, reduced access to critical services, weak visibility, degraded performance, and quota exhaustion. It also describes denial-of-tokens and denial-of-wallet attacks, in which an attacker deliberately drives inference use, long outputs, or recursive processing to impair availability or increase spend.

Token telemetry belongs beside identity, API, cloud, and application telemetry. Treating it only as a finance metric hides both availability risk and potential abuse.

This risk is consistent with OWASP LLM10:2025 Unbounded Consumption, which recommends input limits, rate limits, per-user quotas, timeouts, bounded action queues, comprehensive logging, and graceful degradation. The government guidance goes further on continuity: it asks organizations to identify mission-critical AI dependencies, preserve non-AI alternatives, and plan for reduced availability during incidents or high demand.

Threat model: how token exhaustion becomes a security incident

Runaway agent loops

An agent may repeatedly call tools, re-submit previous outputs, or retry a failing step without a hard termination condition. Each turn can carry the system prompt, conversation history, retrieved documents, and prior tool output again. Even a legitimate task can therefore amplify its own consumption. A malicious document or tool response may also influence an agent into repeating expensive work.

Public-interface abuse and stolen credentials

Attackers do not need a novel model exploit to create financial or capacity pressure. They can automate requests against an exposed AI feature, reuse a compromised API key, distribute traffic across accounts, or select inputs that generate long responses. Identity-aware quotas matter because an IP-only control can be bypassed through proxies, shared infrastructure, or server-side requests made on an attacker’s behalf.

Priority inversion

A more subtle failure occurs when routine drafting, summarization, or experimentation consumes shared capacity before a high-priority security workflow needs it. During an incident, alert triage and evidence analysis may then be rate-limited by the same pool that served low-impact productivity traffic. This is an architectural issue even when every request is authorized.

Build a three-tier allocation model

The agencies recommend separating token allocation according to business impact. Translate that principle into independently enforceable budgets, identities, and failure behavior.

Do not implement tiers as dashboard labels alone. Each tier should map to a service identity, gateway policy, token budget, request and concurrency limit, model allowlist, maximum output length, maximum agent steps, timeout, and named operational owner. If the provider cannot reserve capacity per workload, enforce the separation at an AI gateway or proxy and maintain distinct credentials where practical.

Controls to enforce before inference

• Authenticate the caller: bind requests to a user, workload identity, tenant, and environment. Avoid one organization-wide production key.
• Validate input size: reject or truncate payloads that exceed the approved use case. Limit retrieved chunks, attachments, conversation history, and tool output.
• Estimate before sending: use the provider’s tokenizer when available. The estimate should inform admission control, not be treated as the final billed value.
• Cap output: set an explicit maximum output length and stop sequence where the API supports them.
• Bound autonomous work: enforce maximum steps, tool calls, wall-clock duration, retries, and cumulative tokens for every agent run.
• Prevent recursive replay: summarize or discard unnecessary history instead of feeding complete transcripts and repeated tool results into every turn.
• Use caching carefully: reuse approved static context when the provider supports secure caching, but include cache access, retention, and invalidation in the threat model.
• Choose the smallest sufficient model: route simple classification, extraction, or formatting to a model that meets the task’s quality and security requirements.

For agent security beyond resource controls, see Microsoft’s Five AI Agent Risk Classes: A Practical Security Control Map. Security engineering teams can also compare those controls with the bounded workflow in AI-Assisted Fuzzing: GitHub’s Taskflow Agent in Practice.

Telemetry that a SOC can investigate

Record one structured event for each inference request and one summary event for each agent run. Avoid logging raw prompts by default because they may contain credentials, personal data, incident evidence, or proprietary content. Store identifiers and measurements that let analysts reconstruct the consumption path without copying sensitive payloads into the SIEM.

{
  "timestamp": "2026-10-23T08:00:00Z",
  "workload": "soc-alert-triage",
  "tier": 1,
  "principal": "svc-soc-agent",
  "provider": "approved-provider",
  "model": "approved-model-class",
  "input_tokens": 180000,
  "cached_tokens": 90000,
  "output_tokens": 42000,
  "request_count": 58,
  "loop_depth": 3,
  "result": "success",
  "policy_action": "allow"
}

Correlate token events with identity sign-ins, API gateway decisions, deployment changes, cloud spend, connector access, and tool execution. Useful detections include a new principal consuming production tokens, a sudden change in input-to-output ratio, repeated maximum-length responses, growing cache misses, high loop depth, access outside the workload’s normal hours, and Tier 3 traffic approaching the capacity reserved for Tier 1.

The joint guidance offers 70%, 80%, and 90% of quota as illustrative information, warning, and critical thresholds. Treat those values as a starting point, not a universal standard. Baseline each workload, account for legitimate batch jobs, and make the critical threshold early enough that responders still have time to protect capacity.

Hands-on lab: audit token budgets without calling an AI service

This lab uses synthetic CSV telemetry and Python’s standard library. It makes no network requests, sends no prompts, and changes no system. The script calculates normalized usage as non-cached input plus output tokens. That number is useful for the exercise but is not a currency estimate because provider billing and caching rules differ.

Prerequisites

• Python 3.10 or later
• An isolated working directory
• The sample CSV and audit script from this article

Create the synthetic inventory

mkdir -p ai-token-lab && cd ai-token-lab
cat > ai-token-telemetry.csv <<'CSV'
timestamp,workload,tier,principal,input_tokens,output_tokens,cached_tokens,request_count,loop_depth,budget_tokens
2026-10-23T08:00:00Z,soc-alert-triage,1,svc-soc-agent,180000,42000,90000,58,3,400000
2026-10-23T08:05:00Z,soc-alert-triage,1,svc-soc-agent,160000,38000,80000,53,3,400000
2026-10-23T08:00:00Z,policy-analysis,2,svc-grc-assistant,210000,62000,70000,86,4,300000
2026-10-23T08:05:00Z,policy-analysis,2,svc-grc-assistant,90000,26000,20000,37,3,300000
2026-10-23T08:00:00Z,meeting-summary,3,user-batch-17,380000,140000,10000,165,2,450000
2026-10-23T08:05:00Z,meeting-summary,3,user-batch-17,160000,68000,0,72,2,450000
2026-10-23T08:10:00Z,external-research-agent,2,svc-research-agent,120000,53000,0,48,9,350000
CSV

Create the audit script below. It validates the required columns, aggregates usage by workload, checks the 70%, 80%, and 90% quota levels, flags more than 120 requests per interval, identifies loop depth above six, and detects when Tier 3 consumes more than half of observed normalized usage.

#!/usr/bin/env python3
import argparse
import csv
import json
import sys
from collections import defaultdict
from pathlib import Path

THRESHOLDS = ((90, "critical"), (80, "warning"), (70, "info"))

parser = argparse.ArgumentParser()
parser.add_argument("csv_file", type=Path)
parser.add_argument("--max-loop-depth", type=int, default=6)
parser.add_argument("--max-requests", type=int, default=120)
parser.add_argument("--json", action="store_true")
args = parser.parse_args()

required = {
    "timestamp", "workload", "tier", "principal", "input_tokens",
    "output_tokens", "cached_tokens", "request_count", "loop_depth",
    "budget_tokens",
}
findings = []
workloads = defaultdict(lambda: {"used": 0, "budget": 0, "tier": ""})
tier_usage = defaultdict(int)

try:
    with args.csv_file.open(newline="", encoding="utf-8") as handle:
        reader = csv.DictReader(handle)
        missing = required - set(reader.fieldnames or [])
        if missing:
            raise ValueError("missing columns: " + ", ".join(sorted(missing)))

        for line, row in enumerate(reader, start=2):
            values = {name: int(row[name]) for name in (
                "input_tokens", "output_tokens", "cached_tokens",
                "request_count", "loop_depth", "budget_tokens"
            )}
            if min(values.values()) < 0:
                raise ValueError(f"line {line}: negative value")
            if values["cached_tokens"] > values["input_tokens"]:
                raise ValueError(f"line {line}: cached exceeds input")

            used = (values["input_tokens"] - values["cached_tokens"]) + values["output_tokens"]
            name = row["workload"]
            workloads[name]["used"] += used
            workloads[name]["budget"] = max(workloads[name]["budget"], values["budget_tokens"])
            workloads[name]["tier"] = row["tier"]
            tier_usage[row["tier"]] += used

            if values["loop_depth"] > args.max_loop_depth:
                findings.append(["critical", "loop-depth", name, values["loop_depth"], args.max_loop_depth])
            if values["request_count"] > args.max_requests:
                findings.append(["warning", "request-burst", name, values["request_count"], args.max_requests])
except (OSError, ValueError) as exc:
    print(f"ERROR: {exc}", file=sys.stderr)
    raise SystemExit(1)

report = []
for name, item in sorted(workloads.items()):
    percent = item["used"] / item["budget"] * 100 if item["budget"] else 100.0
    state = next((label for threshold, label in THRESHOLDS if percent >= threshold), "ok")
    report.append([name, item["tier"], item["used"], item["budget"], round(percent, 1), state])
    if state != "ok":
        findings.append([state, "quota-threshold", name, round(percent, 1), 70])

total = sum(tier_usage.values())
tier3_share = tier_usage.get("3", 0) / total * 100 if total else 0
if tier3_share > 50:
    findings.append(["warning", "priority-inversion", "tier-3", round(tier3_share, 1), 50])

if args.json:
    print(json.dumps({"workloads": report, "findings": findings}, indent=2))
else:
    print("WORKLOAD                          TIER  USED       BUDGET     STATE")
    for name, tier, used, budget, percent, state in report:
        print(f"{name:<33} {tier:<5} {used:<10} {budget:<10} {state} ({percent}%)")
    print(f"nFindings: {len(findings)}")
    for level, kind, name, value, limit in findings:
        print(f"- {level.upper()}: {kind} [{name}] value={value} limit={limit}")

raise SystemExit(2 if any(f[0] in {"warning", "critical"} for f in findings) else 0)

Run the audit

python3 audit_ai_token_usage.py ai-token-telemetry.csv
echo "exit_code=$?"

Expected output includes two workloads within their budget, a critical 164.0% result for the productivity workload, a critical 99.3% result for policy analysis, one request burst, a loop depth of nine against a limit of six, and a Tier 3 share of 50.6%. The script returns exit code 2 because warning or critical findings exist.

WORKLOAD                          TIER  USED       BUDGET     STATE
external-research-agent           2     173000     350000     ok (49.4%)
meeting-summary                   3     738000     450000     critical (164.0%)
policy-analysis                   2     298000     300000     critical (99.3%)
soc-alert-triage                  1     250000     400000     ok (62.5%)

Findings: 5
exit_code=2

Troubleshooting and cleanup

• If Python reports missing columns, compare the CSV header with the sample exactly.
• If cached tokens exceed input tokens, correct the exporter or provider mapping before trusting the audit.
• If every workload reaches 100%, confirm that each row carries the intended workload budget rather than an account-wide budget.
• Remove the lab with cd .. && rm -rf ai-token-lab only after confirming the path is the isolated directory you created.

Incident response for abnormal consumption

1. Protect critical capacity: throttle Tier 3, pause nonessential batch jobs, and preserve the quota reserved for incident response.
2. Identify the principal and path: trace the credential, user, workload, gateway route, connector, agent run, and deployment version responsible for the increase.
3. Stop amplification: terminate runaway jobs, disable recursive retries, cap outputs, and isolate untrusted documents or tool responses that influenced execution.
4. Rotate compromised credentials: revoke exposed keys or tokens and review adjacent identities for reuse. Preserve evidence before destructive cleanup.
5. Check data exposure: a token spike may indicate bulk data submission or exfiltration. Review connector reads, retrieved object counts, egress, and prompt-handling logs without broadly exposing prompt content.
6. Restore deliberately: reopen workloads by tier, apply reduced limits first, and watch consumption, latency, and policy denials for recurrence.

If abnormal use includes suspicious agent access or personal-data handling, the response should extend beyond cost containment. The workflow in AI-Agent Data Breach Response: Lessons from AEPD’s First Notification provides a useful companion for evidence preservation, credential control, and notification triage.

Implementation checklist

• Inventory every production AI workload, owner, provider, model class, credential, connector, and critical dependency.
• Assign each workload to a business-impact tier and document its manual or non-AI fallback.
• Enforce per-principal and per-workload token, request, concurrency, output, timeout, retry, and loop limits.
• Reserve or logically protect capacity for mission-critical cyber-defense and incident-response workflows.
• Send minimal structured telemetry to the SIEM and correlate it with identity, API, cloud, and tool-execution logs.
• Alert progressively before exhaustion and test the escalation route with the service owner and finance contact.
• Exercise provider outage, credential abuse, runaway loop, and Tier 3 throttling scenarios.
• Review thresholds after product changes, model migrations, new connectors, or material workload growth.

Conclusion

AI token consumption is simultaneously a capacity signal, a cost driver, and a security observable. The practical goal is not to minimize every token. It is to guarantee that high-value workflows remain available, lower-priority work cannot starve them, autonomous behavior has hard stopping conditions, and unusual consumption becomes visible early enough to investigate.

Start with a workload inventory and three-tier allocation model, then enforce controls at the identity and gateway layers. Once token events reach the SIEM, teams can investigate consumption alongside the authentication, API, cloud, and agent activity that explains it. That turns an unpredictable bill into a measurable resilience control.

References

• CISA: Managing AI Token Consumption for Operational Resilience
• Joint agency guidance PDF
• New Zealand NCSC publication page
• OWASP LLM10:2025 Unbounded Consumption
• NIST AI 600-1: Generative AI Profile