OpenCode's Breach Shows What a Stored Provider Key Costs

TL;DR

• OpenCode is an open-source AI coding agent that developers run from a terminal, with a hosted Console that manages accounts, workspaces and the provider keys some users link to it.
• On 17 October 2026 the company emailed affected Console users under the subject "Action Required: Potential provider key breach", saying an attacker had reached a legacy system it was decommissioning and that third-party keys saved in a workspace, including OpenAI and Anthropic keys, may have been exposed.
• OpenCode put the impact at 1.4 percent of Console users, described the incident as a large-scale distillation attack, and asked affected users to revoke and replace the keys at the provider, update the applications that used them, and check recent usage.
• OpenCode has not said whether the exposed keys were stored in the legacy system itself. Our reading is a general risk: a system kept running while it is retired can keep its access to stored credentials, and here one compromise put keys tied to customers' own provider accounts at risk.
• The bill for a stolen key arrives on the customer's account, because the key carries the customer's provider identity, quota and payment method. The only stop that works after the fact is revocation at the provider.
• On 19 October, two days after the notice, OpenCode's status page showed its Console API component, which covers dashboard, workspaces and keys, as operational; a reader looking there for a security signal would have found only an ongoing slow-response incident.
• Four controls survive a vendor breach: one key per tool, a spend limit at the narrowest scope the provider offers, log retention long enough to reconstruct usage, and a revocation runbook that does not wait for the vendor's confirmation.

What the notice said, and what it left open

The email that went out on 17 October had a subject line that leaves no room for interpretation: "Action Required: Potential provider key breach". The body explained where the access came from, in a sentence that has since been quoted widely: "We identified unauthorized access to a legacy system that we were in the process of decommissioning."

The next line is the one that matters to anyone who has used the product. "Third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed."

Those two sentences answer different questions. The first describes a perimeter failure in a system on its way out. The second names the data at risk: credentials customers had saved in a workspace, issued by other companies. The notice does not say whether those credentials were stored in the legacy system itself.

By 18:08 UTC the company had confirmed the incident publicly, describing it as "a large scale distillation attack" and putting the impact at 1.4 percent of OpenCode Console users. The affected group, per OpenCode, is a subset of users who had linked external providers. The company says it emailed everyone affected and that a user who received no email was not affected, and that it is working with Anthropic, OpenAI and Google on remediation. The distillation label is OpenCode's own choice; the write-up's author offers a reading of it and calls that reading a hypothesis until OpenCode publishes a follow-up.

What a system being retired can still hold

The open questions are worth writing down because they decide how much this incident tells us. OpenCode has not said how many accounts 1.4 percent represents, how the attacker entered the legacy system, how long the access lasted, or whether every key stored there was taken. One outlet quoted in the write-up makes the point directly: the figure measures neither exposure nor loss.

The notice establishes that the legacy system was still reachable while it was being decommissioned. It does not say which data that system held, or how it connected to the workspaces where keys were saved.

This is the part of the incident that generalises. In our reading (OpenCode has not described its own retirement plan), a system can be retired in stages: traffic moves first, then the database, then the credentials, and the credentials can stay in place after the traffic has gone. A system in that middle state is at its most dangerous, since it has lost the attention that a production system gets while keeping the access that made it worth a target.

The remedy OpenCode published is the only one available at that point. Users were asked to "revoke and replace those keys through the relevant provider's dashboard, update any applications using them, and review recent usage for unexpected activity."

Read that instruction as a description of where the control actually lived. The customer's credential could only be invalidated at the provider, by the customer. Every hour between the breach and the customer reading the email is an hour in which the credential worked.

Why the bill lands on your account

A provider key saved in a vendor's workspace still belongs to the customer's provider account. It carries the customer's identity at OpenAI, Anthropic or Google, which includes the quota attached to it, the payment method behind it and whatever guardrails the account has configured.

That is why the aftermath of this class of breach tends to show up as an invoice. The write-up notes user reports of bills in the hundreds of dollars, and it labels them as user reports with no figure from OpenCode behind them, which is the right way to read them today. The mechanism is simple: an attacker holding a valid key is, to the provider's billing system, the customer. In our reading, nothing in the request distinguishes a distillation run from a legitimate batch job.

The distinction between the two custody models is worth pricing before an incident. As a general pattern, and without any claim about how OpenCode bills its own traffic: when a vendor resells model traffic, the provider key in its systems is its own, and a leaked key draws on the vendor's provider account. When you link your own key, you keep the direct provider relationship, and you take on the identity risk. Both arrangements are legitimate; only one of them makes your provider account the blast radius of someone else's perimeter.

What the console status page showed on 19 October

OpenCode publishes a status page, and on 19 October its component list showed the Console API, described as covering the dashboard, workspaces and keys, as operational. The open item on the page was different: a slow-response incident that began at 16:44 UTC and was still marked ongoing 6 hours 48 minutes later, when the page was captured, with a note that pay-as-you-go traffic on one model was seeing slower responses.

That capture shows no security incident. A status page is built to track availability, and OpenCode disclosed this incident by email and on social media. It is also a reminder about the signal. Teams that monitor a vendor's status page for evidence of a security event are monitoring a page that was never built to carry one.

What did carry the signal, in this case, was a researcher posting a screenshot at 15:30 UTC, and the company confirming at 18:08 UTC. The screenshot showed the customer email itself, so the notice was already in affected users' inboxes when the first public post appeared.

Four controls that survive a vendor breach

Every control here assumes the vendor will be breached at some point, and asks what the customer still holds when that happens.

1. One key per tool, issued from a named account. A shared key copied into three tools makes revocation a coordination project; a key per tool makes it a quick action with a known blast radius.
2. A spend limit at the narrowest scope the provider offers, per key where it allows one. The limit converts an unlimited exposure into a capped one, and it caps the loss until revocation lands.
3. Usage logs kept longer than the incident. Reconstructing what a stolen key did requires provider-side usage history that reaches back to the first unauthorised request, so check the provider's retention period before you need it.
4. A revocation runbook that runs before confirmation. Each hour spent waiting for a vendor statement is an hour in which the key still works at the provider.

There is a contract question underneath all four, and it costs nothing to ask a supplier: which credentials do you store on our behalf, where do they live, how long do they stay after we stop using the feature, and what is your deletion evidence. A vendor that answers with a retention policy and a deletion record has thought about the decommissioning window. One that answers with a security page has not. We run that review as part of our security work.

Sources

Source: OpenCode Told 1.4% of Console Users to Revoke Their OpenAI and Anthropic Keys — DEV Community, by Gabriel Anhaia, published 17 October 2026, retrieved 2026-10-19 (the email subject line and the decommissioning sentence, the sentence about third-party provider keys saved in a workspace naming OpenAI and Anthropic, the researcher's 15:30 UTC post, the 18:08 UTC confirmation describing a large scale distillation attack, the 1.4 percent figure and the subset of users with external providers linked, the statement that users without an email were not affected, the work with Anthropic, OpenAI and Google, the note that the incident is ongoing, the instruction to revoke and replace keys at the provider and review recent usage, the unknowns about account count, entry point, duration and completeness, the observation that the percentage measures neither exposure nor loss, the co-founder's 18:41 UTC post, and the user reports of bills in the hundreds of dollars).

Source: OpenCode product site — opencode.ai, captured 2026-10-19 (the product presented as the open source AI coding agent, its terminal interface, and the Console for accounts, workspaces and keys).

Source: OpenCode status page — status.opencode.ai, captured 2026-10-19 (the Console API component covering dashboard, workspaces and keys marked operational, and the slow-response incident that started at 16:44 UTC and was still marked ongoing 6 hours 48 minutes later, with pay-as-you-go traffic on one model affected).

Source: OpenCode's customer notice and public confirmation of 17 October 2026 as reported by a dev.to write-up published the same day, plus OpenCode's own product and status pages captured on 19 October 2026 — the quotations, the 1.4 percent figure, the remediation instruction and the status-page state above trace to those pages. Charges reported by users are identified as user reports. Images are two captures of OpenCode's own properties and two Netics editorial diagrams. More analysis is published on neticslabs.com.