OpenCode Console breach exposes AI provider keys for some users

On the night of October 16, an unauthorized actor gained access to a legacy system within OpenCode’s infrastructure. The company stated that this breach may have exposed third-party AI provider keys saved by users in OpenCode Console, its optional hosted workspace service.

What happened

OpenCode Console allows teams to store their own API keys for providers like OpenAI, Anthropic, or Google. The service uses these keys to call the respective models, enabling team members to use AI tools without directly handling the credentials. The breach specifically affects 1.4% of Console users who had linked an external provider. On the morning of October 17, OpenCode sent an email with the subject line "Action Required: Potential provider key breach" to these affected users, instructing them to revoke and replace their keys. Users who did not receive this email were not impacted.

The compromised keys are those pasted directly into the Console interface. Keys stored locally in the OpenCode command-line or desktop apps, which reside in a local SQLite database, were not part of this incident. Co-founder Dax Raad clarified on X that the breach involved "the OpenCode Console, not OpenCode itself," emphasizing that keys stored locally never reach their servers. However, for those using the hosted Console, the exposure is significant because provider keys act as bearer credentials. Anyone possessing a copy can execute billable requests against the owner’s account until the provider revokes the key.

Deleting a key from the Console interface does not revoke it at the provider level, nor does any budget limit set within Console prevent misuse. This is because Console only monitors requests passing through its own gateway. If an attacker holds the raw key, they can bypass Console entirely. OpenCode described the incident as ongoing and related to a "large-scale distillation attack," though it has not detailed how the two are connected or identified the specific legacy system involved. Attacks on OpenCode’s systems continued through October 18, prompting the company to harden its defenses.

How it works

API keys for major AI providers function as bearer tokens, meaning possession of the key grants full access to the associated account’s capabilities and billing. In the OpenCode Console model, users entrust the platform with these keys to facilitate seamless team access. When a legacy system was breached, the security boundary protecting these stored secrets was compromised. Unlike local storage, where keys remain on the user’s machine, hosted storage centralizes risk. If an attacker extracts these keys, they can use them independently of the OpenCode platform.

Distillation attacks involve extracting large volumes of model outputs to train competing models. These campaigns often rely on networks of fake accounts and stolen credentials. While OpenCode linked the breach to such activities, the immediate threat to users is financial and operational. Stolen keys can be resold on criminal markets or used to run up substantial bills. Because the keys are bearer credentials, revocation at the source is the only effective mitigation; simply removing them from the compromised service is insufficient.

Key details

• The breach occurred on October 16 and affects 1.4% of OpenCode Console users with linked external providers.
• Only keys stored in the hosted Console were at risk; local keys in CLI or desktop apps were not affected.
• Affected users received an email on October 17 instructing them to revoke and replace their API keys.
• Provider keys are bearer credentials, so deletion from Console does not stop unauthorized use if the key was copied.
• Some users reported unauthorized charges, including losses ranging from $168 to $1,700 across OpenAI, Anthropic, and Google accounts.
• OpenCode stated the incident is related to a large-scale distillation attack and that attempts to breach systems continued through October 18.

Why it matters

For engineering teams relying on hosted AI services, this incident highlights the risks of centralizing sensitive credentials. When a platform stores your API keys, you depend entirely on their security posture. A breach in a legacy system, even if isolated from core operations, can compromise user data. This underscores the importance of understanding where your secrets live and who has access to them. It also demonstrates that budget controls within a third-party tool offer no protection if the underlying credential is stolen.

The financial impact on individual users illustrates the tangible cost of such breaches. With reports of hundreds or thousands of dollars in unauthorized usage, the incentive for attackers to harvest AI keys is clear. These keys are valuable assets in the underground economy, used not just for distillation but for general resource theft. Teams must treat AI API keys with the same severity as database passwords or cloud access keys, recognizing that exposure leads to direct financial liability.

What you can do

• Revoke any API keys stored in OpenCode Console immediately via the provider’s dashboard (OpenAI, Anthropic, or Google).
• Generate new keys and update all applications and scripts that relied on the old credentials.
• Review billing and usage logs at the provider level for any unauthorized activity dating back to October 16.
• Implement spend limits and alerts directly with the AI provider to cap potential damage from future leaks.
• Assign unique API keys to each tool or service to isolate usage and simplify tracing in case of compromise.
• Consider moving away from hosted key storage if possible, using local environment variables or secure secret managers instead.