The Key You Handed Your Agent Was Being Used to Train Someone Else's AI — Anthropic, OpenAI, and Google Keys Leaked from OpenCode's Console
OpenCode, a terminal-based coding agent, disclosed a breach of its cloud-hosted Console. The OpenAI, Anthropic, and Google API keys of roughly 1.4% of users who had connected external keys may have been exposed, with some reporting hundreds of dollars in fraudulent charges. Rotate keys, set spending
OpenCode, a terminal-resident coding agent built by Anomaly Innovations, disclosed on October 17 that a breach of its cloud-hosted "Console" product may have exposed the third-party provider API keys that users had entrusted to it. The breach affects roughly 1.4% of Console users — those who had connected external keys — and the keys potentially exposed belong to OpenAI, Anthropic, and Google. Some users are already reporting unexplained charges running into the hundreds of dollars. OpenCode had just rolled out "2.0" with background execution and code mode, which frames this as a stumble on home turf for a project with real momentum.
A "Legacy System" Slated for Retirement Became the Entry Point
According to OpenCode, the intrusion hit a legacy system that was already being prepared for shutdown, and the user-workspace API keys stored there were pulled out. The crucial point is that what leaked were keys entrusted to the Console (the hosted dashboard) side — kept separate from the agent itself that runs locally on your machine. Flip that around, though, and it means the very mechanism of pooling keys in one place for the sake of convenience is what fattened the attack surface.
OpenCode sent notification emails on October 17 and officially states that "if you didn't receive an email, you're not affected." It says it is coordinating its response with Anthropic, OpenAI, and Google, but as of publication the incident is described as ongoing, and the precise method of the initial intrusion has not been made clear. This is a stage where firm conclusions should be avoided.
The Goal Appears to Have Been "Training Data for a Cheap Imitation Model"
OpenCode links the incident to a large-scale "distillation" attack. Distillation is a technique that collects a high-performing model's responses en masse and uses that output as training material to raise a cheaper, competing model. With stolen keys, an attacker can run queries against expensive frontier models on the victim's dime, harvesting training data without bearing the compute cost themselves. The spikes in users' bills are believed to stem from exactly this — bulk queries issued under someone else's name. That said, it has not been confirmed that the leaked keys were actually used for that purpose, and attribution of the attack is reported to remain, for now, no more than conjecture.
Rotate the Keys, Set Caps, and Close the "Open-Ended Bill"
Whether or not you were affected, reissuing keys is free and there's no downside to doing it. Here are the steps the various reports recommend, laid out in order.
- Revoke and reissue keys directly from each provider's management console. Don't click links in emails (risk of phishing). Do it in the respective OpenAI, Anthropic, and Google dashboards.
- Review your usage logs and billing from October 16–17 onward and check for any suspicious queries.
- Set per-key spending caps. All three providers support budget limits, so build the "even if stolen, it won't run unbounded" state ahead of time.
- Update everywhere that references the old keys — track them down across CI/CD,
.envfiles, team settings, and other tools. - If you see fraudulent charges, file a billing dispute with timestamps.
One explainer puts it this way: "Per-key and per-credit caps turn a stolen key from an unbounded bill into a capped one," noting that many developers tend to put off this setting until an incident actually happens.
"Keys You Entrust Are Only as Safe as the Worst-Maintained System They Touch"
Agents like OpenCode hold the user's own credentials in order to read files, call external APIs, and run commands. The key isn't a convenience accessory; it's a core component the agent can't operate without. OpenCode's own documentation had already warned that it "does not sandbox the agent" and that "permission prompts are UX, not a security boundary." That's precisely why the design of where and how you entrust your keys matters. Here are measures a team can take:
- Narrow the keys: drop shared keys and split them per developer and per project.
- Move where they're stored: favor a managed secrets vault over a hosted dashboard.
- Inject them at runtime: slotting a key in at the moment it's needed, rather than stockpiling it centrally, shrinks the blast radius when something leaks.
The more work you hand to coding agents, the more parties you end up entrusting with your highest-value asset — your keys. This incident drives home an old lesson that's new again: wherever you entrust them, they are only as safe as the worst-maintained system in the chain. You don't have to give up the convenience, but a key inventory and spending caps are the kind of operational habit you want baked in before an incident, not after.
References: Cybersecurity News: OpenCode Security Breach / Crypto Briefing: OpenCode distillation attack / Startup Fortune: urgent key rotation / ExplainX: What to do


