Tokenmaxxing Is a Security Metric, and Nobody Is Measuring It That Way

Token-spend leaderboards are the hot productivity metric of 2026. They are also an unread map of where an organization's agentic blast radius is growing fastest.

Share
A laptop screen showing performance analytics graphs
Photo by Luke Chesser on Unsplash

There is a strange contest running across the tech industry right now. Nvidia's Jensen Huang says a $500,000 engineer who is not burning $250,000 a year in tokens should deeply alarm him. At Meta, an employee built an internal leaderboard called Claudeonomics that ranked more than 85,000 staff by token consumption, until it was quietly shut down two days after it made the news. Token spend has become the productivity metric of 2026: simple, visible, and endlessly gamified. As far as I can tell, almost nobody has connected it to the thing security teams actually care about, which is attack surface.

That is the gap this post tries to close. Token volume by department is not just a finance curiosity. It is a rough, real-time proxy for where an organization's agentic blast radius is growing fastest.

Where the tokens actually go

Skip the aggregate headlines for a second, the quadrillions of tokens processed per month and the nine-figure enterprise model deals, because they hide the pattern that actually matters, which is concentration. The clearest public data point comes from Pylon, whose CEO Marty Kausas shared the company's forecasted Claude spend by department. Out of roughly $118,000 a month, engineering alone accounted for about 63 percent, close to $75,000. Support followed at 9 percent, sales at 8 percent, founders at 5 percent, and everything else, product, design, finance, and ops, trailed into low single digits. Per person, engineering was spending around $3,000 a month on Claude alone, and Kausas estimated the true figure across all coding tools was closer to $5,000.

That is not an outlier shape. Across enterprise surveys, engineering and customer support consistently lead AI adoption, with finance, HR, and operations only now catching up. And coding tasks are disproportionately expensive per unit of work. A simple query might cost a few hundred tokens, while agentic coding work, which reasons across a codebase, iterates, and calls tools, can burn tens of thousands. The spread on a single seat license can be absurd: an employee doing email summarization might use 10,000 tokens a day, while another doing code generation on the same license might use 10 million. A thousand to one, invisible from the invoice.

A caveat, because the "everyone is tokenmaxxing" narrative oversells itself. SemiAnalysis and others have found that most employees never come close to their caps. Usage follows a power law, where a handful of people spend four or five figures a day and everyone else spends almost nothing. Even the vendors report the same distribution: typical Claude Code spend per developer runs in the low hundreds of dollars a month, and only a small fraction of users exceed a few tens of dollars a day. The Meta and Nvidia headlines look less like proof that every organization is building a token bonfire and more like a story about incentives and oversight. Kausas himself now says the era of tokenmaxxing is ending, and has started requiring his support team to request approval for additional tokens.

But the shape still holds directionally, and it is the shape that matters for security: token spend concentrates in engineering, and engineering is where agents get the deepest access.

The part nobody is pricing in

Here is the inversion. The departments winning the internal token leaderboards are not just spending money. They are the departments whose AI agents hold OAuth tokens, API keys, repository access, and infrastructure permissions. Token consumption and token exfiltration risk are starting to rhyme, and I do not think that is a coincidence.

A few things worth sitting with.

Agents are identities now, and under-governed ones. As I argued in an earlier post, AI agents authenticate, hold credentials, and carry network permissions just like human users, except they are typically provisioned without lifecycle management, least-privilege review, or behavioral monitoring. Teams optimize for functionality first. Access controls are an afterthought, if they happen at all.

The credential is the actual target. To function autonomously, an agent often needs broad access to code, cloud infrastructure, and internal databases. If that agent is compromised, through prompt injection, a poisoned document, or a malicious issue in a repository it reads, the attacker does not need a new vulnerability. They inherit whatever the agent already had. This is the lethal trifecta again: private data, untrusted content, and a way out, wired into a single non-human identity.

This is not hypothetical. In a controlled red-team test, the security firm CodeWall pointed an autonomous agent at McKinsey's internal AI platform, Lilli, a tool used across the firm's tens of thousands of employees. The way in was almost embarrassingly simple. The agent mapped Lilli's publicly exposed API documentation and found that 22 of more than 200 documented endpoints required no authentication at all. In about two hours it reached 46.5 million chat messages in plaintext, 728,000 files of confidential client data, 57,000 user accounts, and 95 of the system prompts governing the AI's behavior. It is exactly the engineering-tooling compromise you would expect, given where the token spend, and therefore the access, actually sits.

And the blind spot is bigger than most teams realize. A Cloud Security Alliance study found that more than half of organizations have already had AI agents exceed their intended permissions, reaching systems or data they were never scoped for. A third have no audit trail at all, meaning they cannot reconstruct what an agent did after the fact. That is not a gap you patch later. It is a visibility gap in production right now, at the exact moment agentic coding tools are being rolled out to thousands of engineers at once.

Why this matters for how we measure AI risk

Right now, token consumption is used almost exclusively as a productivity and adoption signal, a stand-in for how much a team is actually using AI. That is a reasonable first-order metric. But it is also, unintentionally, a map of where an organization's non-human identity sprawl is expanding fastest, and where the blast radius of a single compromised agent is largest.

If I were advising a security team today, I would want the token-spend dashboard and the agent-identity inventory to be the same dashboard. Not because engineering teams are doing anything wrong by using AI heavily, they are not, but because the department topping the token leaderboard this quarter is, almost by definition, the department where an attacker gets the most for a single successful prompt injection.

Nobody has built that correlation publicly yet. Someone should.