On October 17, 2026, OpenCode announced a security breach of OpenCode Console, its cloud-based management service, saying 1.4% of Console users were affected. The notification sent to affected users says API keys for third-party AI services stored in Console may have been exposed. The team links the incident to a "large-scale distillation attack" but has not disclosed how the attackers got in. Credentials that users entrusted to the service so teams could use AI may have been compromised, which raises questions about how API keys are stored and what mechanisms exist to stop misuse after a breach.
Where API Keys Are Stored Determines the Scope of Impact
OpenCode's figure of 1.4% is the share of all OpenCode Console users. It is not the share of all users of the OpenCode app, nor the share of API keys that were exposed. The number of affected users and the total number of keys have not been disclosed. According to the team, the affected users are a subset of those who had connected external AI services, and all of them have been notified by email. It also says that users who did not receive a notification were not affected.
To understand this incident, it is important to distinguish between the OpenCode app, which runs on the user's own machine, and OpenCode Console, the cloud-based management service. In a follow-up post, developer Dax Raad stated clearly that the breach occurred in Console and that the OpenCode app itself was not affected. He also said the API keys the app uses to connect directly to external AI services are not sent to OpenCode's operators.
Indeed, OpenCode's official documentation on connection settings and its explanation of Console provider management show that where an API key is stored depends on how you connect to the external AI service.
| How you use it | Where the external AI service API key is stored | Relationship to this breach |
|---|---|---|
| Connect directly from the OpenCode app to the external AI service | On the user's machine. Keys registered with /connect are saved in a local authentication file |
A usage method the developer distinguishes from the Console breach |
| Register the external AI service in Console and share it within a workspace | Console stores the key and relays requests to the external AI service through a gateway | Some users who had connected external services have been reported as affected |
This difference means that even among people using the same OpenCode, who manages the credentials for external AI services varies. Storing API keys only on your own machine versus registering them in Console to share with a team changes who is responsible for protecting them. The operation name /connect alone also does not tell you where a key is stored. Because there is also a way to use a Console workspace by selecting it, what matters is which destination you registered the external AI service's API key with.
API Keys Remained in a Legacy System Being Decommissioned
According to an image of the notification email shared by a user, OpenCode confirmed unauthorized access to a legacy system it had been decommissioning. As a result, API keys for external AI services such as OpenAI and Anthropic that were stored in Console workspaces may have been exposed to a third party. However, it has not been confirmed that every targeted API key was actually taken or misused.
The notification asks affected users to revoke the relevant API keys in each AI service's management console and replace them with new ones. It also recommends updating the settings of applications that use the replaced keys and checking recent API usage history for suspicious activity. The credentials at issue are those used to call external AI service APIs. They are different from the password used to log in to OpenCode and from API keys issued by Console itself, so care is needed not to confuse them when responding.
In additional guidance shared by Martin Bowling, who received a notification, the API keys stored in the affected legacy Console were listed by workspace name and the last characters of each key. That notification gave 00:30 UTC on October 17 (9:30 a.m. the same day in Japan) as the earliest possible time of exposure. However, this is the time given to a specific user, and it does not mean all targeted keys were compromised at the same moment.
The additional guidance also said no evidence had been found at that point that data other than API keys was exposed. This was an interim report, though, and the scope of damage has not been finally determined. OpenCode also said in its initial announcement that it is continuing its response, and it has not disclosed the vulnerability used in the intrusion or how the stored API keys were encrypted. The information that a legacy system being decommissioned was breached is not enough to conclude that API keys were stored in plaintext or that a specific implementation error existed.
Still, the possibility that valid credentials remained in an environment slated for decommissioning raises an important question about security management during system migrations. Even after a migration to a new system is complete, if valid API keys remain in the old environment, there is still a risk that the credentials could be abused if that environment is breached. Decommissioning a system requires not only shutting down user-facing features but also reliably invalidating and deleting any stored credentials.
What Does "Large-Scale Distillation Attack" Mean?
OpenCode describes the breach as an incident related to a large-scale distillation attack. In AI, distillation is a technique in which the outputs generated by one model are used as training data to transfer knowledge or capabilities to another model. As Anthropic's explanation notes, distillation itself is widely used for legitimate purposes, such as making a company's own models smaller and more efficient. The problem is collecting large volumes of responses from another company's model without permission and using them to develop or improve a different model.
However, API key exposure and a distillation attack are not the same event. If an attacker obtained a third party's API keys, they could send large numbers of requests to AI models and collect the responses while the legitimate owner of the key bears the usage charges. Using that output to train another model could amount to a distillation attack carried out with illegitimately obtained credentials. But how the API keys were obtained, which systems were breached, and whether the collected outputs were actually used for training each need to be verified separately.
The information OpenCode has published so far does not include records supporting that the exposed API keys were used for large volumes of API requests, or concrete evidence that collected outputs were used to train another model. It has also not explained who the attacker was. The operators' description of the incident as a "distillation attack" alone does not tell us why the legacy system was breached or how the API keys were abused.
This distinction also matters when thinking about security measures. Preventing AI model outputs from being used for training without permission and preventing external service credentials from being illegally obtained protect different things. For this incident, the operators are expected to explain not only the link to a distillation attack but also the specific intrusion route into the legacy system and how they identified the API keys that may have been exposed.
Console Budget Limits Cannot Stop Direct Use of Leaked API Keys
Under Console's current specifications, when an administrator registers an external AI service's API key, workspace members can use that AI model without directly seeing the original key. The advantage is that there is no need to distribute individual API keys to each member, and connection settings and usage can be managed in one place. Meanwhile, token usage charges for external AI services are in principle billed to the user by the service provider, and Console records the cost of each request.
Console also offers a feature for limiting monthly budgets. Usage of bring-your-own providers with pricing information configured is also counted, and once the set budget limit is reached, new API requests are rejected. However, the budget is checked when a request starts, so the final amount used can occasionally slightly exceed the limit because of requests already in progress.
The key point is that Console's budget limits apply only to requests that go through Console. If an external AI service's API key itself is leaked and an attacker accesses the issuer's API directly, those requests do not pass through Console's budget controls. Settings on the Console side alone may therefore not be enough to prevent misuse.
Based on Console's specifications for API key management and billing, the range each action can control is summarized below.
| Action | What it controls | Effect if an external API key is leaked |
|---|---|---|
| Set a budget limit in Console | API requests that go through Console | Does not apply to direct requests to the external AI service |
| Remove a provider from Console | Usage settings for providers and models registered in Console | Official documentation does not state that the issuer's API key is also revoked |
| Revoke the API key at the external AI service | Authentication with that API key at the issuer | Prevents future access with the old key. However, charges already incurred are not cancelled |
This comparison organizes the scope of control by the path an API request takes, based on Console's public specifications as of October 19, 2026. It has not been confirmed that direct requests to external AI services were actually used in this attack, and it does not describe the internal structure of the breached legacy system.
Because of these differences, what OpenCode asks users to do is revoke the API key at the external AI service's issuer and replace it with a new one. Even if you delete a provider in Console or change the budget limit, if the issuer's API key remains valid, direct access with that key may still be possible. To prevent misuse of leaked credentials, the old key must be invalidated at the service that actually performs the authentication.
Anthropic Revoked Affected Keys and Urged Users to Replace Them
In an October 17 post, Anthropic's Lydia Hallie said the company worked with OpenCode and revoked Claude API keys believed to be affected by this incident. However, this was a measure targeting suspected keys, and it does not mean revocation has been completed for API keys of all external AI services, including those of OpenAI and Google. The fact that OpenCode named Google as a partner in its response likewise does not by itself confirm that Google API keys were leaked.
Users who received a notification from OpenCode need to revoke the external AI service API keys named in the notification at the issuer and create new ones. They must then also update the settings of applications, automated processes, and integrated services that use those keys. When checking for suspicious API usage or unexpected charges, it is important to cross-check not only Console's usage records but also the usage history and billing information at the external AI service that actually bills you.
Meanwhile, OpenCode's explanation is that users who did not receive a notification were not affected by this breach. There is no basis to assume that users who stored API keys on their own machines and connected directly from the OpenCode app to external AI services were among those targeted. However, if you are unsure which connection method you used, it is a good idea to check your history of registering external API keys in Console and whether you received a notification from OpenCode.
The incident highlights both the convenience of using an AI gateway and the risk of entrusting credentials to an external service. A mechanism that avoids distributing API keys directly to team members has management benefits, but it also makes the storage practices of the service operating the gateway all the more important. In particular, when credentials are deleted from legacy systems, and how targeted keys are identified and reliably carried through to revocation at the issuer when a breach occurs, are points companies should check when choosing a service. How concretely OpenCode explains the intrusion route, the scope of damage, and its API key management and revocation procedures going forward will be an important factor in evaluating the service's security posture.