On October 17th, OpenCode disclosed on its X account that a breach had occurred the previous night, affecting 1.4% of OpenCode Console users. Developers were first tipped off to the attack by bills popping up overnight, with unauthorized charges exceeding $1,700. OpenCode’s disclosure refers to the incident as a “large-scale distillation attack.”
A Vault Built to Keep Keys Hidden
OpenCode Console is a hosted layer of the open-source AI coding agent that enables teams to share models, manage budgets, and connect to external model providers. OpenCode is model-agnostic, connecting to providers including Anthropic, OpenAI, and Google. Console provides a centralized credential gateway that allows team access without exposing provider keys. OpenCode’s email to affected users cites a legacy console system that was in the process of being retired as the entry point for the attack.
The convenience of this tool, while it helps teams coordinate and collaborate on coding projects, also creates a single high-value store of keys. “OpenCode had the right idea in keeping provider keys away from individual developers and brokering every request centrally,” says Shreyans Mehta, co-founder and CTO at Cequence Security. “The tradeoff is that the broker now holds every team's OpenAI, Anthropic, and Google keys, which makes it the most valuable target in the stack.”
What Attackers Want From Borrowed Keys
Bad actors can use stolen OpenCode keys for a wide range of malicious activity, from running workloads for their own ends on the victim’s account to accessing associated files, prompts, and models. They can exploit stolen keys for bulk querying in order to harvest model outputs or train their own cheaper rival models. Using stolen keys also allows threat actors to achieve workarounds if they are located in regions with restricted access to certain AI models.
While it is a possible outcome, some skeptics question OpenCode’s labeling of the activity as a distillation attack. There has not been any information released by OpenCode or otherwise that necessarily supports this conclusion. No actor or threat group has been named.
Targets Shift as Defenses Harden
This incident comes partly in response to recent and ongoing changes in the AI and LLM ecosystem that have made it more difficult to achieve compromise through means that attackers have previously relied upon. Anthropic has instituted new defenses in Claude Fable 5.1 and Opus 5.5, claiming that these changes cut down on harvested output by 90-99%. The networks of fraudulent accounts used by attackers are also drying up, driving bad actors toward other tactics.
Legitimate keys like those stolen from OpenCode provide a much cleaner cover for attackers than many other methods. By using these keys, threat actors can carry out malicious activity under the guise of paying customers, turning their compromised accounts into unwilling and unwitting proxies for attacks.
A Pattern Across Key-Holding Platforms
This OpenCode breach is concerning on its own, but only becomes more so when viewed in the broader context rather than as an isolated incident. Less than two weeks before OpenCode’s disclosure, Fireworks AI experienced an exposure incident that breached customer secrets as the result of an internal credential being compromised.
Credential brokers stand out in today’s vast and intricate supply chain networks as a central repository where highly sensitive information and access are gathered together from many other sources. Third-party gateways multiply across teams using these platforms, compounding risk with each additional user who has access. This makes credential brokers extremely valuable targets for attackers, highlighting the fact that this incident does not come down to an issue with OpenCode, but a much broader threat.
Uneven Cleanup and Unclear Accountability
The disclosure from OpenCode referred to the attack as “ongoing” and assured users that the company was “working with Anthropic, OpenAI, and Google to remediate” the incident. In the wake of the attack, Anthropic and Google have both revoked exposed keys to cut off attacker access, while OpenAI has restored access to legitimate users and issued refunds for unauthorized charges that were made.
Some Google Cloud projects have been suspended as a result of the unauthorized spending carried out by attackers. While remediation and mitigation are ongoing, developers are forced to absorb losses from damage and downtime in the meantime.
Rethinking Who Holds the Keys
This incident highlights the critical importance of taking steps to both prevent similar attacks and mitigate the harm of any such attacks that are successful in the future. These steps include rotating keys from provider dashboards rather than leaving them in place and implementing spending limits on accounts to place a cap on the potential financial damage. Credential brokering services should be scrutinized by users and industries to ensure security, and the different companies involved in stolen-key fraud attacks should assume shared responsibility for the harm done.
