Aggregate totals hide whether the problem is prompt bloat, context pressure, or a runaway agent loop. Without per-call and per-span attribution, teams can see that usage increased but cannot tell which request, route, or step caused it. That makes debugging slow and can also mask governance failures in production AI workflows.
Why This Matters for Security Teams
Monthly totals answer finance questions, not operational security questions. For LLM systems, the meaningful unit of analysis is the call, the span, or the workflow step, because that is where prompt growth, retrieval expansion, tool chatter, and retry storms appear. The NIST AI Risk Management Framework stresses governance, measurement, and monitoring, which cannot be done well if usage is compressed into a single number at month end.
The hidden risk is that token growth often signals a control failure before it becomes a cost problem. A prompt injection issue can inflate context, a poorly bounded agent can recurse through tool calls, and a retrieval pipeline can pull too much irrelevant material into every request. With only monthly aggregation, teams lose the link between consumption and behaviour, so they cannot prove whether spikes came from legitimate traffic, a misconfigured route, or an adversarial interaction described in the NIST AI 600-1 Generative AI Profile.
In practice, many security teams encounter the real cause only after a runaway workflow has already consumed budget, degraded latency, or exposed a policy gap.
How It Works in Practice
Effective token governance starts with attribution. Every request should carry identifiers for user, service, application route, model, prompt version, and agent step so usage can be reconstructed across the full execution path. That is especially important when autonomous software entities have tool access, because a single “interaction” may represent multiple internal turns, retrieval operations, and external calls. The OWASP Top 10 for Agentic Applications 2026 and the related OWASP Agentic AI Top 10 both reinforce the need to bound agent behaviour and observe execution, not just final outputs.
At a minimum, teams should log and monitor:
- Tokens per request and per response, not just monthly rollups.
- Tokens per route, tenant, prompt template, and agent step.
- Context window occupancy and retrieval payload size.
- Retry counts, tool invocations, and loop indicators.
- Policy decisions, such as truncation, refusal, or fallback model use.
This data supports both engineering and governance. Engineers can identify prompt bloat, over-retrieval, and inefficient orchestration. Security teams can detect abuse patterns, such as automated prompt stuffing or abnormal tool chaining. For higher-risk deployments, this telemetry should feed alerting and investigation workflows alongside controls from NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where logging, auditability, and system integrity matter.
In agentic environments, token spikes can also be a symptom of adversarial manipulation. The MITRE ATLAS adversarial AI threat matrix is useful for mapping where input attacks, model abuse, and workflow manipulation may translate into abnormal token behaviour. These controls tend to break down when observability is split across multiple teams or when the application layer, model gateway, and agent runtime all record usage differently because no one can reconcile a single request end to end.
Common Variations and Edge Cases
Tighter per-call telemetry often increases engineering and privacy overhead, requiring organisations to balance diagnostic value against data minimisation and storage limits. Current guidance suggests that the right level of detail depends on the system’s risk profile, but there is no universal standard for how much prompt content should be retained. That is why many teams log metadata and hashes by default, then selectively sample or redact sensitive text.
Edge cases arise when usage is shared across tenants, routed through multiple models, or masked by batching. In those environments, a monthly total can hide one customer driving an incident, one workflow step over-consuming context, or one fallback path silently doubling spend. The most practical approach is to treat token usage as an operational signal tied to identity, route, and policy state rather than as a pure cost metric. Where AI governance is formalised, the NIST AI 600-1 Generative AI Profile and CSA MAESTRO agentic AI threat modeling framework help teams connect observability to accountability.
Where this guidance breaks down most sharply is in highly distributed platforms with inconsistent tracing, because attribution gaps make per-span reporting incomplete and the monthly total becomes a misleading average.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST AI 600-1 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI risk governance depends on measurable monitoring, not month-end aggregates. | |
| OWASP Agentic AI Top 10 | Agentic systems need step-level observability to spot runaway loops and abuse. | |
| NIST AI 600-1 | GenAI profiles emphasise monitoring, traceability, and operational control. | |
| MITRE ATLAS | Adversarial AI tactics can surface as abnormal token growth or looping behaviour. | |
| NIST CSF 2.0 | DE.CM-01 | Continuous monitoring requires granular telemetry, not coarse monthly summaries. |
Use adversary-focused threat modeling to correlate token spikes with prompt abuse and workflow manipulation.
