Token Spend Is a Security Signal: A Security Leader's Guide to Governing AI Agent Costs

Most security teams treat AI agent token spend as a finance problem. It is not. Token spend is the most legible signal you have of how your agents actually behave in production, and the same blind spot that hides the cost hides the risk.

This guide is written for security leaders, not FinOps. It explains where agentic token cost comes from, why the waste and the risk share a single root cause, and what an evidence-led governance program does about both. Every figure below is attributed to a primary or independent source so you can verify it and cite it.

The core claim: cost waste and security risk have the same root cause

An AI agent overspends for one reason above all others: it pulls more into its context than the task requires. It loads tool schemas it never calls, data it never reads, and permissions it never exercises. That is the definition of a cost problem. It is also, word for word, the definition of an access-control problem.

The security discipline already has a name for an agent that holds more capability than its job needs. The OWASP Top 10 for LLM Applications calls it Excessive Agency (LLM06): harm that follows from an agent having excessive functionality, permissions, or autonomy. Excessive functionality shows up on your bill as loaded-unused context. Excessive permissions show up as an agent that can reach systems it never touches. The token meter is measuring your attack surface in real time.

This is the reframe that matters for a security leader: you do not have a cost problem and a security problem. You have one governance problem that presents two symptoms. Fix the root cause, scoped context and scoped access enforced at runtime, and both symptoms shrink together.

Why agentic workloads cost, and expose, so much more than chat

A chatbot processes one prompt and answers. An agent plans, calls tools, reads results, and decides again, so a single request fans out into many model and tool calls, each reprocessing context. Independent measurements put agentic token consumption at multiples of a comparable chat interaction, and for a given operation, calling a tool through the Model Context Protocol (MCP) has been measured at 4 to 32 times the token cost of an equivalent command-line call (OnlyCLI benchmark, 2026).

The heaviest, least visible cost is the tool surface itself. When you connect an MCP server, every tool it exposes loads into the context window on every conversation turn, not only when a tool is used: names, descriptions, parameter schemas, enum values. Independent developer measurements found a single MCP tool definition running 550 to 1,400 tokens, a large server such as GitHub's loading roughly 55,000 tokens before the agent acted, and three connected servers consuming about 143,000 of a 200,000-token window on schemas alone (dev.to, 2026).

For a security leader, read that last figure twice. Before the agent does anything, most of its working memory is a standing inventory of capabilities it may never use, and every one of those capabilities is a path into a system you are responsible for.

What the token bill is telling your security team

Three signals sit inside token data that no finance dashboard is built to read.

1. Loaded-unused context is over-provisioning, made measurable. An agent that repeatedly loads a toolkit and calls two of its forty tools is over-permissioned by thirty-eight tools. The unused thirty-eight cost tokens and widen the blast radius. Token analytics surface this automatically, which makes cost data the fastest scope-tightening tool most security teams are not using.

2. Top-consumer ranking is anomaly detection you already have. The agent, team, or tool burning far more than its peers is either doing more work, or doing something it should not. A ranked view of consumption is a ranked view of where to look first.

3. Unattributed spend is unattributed action. If a line item climbs and no one can say which agent, on whose behalf, ran it, you have the same accountability gap that turns an incident into a forensics project. Cost attribution and security attribution are the same control: every token, like every action, tied to a named agent and a human owner.

The optimization techniques, and what each one is really doing

The engineering community has converged on a clear set of token-reduction techniques. Viewed through a security lens, each one is also a least-privilege or containment control. The evidence is strong and, importantly, much of it comes from the model providers themselves.

A note on the strongest number in that table. In November 2025, Anthropic's own engineering team published a pattern where agents write code to call tools instead of loading every definition into context, and reported a representative workflow falling from about 150,000 tokens to about 2,000, a 98.7% reduction (Anthropic Engineering, "Code execution with MCP," 2025). A byproduct they call out explicitly: because the code runs outside the model, sensitive intermediate data does not have to pass through the model's context at all. That is a cost technique and a data-exposure control in the same design.

Why a bolt-on cost tool does not solve a security leader's version of this

A standalone token-cost dashboard reports spend after the fact, sees only what you point it at, and never connects a dollar to an identity. For a finance owner that may be enough. For a security owner it is not, because the questions you have to answer are governance questions: which agent, acting for which human, loaded which tools, touched which data, under which policy. A cost tool with no identity model cannot answer any of them.

The techniques above only become durable when they are enforced where the agent runs, not suggested in a quarterly review. On-demand tool loading, scoped toolkits, and response trimming are runtime controls. They belong at the same control point that already governs the agent's identity, permissions, and audit trail, because that is the only place that sees every agent, every tool, every MCP, and every skill at once.

This is the architecture Willow is built on. Every agent runs through one control plane for identity, access, and audit, so the token view is a property of the governance layer rather than a separate purchase: consumption broken down by MCP server, toolkit, skill, and tool response, per agent and per human owner, with loaded-unused context and empty calls surfaced automatically and streamed to your SIEM alongside the rest of your security telemetry. One Willow customer cut token use on certain tool operations by as much as 95%, on the same control plane that governs roughly 600 tools and about 5,000 weekly active users at Wix. The savings are what disciplined governance leaves behind.

A governance-led token program, in four moves

1. Instrument before you optimize. Turn on per-agent, per-owner token visibility across every surface. Unmeasured spend is unmeasured behavior. This is the same principle as any security program: you cannot govern what you cannot see.
2. Read the cost data as risk data. Rank top consumers, and treat loaded-unused context as an over-provisioning finding, not a rounding error. Tighten the scope of the worst offenders first.
3. Enforce scope at runtime. Move to on-demand tool loading, expose only the tools each task needs, and trim responses. Least privilege for context is least privilege for capability.
4. Attribute everything to a human. Tie every token, like every action, to a named agent and its owner. Attribution is what makes both the cost and the risk defensible in an audit.

Non-human identities already outnumber human ones by roughly 45 to 1 on average, and by as much as 144 to 1 in cloud-native environments (Cloud Security Alliance, 2026). Each of those identities consumes tokens and holds access. Governing the spend and governing the access is the same work. The organizations that treat token data as security telemetry will cut their bill and shrink their attack surface at the same time, from the same control plane, with the same evidence trail.