Every company that adopted AI quickly has a version of this moment. Someone finally sits down to map the AI bill to teams and products, gets through the obvious entries, and is left staring at a stubborn remainder: spend flowing through API keys that no current employee admits to creating, projects named test-v2-final, a service account that predates the reorg, a key that turns out to be embedded in a demo that never got turned off.
This is shadow AI — AI usage that generates real invoice spend but has no accountable owner in your attribution map. The name borrows deliberately from "shadow IT," but the AI variant has a sharper edge: creating usage requires nothing but a key, keys multiply through copy-paste, and the resulting spend arrives co-mingled on one invoice with your production workloads.
Shadow IT took effort — someone had to procure a tool, expense a subscription, onboard a vendor. Shadow AI takes an environment variable. The unit of adoption collapsed from "a purchasing decision" to "a string pasted into a config file," and governance built around purchasing decisions never sees it happen.
Three structural features make the resulting spend hard to claw back into view:
Keys outlive their context. The person who minted a key for a hackathon leaves; the key keeps working. The prototype gets forked; the key travels with it. Provider consoles will tell you a key exists and what it spent — they cannot tell you what organizational purpose it currently serves, because that fact lives in your company, not the provider's database.
Naming is folklore. Key and project names encode meaning that was obvious to one person at one moment — and to no one else ever again. Attribution built on "we'll recognize it from the name" degrades with every quarter and every departure.
The bill aggregates what governance never separated. The invoice arrives as totals per project or per key at best. If the key-to-owner mapping doesn't exist on your side, no amount of staring at the bill reconstructs it.
Faced with an unattributable remainder, most allocation processes do the institutionally comfortable thing: spread it. Peanut-butter the orphan spend across teams proportionally to their known usage, or park it in an "infrastructure overhead" bucket, and the reports look complete again.
This is the worst available move, for two reasons.
First, it destroys the incentive to fix the mapping. Spend that is invisibly redistributed generates no questions; a line item named "unattributed" generates them every month until it shrinks. The discomfort is the mechanism — smoothing it away is anesthesia, not treatment.
Second, it silently corrupts every downstream number. Unit economics per feature, cost per customer, margin by product line — each inherits a share of spend that belongs to none of them. Decisions made on those figures inherit the error. You cannot make a per-feature number honest by hiding an unallocated remainder inside it; the honest report says this is what we can attribute, this is what we cannot — yet.
The design principle we hold is simple to state: unmapped spend is a reported state, not an error to be smoothed over. An attribution system should show the unattributed remainder openly — sized, trended, and named — the same way a serious reconciliation shows its residual instead of absorbing it.
From that principle, a workable process for hunting down ownerless keys follows almost mechanically:
1. Inventory before interpretation. Enumerate every key, project, service account, and workspace across your AI providers — from the provider consoles themselves, not from tribal memory. The list is the ground truth of what can spend money; folklore about what "should" exist comes second.
2. Attribute deterministically first. Most spend can be mapped by rules that need no judgment at all: this key belongs to that team's project, this service account deploys from that repository, this metadata tag names that application. Rules can be checked by reading them, are cheap to run, and never guess. Exhaust them before anything cleverer touches the data.
3. Let suggestions be suggestions — and approvals be human. For the remainder, tooling (including ours) can propose likely mappings with stated reasoning — "this key's usage pattern and naming resemble team X's staging environment." The hard line: a proposal enters your cost attribution only after a human accepts it, and every accepted mapping is recorded — who approved what, when, and why. Attribution that guesses silently is just estimation wearing a costume.
4. Publish the remainder. Whatever survives steps two and three appears in your reporting as unattributed, with a dollar amount and a trend line. The goal is not zero on day one; the goal is a number that is visible, owned, and shrinking.
5. Close the loop at creation. The durable fix is upstream: new keys get an owner, a purpose, and an expiry at minting time. The hunt you are running now is the one-time cost of not having done this earlier; the policy makes it the last hunt.
Attribution and invoice reconciliation are different disciplines, and conflating them flatters neither. Reconciliation ties invoice totals to independently recomputed usage — it tells you the bill is right. Attribution divides those verified totals among teams and products — and its precision depends on the quality of your telemetry and your mapping, not on the invoice. A bucket can tie out to the bill perfectly while its internal split across teams is only as good as the tags feeding it. Honest tooling keeps the two claims separate; we go out of our way to.
That stance is baked into ToTheCent: the unattributed remainder appears the same way every unexplained dollar does — as a first-class output with a name and a number — because spend you can see is spend someone will eventually own.