OpenCode Breach: API Keys Exposed for 1.4% of Console Users

What OpenCode disclosed

OpenCode is an open-source coding agent built by Anomaly, the team formerly known as SST. The company says 16 million developers use the agent each month, and its GitHub repository has about 215,000 stars — more than OpenAI's Codex CLI or Google's Gemini CLI. OpenCode runs in a terminal, code editor, or desktop app and connects to models from more than 75 providers, with users supplying their own private API keys to give the agent access. Console, OpenCode's hosted product, stores those keys on OpenCode's own servers so the service can call providers on a user's behalf.

That storage is what got exposed. In an email to affected users, OpenCode said someone had gained "unauthorized access to a legacy system that we were in the process of decommissioning." Third-party provider keys stored in users' workspaces, including those for OpenAI and Anthropic, may have been exposed. OpenCode has tied the intrusion to what it describes as a large-scale distillation attack, which involves collecting an AI model's responses to train another model — in effect, using stolen access to a frontier model as a cheap way to harvest training data for a competing one.

On scope, the company has been specific about exactly one number. OpenCode disclosed a security breach affecting 1.4% of its Console users, and it emailed all of them, saying anyone who did not receive an email was not affected, and that the affected group was users who had external providers linked. Beyond that, detail is thin: OpenCode's public statement does not explain how attackers gained access, how long they remained inside, or how many keys were involved, and it does not name an attacker or provide technical evidence showing how the breach supported the reported distillation activity.

The timeline, as far as it's public

The "we meant to get to it" failure mode

OpenCode's own explanation is the most honest part of the disclosure, and also the most familiar. The entry point wasn't a novel attack technique — it was a system the company already knew was a liability. It was mid-decommission: scheduled for retirement, presumably deprioritized against other work, still reachable, and still holding keys.

This is one of the most common patterns in breach postmortems. The vulnerable component isn't a surprise; it's a known item that didn't get retired before an attacker found it. Decommissioning takes time, and in that window, old systems often fall out of active monitoring even though they still carry live credentials. The lesson isn't "patch faster." It's that any system holding raw provider keys is a standing liability for as long as it exists — including during its own shutdown.

Why this is structurally the same mistake as a .env file

It's tempting to treat this as an access-control failure specific to OpenCode and move on. But the deeper issue is architectural, and it applies well beyond this one incident: Console stored real, usable OpenAI, Anthropic, and Google API keys so a hosted agent could call those providers for a user. Functionally, that's indistinguishable from a developer pasting the same keys into a .env file on a server. In both cases:

• The raw credential exists in a retrievable form, in a system that is one access-control mistake away from exposure.
• Any process, script, or legacy endpoint with read access to that storage can exfiltrate a key that works everywhere, with no built-in limit on spend, scope, or duration.
• Revocation is manual and reactive — it happens only after someone notices the damage, whether that's a developer spotting a leaked .env in a public repo or a Console user watching an unexpected AI bill.

Swapping "config file" for "coding-agent console" doesn't change the trust model. A key sitting in workspace storage so an agent can use it later is the same shape of risk as a key sitting in plaintext on disk. The interface is nicer; the blast radius is identical.

What a gateway model changes

The alternative isn't "store the key more carefully." It's not handing the raw key to the agent, the console, or the process in the first place. In a gateway architecture, the application or agent authenticates to the gateway, and the gateway injects the actual OpenAI, Anthropic, or Google credential at the network egress point, per request. The agent never holds the live key, so it can't leak what it never had. If the gateway's own storage is compromised, the operator rotates one upstream secret centrally instead of asking thousands of end users to revoke credentials across three separate provider dashboards.

That architecture would not have stopped someone from reaching OpenCode's legacy system, and it wouldn't have prevented a breach from existing. What it changes is the payload: an attacker reaching that system finds short-lived, scoped routing tokens instead of live OpenAI, Anthropic, and Google keys that work immediately, from anywhere, for as long as a distillation campaign needs them to run. This is the premise behind KnoxCall's AI gateway design — the credential lives at the egress wire, not inside the agent, the CI runner, or the console workspace calling it.

What to do if you used OpenCode Console

If you linked OpenAI, Anthropic, or Google credentials in OpenCode Console, treat every one of those keys as compromised, whether or not you received a notification email, since OpenCode has acknowledged it doesn't yet know the full extent of the access. Concretely:

1. Revoke and reissue the keys directly in each provider's dashboard, not just inside OpenCode. The company's own notice asks recipients to revoke and replace those keys through each provider's dashboard, update applications that use them, and review recent usage for unexpected activity.
2. Set hard spend caps on provider accounts going forward; a distillation attack is defined by volume, and a cap limits the financial damage of the next leak, wherever it originates.
3. If you're building anything that needs to hold or route provider keys on behalf of other users — a coding agent, an internal tool, a SaaS integration — treat this incident as the reference case for why that credential shouldn't live in your own storage at all.

For teams rethinking how secrets sprawl across dev tools, CI, and agents, our security overview and gateway comparison cover what egress-time credential injection looks like in practice, and pricing covers what it costs to stop handing out raw keys at all.

What's still unknown

OpenCode identified a large-scale distillation attack but has not disclosed full technical details, and the company has said the incident remains ongoing so it cannot share more at this point. Whether the attacker was specifically hunting for distillation fodder, or simply found a trove of valuable keys and distillation was the most profitable use of them, isn't established. Neither the duration of the attacker's access nor the total number of exposed keys has been made public. If that changes, it will matter — but as of this writing, the 1.4% figure and the legacy-system explanation are the two facts OpenCode has put its name to.