OpenCode Console Data Breach: The Risk of a Middleman Holding Your API Keys

The OpenCode Console data breach reveals a neglected risk: when you hand your API keys to a hosted service, you are effectively handing control of your account to a middleman.

Incident Recap: 1.4% of Users Affected

On October 17, 2026, OpenCode disclosed that an intruder accessed a legacy system on the evening of October 16, and that provider API keys stored in OpenCode Console "may have been compromised." About 1.4% of Console users were affected, all of whom had linked external providers. OpenCode stated that users who did not receive an email were not affected.

Console is OpenCode's optional hosted service that lets workspaces store their own OpenAI, Anthropic, or Google keys and make provider calls through Console, so team members never have to touch the keys directly. This is the "bring your own key" (BYOK) model.

Co-founder Dax Raad emphasized that the breach involved Console, not OpenCode itself. According to the documentation, keys added via /connect in the terminal app are stored locally in ~/.local/share/opencode/auth.json.

BYOK (Bring Your Own Key) is a common key management model in cloud services and AI tools: instead of reselling model usage, the service provider lets customers enter their own provider (e.g., OpenAI, Anthropic, Google) API keys into the platform, which then makes requests on their behalf. For enterprises, the benefit of BYOK is that billing rolls up into existing provider contracts, negotiated pricing and quotas can be reused, and auditing is centralized; the cost is that keys must leave the local environment and be stored in some form in a third-party system. Once that storage layer is compromised, attackers obtain credentials that can directly consume the customer's quota rather than the platform's own credentials, so losses and accountability often span both the platform and the provider, and the forensics and containment chain is longer. This is precisely the structural reason the risk was amplified in this incident.

Why This Matters

A provider key is a bearer credential. Anyone holding a copy can run billable requests against the owner's account until the provider revokes the key. Some users have already posted reports of charges they did not make (one report claims $281 charged to an OpenAI key and $168 to an Anthropic key). These are users' own accounts; OpenCode has not confirmed that any key was copied or used.

On October 18, Raad wrote that attackers had been trying "nonstop" to get into OpenCode's systems for 48 hours.

Bearer credential refers to a token or key that authenticates solely by being presented, with no additional user interaction or second factor. An API key is a typical bearer credential: put it in the request header and the provider assumes the caller is the account owner. This has three security implications. First, leakage equals identity impersonation—there is no "second door beyond the password." Second, keys are typically long-lived and can be used continuously unless actively rotated or revoked. Third, usage shows up in billing and rate limits rather than login logs, so anomalies often go unnoticed until costs spike. This is why the industry advocates assigning a separate key to each tool, setting spending limits and alerts, and shortening key lifetimes—the goal is to keep the blast radius of a single leak within controllable bounds.

Key Issues Overlooked in Coverage

"Distillation Attack" Is a Motive, Not a Conclusion

OpenCode says the incident is related to a "large-scale distillation attack." Distillation means extracting model answers in bulk to train another model. But stolen keys could also be resold or used to run up bills. The information disclosed so far does not show which scenario applies, and no provider has characterized it.

1.4% Lacks a Denominator

Without a total user count, no one can convert the percentage into a specific number of people or keys. This ambiguity makes risk assessment difficult.

Deleting a Key in Console Is Not Revocation

According to The Hacker News, removing a key from Console does not revoke it, and Console budgets cannot limit usage outside Console's own gateway. Only the provider can fully disable a key.

This is a critical security blind spot: users may believe deletion has made them safe, but the key remains valid.

Key revocation vs. deletion are often confused semantically, but their security consequences are entirely different. Deletion usually only removes the platform-side storage record or reference, while the key itself remains "active" at the provider; revocation marks the key as invalid in the provider's control plane, after which any request carrying it will be rejected. The difference stems from who issued the key: only the issuer can invalidate it. In practice, the correct order is to first revoke (or rotate) the key in the provider console, then clean up residual records on the intermediary platform, and finally check usage and billing from before the revocation. If the order is reversed, the intermediary platform often loses the key's identifying information after deletion, making it harder to locate and revoke.

A Practical Recommendation

Assign a separate key to each tool, set spending limits or alerts at the provider, and know exactly where to revoke keys. If you have ever stored a key in Console, revoke it at the provider regardless of whether you received an email, and review usage since October 16.

Industry Impact: The Trust Challenge of the BYOK Model

This incident may prompt more teams to make "who holds our provider keys" a vendor review question, just as they treat cloud credentials. Gateways that hold BYOK keys can expect to be asked for details on storage and rotation.

For teams that rely on third-party key hosting, this incident is a warning: there is a trade-off between convenience and security. When choosing a hosted service, it is essential to understand how keys are stored, what access controls exist, and what the incident response process is.

The OpenCode incident also reminds us that in today's increasingly complex AI toolchains, key management has become a security element that cannot be ignored. Whether you are an individual developer or an enterprise team, you should establish strict key management practices to avoid unnecessary losses caused by gaps in the middleman chain.

One-line Summary

Provider API keys for about 1.4% of OpenCode Console users were reportedly leaked, exposing BYOK hosting risks.

Paragraph Summary

On October 17, 2026, OpenCode disclosed that an intruder accessed a legacy system on the evening of October 16, potentially leaking provider API keys stored in OpenCode Console. About 1.4% of Console users were affected, all of whom had linked external providers. Co-founder Dax Raad emphasized that the breach occurred in Console, not OpenCode itself, and that keys added via the terminal /connect command are stored locally. The article notes that provider keys are bearer credentials and can be used for billable calls once leaked; users have reported unauthorized OpenAI and Anthropic charges, but OpenCode has not confirmed that keys were copied or used. Overlooked issues in coverage include: the so-called "large-scale distillation attack" is only a possible motive, not a conclusion; the 1.4% figure lacks a total user count as a denominator; and deleting a key in Console is not the same as revoking it at the provider. The article recommends assigning a separate key to each tool, setting spending limits, and revoking keys at the provider and reviewing usage.