LLMjacking — how AI key theft works, and how to stop it
Last verified
LLMjacking is credential theft with a resale market attached. Someone harvests your AI API key, then uses it — or sells access to it — while your account absorbs the bill. It is automated, continuous, and indifferent to how small your project is.
Why it exists
Frontier model access is expensive and rate-limited, which creates demand for stolen access. That demand makes harvesting worth automating, and automation is what turns "someone might find my key" into "something will find my key, quickly."
The economics are simple and unfavourable to you:
- The attacker's cost of using a stolen key is zero.
- Your cost is metered, real, and charged to a saved card.
- Detection is your job, and the billing data that would reveal it lags by a day.
How keys get harvested
Public repositories. The largest source. Scanners watch the public events stream and pull credentials within minutes of a push. Deleting the commit afterwards does not help — see why.
Mobile app binaries and traffic. Keys compiled into an app are extractable, and keys sent from a device are observable. A 2026 network-traffic study found 282 iOS apps leaking LLM API keys. Obfuscation does not fix this — see why you can't ship an API key in a mobile app.
Client-side JavaScript. Anything in a browser bundle is public. Not "hard to find" — public.
Notebooks and gists. Jupyter output cells persist secrets even after the source cell is edited, which catches people who think they cleaned up.
Pastebins, Discord, screenshots, and chat logs. Including pasting a key into an LLM.
Compromised developer machines. Infostealer malware specifically targets .env files, shell history, and cloud credential stores.
What it costs
Reported outcomes cluster around "far more than you would guess":
- 1Password has documented scanners actively harvesting exposed OpenAI keys from public sources and running up charges against the owner.
- Worst-case abuse of stolen credentials has been reported in the tens of thousands of dollars per day, because an attacker with free access has no reason to be efficient.
- Providers generally do not refund this. The account holder is responsible for usage on their keys.
The multiplier that turns a bad day into a catastrophic one is auto-recharge. A drained balance that automatically tops itself up from a saved card removes the only natural brake in the system. Turn it off.
Controls that actually help
Ranked by effect, not by how sophisticated they sound.
1. A hard spend limit. The only control that bounds your worst case regardless of what else fails. Set it below what you would be upset to lose. What provider spend limits do and don't protect you from.
2. Auto-recharge off. Removes the mechanism that turns a capped loss into an uncapped one.
3. Secrets never in source. Environment variables and a secret manager, plus a pre-commit hook and push protection so the mistake is blocked where it's free to fix.
4. A backend proxy for any client app. Web and mobile clients call your server; your server holds the key. There is no version of client-side key storage that is safe.
5. One key per service. Not security theatre — it is what lets you answer "which key is the problem?" and revoke precisely instead of taking everything down.
6. Something that looks at daily spend for you. Every detection signal in how to tell if someone is using your key requires somebody to go and look. Nobody opens a billing console on a normal Tuesday. That gap — between the abuse starting and anyone noticing — is what decides the size of the number.
That last one is the whole premise of TKN: today's spend across OpenAI, Anthropic, xAI and Gemini on one screen, checked against a rule you set, with a kill switch that revokes at the provider from your phone.
If it has already happened
Work the incident in order — your OpenAI API key leaked has the full sequence. Short version: revoke, reissue, check usage, cap the account, then clean up the source.