What happened in the OpenCode Console breach? On 17 October 2026, OpenCode said it had a security breach the previous night, "related to a large scale distillation attack", that affected 1.4% of OpenCode Console users: those who had external AI providers linked1. Its email to those users said provider keys saved in a workspace "may have been exposed"2. The company is working with Anthropic, OpenAI and Google, has published no root cause, and describes the incident as ongoing.
If you ever linked a provider key to the Console, the short answer is: create a scoped replacement key, revoke the old one at the provider, and read your provider usage from 16 October onward. The rest of this page separates what OpenCode has confirmed from what has only been reported, explains where distillation fits, and turns the incident into questions worth asking any tool that stores your provider keys, including ours.
What OpenCode has said
These are the company's own words, from its public statement and the notification email that recipients made public.
| Statement | Where it comes from |
|---|---|
| A security breach "last night" related to "a large scale distillation attack" | OpenCode's public statement, quoted by BleepingComputer1 |
| 1.4% of OpenCode Console users were impacted, a subset who had external providers linked | Same statement1 |
| Affected users were emailed; "If you did not get an email you were not impacted" | Same statement1 |
| Unauthorized access to "a legacy system that we were in the process of decommissioning" | The notification email, quoted by Infosecurity Magazine2 |
| "third party provider keys (e.g. OpenAI, Anthropic) saved in your workspace may have been exposed" | The notification email, quoted by Infosecurity Magazine2 |
| The earliest possible key exposure was 17 October 2026, 00:30 UTC | The notification email, as reported by BleepingComputer1 |
| The incident is ongoing; OpenCode is working with Anthropic, OpenAI and Google | OpenCode's public statement1 |
According to Infosecurity Magazine, the Console stores each workspace's provider credentials and uses them to authenticate requests, so team members do not see the underlying keys2. A co-founder said on X that the breach involved the Console only, not the OpenCode coding agent itself2.
What has been reported, not confirmed
Several details come from users or from interviews and have not been confirmed by OpenCode in a published account:
- Unauthorized charges. Users reported overnight charges ranging from several hundred US dollars to more than $1,7001. These are individual reports, not a confirmed total.
- Suspended cloud projects. Some users said Google suspended their projects after flagging "abusive activity consistent with hijacked resources"1.
- AI agents on both sides. BleepingComputer reported co-founder Dax Raad saying attackers had targeted OpenCode's systems for at least 48 hours using AI agents, and that the models OpenCode used for its investigation refused some requests because of their safeguards1.
- Reimbursement. BleepingComputer reported that OpenCode's message to impacted users mentioned the possibility of reimbursement1. No terms have been published.
What nobody has said yet
As of 21 October, OpenCode has not published:
- How the legacy system was reached, or how long access lasted.
- How keys were stored on that system, and whether they were readable there.
- How many keys were exposed, and whether any were confirmed used by the attacker.
- How the breach and the distillation attack connect.
- Whether the scope (1.4%, linked providers only) could still change.
Until those are answered, the safe reading is the vendor's own: keys saved in an affected workspace may have been exposed, so treat them as exposed.
Where distillation fits
Distillation means training a model on the outputs of a stronger one. It is a standard technique when a lab distills its own models; it becomes an attack when another party extracts a model's capabilities through its API without permission. In February 2026, Anthropic said three labs had generated more than 16 million exchanges with Claude through roughly 24,000 fraudulent accounts, using proxy networks to get around its access rules3. In September, a joint advisory from CISA, the NSA and the FBI named six China-based companies and described the infrastructure such campaigns rely on: accounts not registered to legitimate users, gray-market API proxies, aggregators, relays and pooled accounts4.
That is the background against which a store of working provider keys becomes valuable. Each key comes with someone else's identity, payment method, rate limits and account history, which is exactly what a campaign needs to look like ordinary traffic. OpenCode has not said that exposed keys were used for distillation, and this article does not claim it. What the background explains is why keys to frontier-model accounts are worth stealing in bulk in 2026, and why a leaked key can now produce a large bill overnight. What is an AI distillation attack covers the technique in depth.
If you linked a provider to OpenCode Console
Do this whether or not you received the email. Infosecurity Magazine published a similar list from an incident-response report2.
- List every key. Write down each OpenAI, Anthropic and Google key ever saved in a Console workspace, including keys added by other admins of the workspace. Note which provider project or workspace each belongs to.
- Create replacements first. Issue new keys scoped to a single project or workspace, with the least permissions the workload needs, and set a provider-side spending limit on that project or workspace. This avoids an outage when you revoke.
- Revoke the old keys at the provider. Removing a key from the Console does not revoke it; only the provider can. Revoke even if usage looks clean.
- Deploy and confirm. Update every system that used the old keys, then call the provider with an old key and confirm it is refused.
- Read usage from 16 October onward. Look for unfamiliar models, round-the-clock usage, new regions or a jump in output tokens. Signs your AI API key is being abused lists what to look for.
- Keep the evidence. Export usage and invoices for the period. If you see charges you did not make, contact the provider's support with the key identifier and times, and keep OpenCode's email.
- Check your cloud projects. If a Google Cloud project was suspended, follow the provider's appeal process; what to do when a provider suspends your account walks through it.
Provider-specific runbooks: leaked OpenAI API key and leaked Anthropic API key.
What this says about every tool that holds your keys
OpenCode Console did what many AI tools do, and what an AI gateway does by design: it held provider credentials so people could use models without handling the keys themselves. That pattern is useful, and it concentrates risk. A breached store of keys exposes every account behind it at once, and once a key leaves the platform, nothing the platform does can limit what is done with it.
The questions worth asking any holder of your provider keys:
| Question | Why it matters |
|---|---|
| How are keys encrypted at rest, and where is the encryption key kept? | A key stored next to the data it protects does not protect it. |
| Is there any read path that returns a saved key? | An API, export or support tool that can show a key can leak it. |
| What happens to keys in retired or legacy systems? | Old copies outlive the systems that were supposed to replace them. |
| How fast will you tell me, and what will you tell me? | Rotation can only start once you know. |
| Can I use a key scoped to one project with its own spend limit? | That limit is the only one that still applies after a key leaks. |
The last row is the one you control. A key with a provider-side spending limit, scoped to one project, given to one tool, turns a breach at that tool from an open-ended bill into a bounded one. The trade you make when you give a third-party AI tool your API key goes further.
How INFRO handles the keys you connect
INFRO is a holder of provider keys too: customers connect their own OpenAI, Anthropic, Google and other accounts, and INFRO uses those credentials to serve their requests. The same questions apply to us, so here are the answers.
- Each provider credential is encrypted with AES-256-GCM under a key held as a Worker secret outside the database, with the organization and connection bound in; it is never shown again after it is saved, and no endpoint, console screen or export returns it. The console shows its last four characters. See Connect a provider.
- Applications never hold the provider key. They use INFRO gateway keys, stored only as a digest, which belong to one environment, can be limited to chosen providers or IP ranges, and can be rotated with an overlap window or none. See Authentication.
- Budgets at organization, project, member and key level refuse a request before the provider is called. See spend controls.
- On the Business plan, cost reconciliation compares what INFRO served with what OpenAI and Anthropic report, and with usage access switched on it can show traffic on a provider key that never went through INFRO.
What INFRO cannot do: if a provider key were taken from INFRO, or from anywhere else, it could be used directly against the provider, outside every INFRO budget and allowlist. That is why we recommend connecting a key scoped to a dedicated project or workspace, with a spending limit set at the provider. It is the control that holds even if we fail.
Summary
OpenCode says a breach related to a large-scale distillation attack exposed provider keys saved by 1.4% of its Console users; the cause is unpublished and the incident is ongoing. If you linked a key, replace it with a scoped one, revoke the old one at the provider, and read your usage from 16 October onward. Then apply the same questions to every other tool holding your keys, and make sure each key it holds has a limit set at the provider.