Runaway Tokens Are a Governance Problem
Ask a security leader to name their biggest AI risks and you’ll hear the usual list: data leakage, prompt injection, models saying something they shouldn’t. All real. All worth defending against.
But there’s a risk that rarely makes the list because it wears a finance costume: unbounded, unattributed, ungoverned AI consumption. A key with no limit. A team with access to the most expensive model and no ceiling. A workload that can, through a bug or a bad actor or just enthusiasm, generate an unbounded bill against your accounts with nothing standing in the way.
That’s not a finance problem that happens to involve tokens. That’s a missing control. And the reason it stays off the risk register is that most organizations have no mechanism to treat it as one - no way to scope access, no way to set a limit, no way to know it was breached. This piece is about closing that gap with the same discipline you’d bring to any other control.
Consumption is an attack surface
Start by naming it plainly. Every path to a paid model is a way to spend your money. If that path has no identity, no scope, and no limit, then anyone or anything that reaches it can spend without bound. We’d never accept that for a database or a cloud account. We’ve quietly accepted it for LLMs because the spending is metered in tokens instead of dollars, and tokens don’t feel like money until the invoice lands.
They are money. A loop that retries against a frontier model, a leaked key pasted into the wrong place, a batch job pointed at the premium tier by mistake - each of these is a financial incident waiting to happen, and none of them trip any alarm today because there’s no threshold defined to trip.
The mindset shift is small but important: treat spend limits as security controls, not budget suggestions. Once you do, the tools to enforce them start to look familiar.
Identity: every request should be attributable to something
You can’t govern what you can’t attribute. The first control isn’t a limit at all - it’s identity.
In this model, applications reach models through virtual keys rather than raw provider credentials scattered across environments. A virtual key is an identity: it’s issued, it’s tracked, and every request made with it carries that identity through to the spend record. That single design choice does something powerful - it means there’s no such thing as anonymous spend. Every dollar traces back to a key, and every key traces back to an application, a team, and a cost center.
This is the least privilege applied to money. Just as you wouldn’t hand every service the same all-powerful database credential, you don’t hand every workload an unscoped path to unlimited model spend. Each gets its own identity, and that identity is the anchor for everything that follows.
Scope: contain the blast radius
The second control is scope, and it borrows directly from how you already think about limiting blast radius.
Spend is organized along a hierarchy - organization at the top, then cost center, then group, then individual user - plus attributes like the model family and the specific key. Any control you set can attach to any point on that hierarchy. You can govern an entire organization with one broad rule, or reach down and govern one team’s use of one provider, or one specific key.
That range is what lets you contain damage. A limit high in the hierarchy is a backstop that catches everything. A limit deep in the hierarchy is a precise constraint on a known-risky workload. Used together - a sensible default at the top and tighter limits carved out below it - you get defense in depth for spend: nothing is unbounded, and the riskiest paths are bounded tightest. A problem in one corner stays in that corner instead of becoming an organization-wide event.
Enforcement: detective and preventive controls, by design
Now the limits themselves. This is where the security framing pays off most directly, because budgets come in exactly the two flavors your control framework already recognizes.
A budget can respond to a breach in one of two ways, and the choice is yours per budget:
Audit mode is a detective control. When the limit is crossed, it’s recorded and surfaced, but traffic keeps flowing. Nothing is blocked. This is how you roll a control out safely - you turn it on in audit first, watch what would have been stopped, confirm you’ve scoped it correctly, and build the case before you ever risk interrupting real work. It’s also how you keep an eye on slices where you want visibility but not a hard stop.
Block mode is a preventive control. When the limit is crossed, further spend against that slice stops. This is the circuit breaker - the thing that turns “we found out about the runaway job on the invoice” into “the runaway job was stopped at the limit and never became an incident.”
The same budget mechanism serves both. You typically start a control in audit, prove it’s scoped right, then promote it to block once you trust it. That’s a familiar, disciplined rollout path - the same one you’d use for any new enforcement control - and it’s built into the model rather than bolted on.
Consider a real one: a support team with a monthly dollar limit set to block. It’s sitting at 112% of its limit. In an ungoverned world, that overage is invisible until the bill arrives, and by then it’s spent. Here, the control already did its job - spend against that slice is being stopped at the ceiling, the breach is visible in real time, and the number that matters is on screen, not buried in a statement four weeks late. The overage you see is the control working, not the control failing.
Continuous compliance, not a quarterly scramble
The last piece is the part that makes this sustainable: it’s continuous, not periodic.
Every budget shows its live state - how much of the limit is consumed, whether it’s on track or over, right now. There’s no month-end reconciliation to discover you blew past a limit three weeks ago. The posture is always visible, the way a good monitoring system shows you control health at a glance rather than in a quarterly report.
That’s what “continuous compliance” actually means in practice: not a heroic audit every quarter, but a standing view where “are we within our limits” is answered at all times, and a breach is a real-time signal rather than an archaeological finding. For anyone who has to attest that controls are in place and operating, the difference between “we check quarterly” and “it’s enforced continuously and visible now” is the whole game.
Put it on the register
Unbounded AI spend has every quality of a risk you’d normally track: it’s exploitable, it’s expensive, it’s currently uncontrolled, and until now it’s been effectively invisible. The only reason it’s not already on your risk register is that it didn’t used to have a control you could point to.
Now it does. Identity through virtual keys. Blast-radius containment through scoped dimensions. Detective and preventive enforcement through audit and block budgets. Continuous visibility instead of after-the-fact discovery.
That’s not a finance dashboard. That’s a control. Treat it like one, and the runaway token bill stops being a surprise you explain after the fact and becomes a risk you manage in real time - like everything else you’re responsible for.
This concludes the series. Part one showed how to make AI spend visible; part two laid out the maturity ladder from attribution to optimization; this part reframed the whole thing as the governance control it always was.
%20(1).png)
%20a%20Bad%20Idea.png)
