Stolen AI API keys used to be a nuisance: someone found a key in a public code repository and ran up a bill. Two reports from the same week in October show the problem has grown into a small economy. A leaked key can now be resold through cut-price proxy services, fed into criminal hacking tools, or, according to one company, used to help copy an AI model. In each case, the bill goes to the key’s owner.
An API key is a long secret string that lets software use a paid service such as OpenAI, Anthropic or Google Gemini. Whoever holds it can make requests, and the account it belongs to pays for them.
The OpenCode breach
OpenCode makes an open-source AI coding agent, and its hosted dashboard, OpenCode Console, lets users store keys for outside AI providers. On October 17, co-founder Dax Raad said the company had “a security breach last night related to a large-scale distillation attack that impacted 1.4% of OpenCode Console users,” BleepingComputer reported. Only users who had linked keys from Anthropic, OpenAI or Google were affected, and the company emailed them.
Affected users reported unauthorized charges from several hundred dollars to more than $1,700 overnight. Some said Google suspended their cloud projects for “abusive activity consistent with hijacked resources.” OpenCode said it was working with the three providers and mentioned possible reimbursement, but has not said how the attackers got in.
The “distillation” label is OpenCode’s own and has not been explained. Distillation is a normal machine-learning technique: a smaller model is trained on answers produced by a larger one. It becomes an attack when someone does it at scale through access they are not entitled to, which is why AI companies treat mass, unpaid querying of their models as a threat. Stolen keys would let someone do that on another person’s account. Whether that is what happened at OpenCode, the company has not shown.
A hacking tool that runs on other people’s keys
A day earlier, Help Net Security described research from Bitsight, a security ratings firm, which tracked thousands of posts on 16 underground forums from February through August 2026. One find was MONST3R-AI, sold on a restricted criminal forum as an autonomous penetration-testing platform.
The tool hosts no AI model of its own. A buyer pastes in stolen OpenAI, Anthropic or Google keys, sets a budget cap and points the agent at a list of targets. The seller’s dashboard claims 1,072 findings across 199 scanned hosts. Bitsight says it cannot verify those numbers, but expects stolen keys to be sold “purely to fuel scanners like this one.” The design has a second advantage for criminals beyond free computing: the person paying is a stranger who has no idea their account is being used.
Where stolen keys end up
Palo Alto Networks’ Unit 42 research team describes the resale side in a report on what it calls “AI token jacking.” Gray-market “transfer stations” resell access to AI models far below official prices, often running on open-source proxy software. To make the numbers work, many rely on stolen keys. In one case Unit 42 handled, exposed credentials were plugged into such a service “within minutes,” and the victim ran up nearly $1 million in charges before the abuse was found and stopped.
Unit 42 lists the usual ways keys leak: phishing, password-stealing malware, poorly secured file shares, public code repositories and poisoned software packages that harvest credentials from developers’ machines. The OpenCode case adds another route: a third-party service that stores keys on users’ behalf.
Who pays
The losses can be large for small teams. In February, a three-person startup in Mexico that normally spent about $180 a month on AI services said a compromised Google Cloud key ran up $82,314.44 in charges in 48 hours. Unit 42 notes part of the reason such bills grow so large: billing runs in cycles, and many providers do not cap usage by default, so victims often find out only when the invoice arrives.
For developers, the defensive steps are well known but often skipped:
- Keep keys out of code, client-side scripts and build logs; store them in a secrets manager.
- Use separate keys for development, testing and production, so one leak does not expose everything.
- Set hard spending limits and alerts for sudden jumps in usage, where the provider allows it.
- Prefer short-lived tokens over long-lived keys, as Unit 42 recommends.
- Be careful about which third-party tools you give keys to. If you used OpenCode Console with linked providers, revoke those keys in each provider’s dashboard and check recent usage.
Code platforms are a target in their own right, as the recent theft of source code and staff data from Meta’s GitHub repositories showed.
Our take
Developers deserve blame for keys left in public code, but the bigger design flaw sits with the providers. An account that normally spends $180 a month should not be able to spend $82,000 in two days without a hard stop. Telling customers that credentials are their responsibility made sense when a stolen key meant a modest bill; it makes less sense now that stolen keys feed resale proxies and attack tools at industrial scale. Hard spending caps that are on by default would not stop key theft, but they would cap the damage, and the companies best placed to switch them on are the ones collecting the revenue.