An AI spend control plane is the infrastructure layer that governs what your organization spends on AI on the request path — attributing, capping, and authorizing every model call before the money leaves, not reconciling it after the invoice posts.
That "before, not after" is the whole point, and it's what separates a spend control plane from everything adjacent to it. An observability tool tells you what you already spent. A FinOps dashboard tells you how to think about what you already spent. A control plane decides whether you spend it at all.
The category is new because the problem is new. Enterprise AI spend is compounding at roughly 50% a year, and most of it still runs on shared keys with no owner, no budget, and no attribution. When a leaked key or a runaway agent turns $340 into $34,000 overnight, the native OpenAI, Anthropic, and Google dashboards show you the damage — a day later. A spend control plane is the layer that would have stopped the call at $500.
Why the adjacent framings all miss
Three vocabularies already circle this problem. Each is real, and each stops short.
"AI gateway" (the Portkey framing). A gateway is the right location — a proxy every call passes through — but "gateway" describes plumbing, not purpose. A gateway routes, load-balances, and retries. Governance is an option you bolt on. Calling the thing a gateway puts spend control in the same bucket as rate limiting, when spend is the thing that ends up on the board deck.
"AI control plane / governance" (the Speakeasy framing). Governance is broad: policy, access, safety, model risk, data handling. Spend is one line item inside it, and it's the line item that gets deprioritized when governance means "everything." Bundling spend into general governance is how budget enforcement ends up as a dashboard nobody wired to an actual cap.
"AI FinOps" (the FinOpsLLM framing). FinOps is a discipline — a practice of visibility, allocation, and optimization borrowed from cloud cost management. It's a good practice. But it's an off-path practice: it observes, reports, and recommends. FinOps tells you the search team overspent last month. It doesn't stand between the search team and the provider and say no at token 40,000.
The common failure is position. Gateways treat spend as a feature; governance treats it as a subtopic; FinOps treats it as a report. Spend needs its own plane because spend is the one dimension that must be enforced on-path, before the call — and a plane defined by any of the other three framings enforces from the side, or not at all.
The four functions of a spend control plane
A layer earns the name "spend control plane" when it does four things — not observe them, do them, on the request path.
1. Attribution — the Token Ledger
Every governed call is written to an append-only Token Ledger that answers five questions before a token is spent: WHO (the person or agent persona), HOW MUCH (the budget it draws on), WHY (the project and task), WHERE (the location), and WHEN (the timing).
This is not a log you parse later. It's the authoritative per-transaction record captured at the moment of the call — the same record that produces a chargeback CSV finance can reconcile to the provider invoice, row by row. "Which API key" is not attribution. "Which business unit, on what task, against whose budget" is.
2. Enforcement — hard caps and Virtual AI Keys
Every workload gets a Virtual AI Key (tk_live_…) instead of a raw provider key. Each key carries a hard budget cap and a budget window. When the balance is exhausted, the plane returns a 402 before the call is ever forwarded to the provider. No spend occurs. This is a circuit breaker, not an alert — the difference between "we notified you at $34,000" and "we stopped it at $500."
Enforcement runs on the customer path, including pass-through traffic. A fail-closed PII pre-flight with twelve detectors scans the prompt before it reaches the model; if it can't clear the check, the call doesn't go. Spend-anomaly alerts fire the instant a workload deviates from plan. And because it all sits on-path, semantic caching can short-circuit repetitive traffic and cut 40–80% of that spend at the source.
3. Identity — a key per team, agent, and employee, with a binding second factor
A shared key is an unattributable, unrevokable liability. A spend control plane issues a distinct governed key per team, per agent, and per employee — so every dollar has an owner and any single key can be frozen without touching the rest.
The keys carry a binding-key second factor: a tk_live_… token that leaks without its binding key is a dead key. An attacker who exfiltrates the token string alone cannot spend with it. Identity is what makes both attribution and one-click revocation actually enforceable rather than aspirational.
4. Evidence — append-only audit and a compliance pack
Governance you can't prove isn't governance an auditor accepts. The plane keeps an append-only audit of every allocation and policy decision, and rolls it into a continuous evidence pack mapped to SOC 2, ISO 27001, ISO 42001, and NIST AI RMF. When an auditor asks whether PII can reach your providers, the answer isn't "we have a function developers are supposed to call" — it's a control on the request path with a tamper-evident record behind it.
Spend control plane vs. the adjacent tools
The categories overlap in vocabulary. They diverge sharply on what they actually enforce.
| Capability | Spend control plane | LLM gateway | Observability tool | FinOps dashboard | |---|---|---|---|---| | Enforces on-path (blocks before the call)? | Yes — 402 before spend | Optional add-on | No | No | | Per-key hard budgets? | Yes | Rare | No | Budgets as alerts only | | Five-dimension attribution (WHO/HOW MUCH/WHY/WHERE/WHEN)? | Yes — the Token Ledger | Partial (per-key) | Traces, not budgets | Team/project rollups | | Chargeback CSV finance reconciles? | Yes — to the row | No | Export, not reconciled | Yes (off-path estimate) | | Identity + binding-key second factor? | Yes — leaked token = dead key | Provider keys | No | No | | Compliance evidence pack? | Yes — SOC 2 / ISO 27001 / ISO 42001 / NIST AI RMF | No | No | No |
Read the table top to bottom and the shape is clear: the other three tools are strong at telling you what happened. Only the spend control plane is built to decide what happens — and to prove it afterward.
Where the plane sits
Practically, a spend control plane is a governed proxy your applications point at instead of the raw provider. You change one base URL; your SDK calls, prompt templates, and app code stay the same. Anthropic is served natively; OpenAI, Google/Gemini, Azure OpenAI, and Bedrock run through the governed proxy; and 1,900+ models are reachable via pass-through — all under the same ledger, the same caps, the same audit.
The plane also governs the newer surfaces where spend runs away fastest: an MCP gateway brings agent and tool calls under the same budgets and identity, so an autonomous agent is a persona with its own cap and its subagents roll up under it. And with per-org BYOK, your provider keys stay yours — the plane governs the traffic without ever holding the raw keys in the clear.
See a call get governed
The fastest way to understand a spend control plane is to watch one work. On the live playground you can send a call and see it hit the ledger, draw against a budget, clear the PII pre-flight, and — if it's over cap — get denied with a 402 before a single token is spent.
Watch a call get governed at tokenality.ai/playground.