Someone else is spending your AI budget on a leaked key

Adding an AI feature to something is easy now. You sign up for an API key — a long secret string that lets your code talk to OpenAI, or a cloud service, and bills you for what it uses — you paste it into the app to get things working, and you move on to the next thing. The feature works. The key sits where you left it.

The trouble is where “where you left it” often turns out to be. A key pasted straight into the source code gets committed to a repository and, if that repository is ever public, published to the world along with it. A key baked into a phone app ships inside the app, where it can be extracted. A key dropped into a config file gets copied to somewhere it was never meant to go. And a working key is money: it doesn’t need to be cracked, only found and used.

This is the quiet failure. It isn’t a dramatic breach with a locked screen and a ransom note — it’s a live credential quietly spending your money in the background. Bots crawl public code and app stores looking for exactly these strings, and because a leaked key so often keeps working for months or years — GitGuardian found that 64% of the secrets it saw leak in 2022 were still live at the start of 2026 — the bill just grows while everything appears to be running normally.

Why it stays invisible

There’s no alarm for this. Your app keeps working, because the key is still valid — that’s the whole point of it. The stranger using it isn’t breaking anything; they’re using the same door you use, for their own purposes, on your account. The only trace is on the invoice, and only if someone looks at the invoice closely enough to notice it climbing.

Meanwhile, finding the key took no effort at all. Automated scanners watch public code repositories and released apps continuously, matching the tell-tale shape of provider keys the moment one appears. The scale is sobering: one 2026 analysis by Cyble turned up more than 8,000 ChatGPT keys sitting in public GitHub repositories and live websites, and researchers at Wake Forest University found 282 of the 444 AI-powered iPhone apps they tested leaking their AI credentials in ordinary network traffic. There are even botnets built for the hunt — one called NadMesh, spotted in July 2026, does little else but scan for exposed AI services and harvest the credentials behind them. So the exposure is doubly quiet: silent on your side, and instantly discoverable on theirs.

Find it yourself

You can check the two things that matter — is money leaking, and is a key exposed — in about ten minutes.

1. Read the meter. Sign in to each AI or cloud provider you use and open its usage or billing dashboard. Look at usage over the last few weeks against what you’d expect. Spikes at odd hours, models you don’t use, or requests from unfamiliar places are the fingerprints of someone else on your key.
2. List your keys. In the same account, open the API keys section and look at every active key. If there are keys you don’t recognise, can’t account for, or that predate anyone remembering why they exist, treat them as suspect.
3. Check the obvious hiding places. Look at whether any key is sitting in a place it could escape from: hard-coded in source that’s in a shared or public repository, committed in an old .env file, or built into a phone or desktop app you’ve shipped.
4. Search your own code. If you keep code anywhere searchable, search its whole history — not just the current version — for the shape of your provider’s keys (for example a string beginning sk- for OpenAI — newer project-scoped keys start sk-proj-). A secret is exposed the moment it enters the history, even if a later commit removed it.

No code repository to search? The billing dashboard in step 1 is the check that matters most, and it needs nothing technical — if the usage looks wrong, act on the fix below regardless of where the key turns out to have leaked.

The fix

The aim is to stop the current leak and make the next one both less likely and less painful.

Rotate, don’t just delete. This is the part people get wrong. Deleting a key that’s already loose doesn’t undo the exposure — the damage is a key that got out. Instead, rotate: create a new key, update your app to use it, and only then revoke the old one. Rotating cuts off whoever has the old key while keeping your own service running.

Keep keys out of code. Store secrets outside the source entirely — in environment variables or a secrets manager the code reads at run time — so a key can never be committed to a repository or shipped inside an app in the first place. If a key has ever been committed, assume it’s compromised and rotate it, even if the repository is private now.

Put a ceiling on the damage. Most providers let you set spending limits and usage alerts on a key. A hard monthly cap and an email alert turn a silent, unbounded leak into a small, noticed one — the difference between a nasty surprise and a quick phone call.

Make rotation a habit. Keys accumulate — for old projects, former staff, one-off experiments. A periodic review that revokes the ones nobody can explain keeps the list short, and a short list is one you can actually watch.

None of this requires a security team. It needs someone to look at the meter now and then, and to treat every key as something that will eventually get out — so that when one does, it’s already capped, already replaceable, and gone within the hour.