Users' OpenAI, Anthropic and Google keys reportedly leaked from OpenCode Console's legacy system, hitting 1.4% of users, with some charges topping $1,000 from mass distillation calls

A legacy system behind the Console run by AI coding tool OpenCode was breached, and the OpenAI, Anthropic and Google API keys that users had stored there were stolen, TechCrunch (October 19) and SecureWorld (October 20) reported. According to the reports, 1.4% of users were affected. The stolen keys were used for heavy call volumes that appear aimed at distillation, which means collecting another company's model outputs to train your own model. Some users reportedly received charges of more than $1,000. We have not yet been able to find a primary statement from OpenCode itself. All figures below come from these reports.

The real issue here is less how the attackers got in than what kind of keys were stolen. A provider API key works for anyone who holds it. It has no expiry and no owner. When such keys are gathered in one place, a breach of that one place is enough to run up charges at three providers' accounts in other people's names.

What was reportedly leaked

According to the reports, the breached system was not OpenCode's core product but a legacy system behind the Console. Users had registered their own OpenAI, Anthropic and Google keys there. OpenCode co-founder Dax Raad reportedly described how the core product is built as follows.

In other words, the tool users normally run on their own machines does not send keys to OpenCode. The old Console was the exception, because it was designed to store keys. Even if the new architecture is secure, a single storage point left in an old path becomes the weak spot for the whole system. This incident shows that.

Raad also described something that happened during the investigation. When he asked an AI to analyze the code used in the attack, its safety filters refused.

Defenders who turn to models for an investigation can still be refused when they ask for attack code to be analyzed. The labs have been expanding vetted-access programs that decide how much cyber capability to open up. Those programs evidently had not reached a small developer investigating an incident as it happened.

Stolen keys aren't used to break in, just to make calls in someone else's name

Experts at security firms have pointed to this structure. Chris Hughes of Noma Security sees the problem in the practice of collecting and holding keys itself.

If a single tool holds keys for three providers, one intrusion gives an attacker access to accounts at all three. However much the providers harden authentication and monitoring, it does not help once the keys leak from the tool.

Shreyans Mehta of Cequence Security explained how stolen keys are used.

Because the key stands in for identity verification, requests made with a stolen key look to the provider like they come from the legitimate user. For the attacker, mass calls for distillation amount to free training data, while the bill goes to the user's account. Charges of more than $1,000 put a number on that imbalance.

Some labs are stepping up their defenses against distillation. In an October 12 research page, Anthropic wrote that it uses classifiers to stop accounts that attempt distillation, and disclosed that it has charged for refused requests since September 24. The measure makes sense. But when distillation requests are sent with a stolen key, the victim who owns the key may also be billed for the blocked requests. The reports do not say whether the charges in this case included any such requests.

The only fix was revoking keys at each provider

According to the reports, the only way to stop the damage was for users to revoke their keys at OpenAI, Anthropic and Google, one provider at a time. OpenCode cannot revoke keys that have already gotten out. Because the keys have no expiry, they never lapse on their own. And because they are not tied to a specific tool or device, providers cannot tell the attacker's calls from the user's own. Charges keep growing until users notice the leak and finish going through all three providers' dashboards.

As agents are increasingly left to work for long stretches, it has become normal for a single development environment to switch between models from several providers. Handing all your keys to a harness or ADE is convenient. The cost of that convenience is that bearer keys end up gathered at an intermediary. SecureWorld points to the fact that no one governs these keys.

The incident offers three lessons. First, if you hand keys to a tool, issue dedicated keys with limited scope and expiry. Second, set usage caps and alerts for unusual usage at each provider. Third, check that no keys remain in old admin dashboards or systems that have not yet been migrated. In this case, none of these safeguards were in place, a single legacy system was reportedly breached, and other people's usage ended up on bills from three providers. It is not yet known how OpenCode will handle the charges for affected users, or whether the providers will reverse the fraudulent charges.