The OpenCode breach.
Your keys. Someone else’s bill.

01 / A weekend, reconstructed

These times describe disclosures and reported events, not a complete forensic timeline. All times below are UTC.

The initial “ongoing” description should not be treated as a live status indicator on October 19. The reviewed disclosures also do not amount to a final technical postmortem.

02 / The product becomes a wallet of keys

OpenCode’s current Console documentation describes a service that stores provider credentials and routes model requests through a gateway. Workspace members can use the configured provider without seeing its underlying key. That is useful delegation: access becomes easier to manage across a team.

It also creates a trust boundary. A provider credential is more than a preference setting. Depending on its permissions, possession can authorize requests against the issuer’s account. A service holding credentials therefore needs protection appropriate to the capabilities those credentials confer.

Cyera’s incident analysis, citing the customer notification, described a legacy Console system being retired and warned that linked provider API keys may have been exposed. This is an account of the notice, not independently published proof of the entry mechanism. Current product documentation explains the general delegation model; it cannot establish exactly how the affected legacy system stored or protected keys.

Why closing the app may not stop the bill

The risk model is straightforward: if a usable key is copied, a request can potentially go directly to the provider without passing through the tool that originally held it. Closing the coding application or disabling a model in its interface does not necessarily invalidate that credential at its issuer.

Console’s documented budgets control requests handled by Console. Our architectural inference is that such a gateway limit cannot govern requests that bypass the gateway. Provider-side enforcement is a separate control. A spending alert, an application budget, and a revoked credential are three different things.

That distinction is the heart of this disaster pattern. The visible application can appear quiet while a credential remains usable somewhere else.

03 / “Distillation attack” describes a purpose, not an entry point

Distillation uses outputs from one model to help train another. It has legitimate uses. In the security context, Anthropic describes distillation attacks as unauthorized campaigns to extract a model’s capabilities and reproduce them in another system.

OpenCode linked this breach to such an operation. That suggests an alleged objective for consuming model access; it does not explain how the attacker entered Console or acquired credentials. Those are separate questions.

Nor does the description establish who ran the operation, whether a resulting model was successfully trained, or how much activity was attributable to it. A complete account would connect the access event to observed request patterns and explain the basis for the attribution. Until that evidence is public, “distillation attack” remains OpenCode’s characterization of the incident.

Raad’s statement about relentless attacks is important operational context, but a social post is not a substitute for access logs or a technical reconstruction. There is no basis in the reviewed record to turn this into a claim that a particular company’s autonomous agents carried out the breach.

04 / A small percentage can still mean a serious incident

The denominator in OpenCode’s statement is Console users. It is not all developers using OpenCode, all provider accounts, or all AI coding-tool users. No absolute affected-user count is established here.

BleepingComputer reported user complaints about unauthorized charges and a suspended Google Cloud project. These reports indicate potential financial and operational harm, but they do not establish a verified aggregate loss. Individual examples should not become an invented average.

One affected user, Alex Spînu, publicly reported a project suspension, then said the issue had been resolved and praised the communication from OpenCode and Google Cloud. Both parts belong in the account: disruption occurred according to the user, and the user subsequently reported a successful response.

A compromised key can also create uncertainty beyond its immediate bill. The permissions attached to it determine what else needs investigation. The evidence reviewed here does not establish a general theft of source repositories or every user’s prompts, and it would be wrong to imply one.

OpenCode’s statement that unnotified users were unaffected is useful guidance from the service operator. It is not an independent audit of every account. Affected users should follow the notice; anyone seeing unexplained provider activity should investigate that activity regardless of whether an email arrived.

05 / If you had a provider linked

This is a containment checklist for potentially exposed credentials, not a finding that every reader’s account is compromised.

1. Read the actual notification. Identify the affected workspace, provider, and credentials. Open the service and provider dashboards directly; do not paste keys into a reply, public issue, or supposed verification form.
2. Revoke exposed keys at the issuer. Creating a replacement does not by itself invalidate the old key. Inventory legitimate consumers, replace their credentials, and verify that the old credential is disabled. Do not delay containment of active misuse merely to preserve uninterrupted service.
3. Review provider activity and billing. Check the reported exposure period and surrounding activity. Preserve timestamps, usage exports, and relevant billing records before they become harder to retrieve. Record the time each key was revoked.
4. Check what the key could access. Review permissions, projects, and any relevant logs. Where supported, give replacement keys narrower access and separate keys by service so future revocation has a smaller impact.
5. Verify spending controls. Determine which controls actually block requests and which only send alerts. Confirm whether enforcement belongs to the provider or an intermediary.
6. Ask the provider to review suspicious charges. Supply account identifiers and evidence through official support channels. A reported resolution for one user is not a blanket reimbursement promise.

Cyera’s rotation guidance likewise emphasizes replacing exposed credentials and reviewing provider usage. Google’s API-key documentation explains restrictions and key handling for its platform. Follow each issuer’s instructions for the particular credential involved.

06 / What the postmortem needs to answer

The strongest next disclosure would go beyond a percentage and a description of the attacker’s presumed goal:

• What was the initial access path, and when did unauthorized access begin?
• Which credentials and permissions were exposed, and how were they stored?
• What did retiring the legacy system mean for retained credentials and access?
• When were affected keys invalidated, and which actions required the customer?
• What usage was confirmed unauthorized, and how will billing disputes be handled?
• What evidence connects the intrusion to distillation activity?

A system being retired can still hold production authority. That is a general engineering lesson, not proof that retirement caused this breach. Decommissioning should end with verified deletion or revocation of retained authority, not merely a quieter interface.