OpenCode disclosed a security breach on October 17 that affected 1.4% of users of its hosted Console service, specifically a subset of customers who had connected external AI providers. The company notified affected users by email and said it was working with Anthropic, OpenAI and Google while the incident remained under investigation.
The customer notice warned that provider credentials saved in affected workspaces may have been exposed. For anyone who received that notice, removing a provider from OpenCode is not enough: the old key must be revoked at the company that issued it. Until that happens, a copied credential may continue to authorize requests and generate charges outside OpenCode.
OpenCode has not published a technical postmortem, the number of affected accounts, the number of exposed keys or a total for unauthorized usage. It also has not explained whether the “large scale distillation attack” was the intrusion method, the activity carried out with stolen credentials, or a broader description of the incident. Those gaps make immediate credential containment more important than waiting for a complete explanation.
Who needs to act now
The disclosure is about OpenCode Console, the hosted workspace service. OpenCode’s own documentation says Console stores credentials for connected providers and injects them when it forwards requests through its gateway. Workspace members can use enabled models without seeing the underlying provider key.
That is different from a standard local OpenCode setup. The project’s CLI documentation says locally added credentials are stored on the user’s machine, historically in ~/.local/share/opencode/auth.json and, in newer versions, in OpenCode’s local SQLite database. The current disclosure does not establish that every local OpenCode installation or every locally stored credential was compromised.
You should treat a provider key as exposed if any of the following applies:
- You received OpenCode’s affected-user email.
- Your organization connected OpenAI, Anthropic, Google or another external provider to an OpenCode Console workspace that may be in scope.
- You cannot reliably determine whether a key was stored in Console.
- Provider logs show unfamiliar models, request times, token volumes, source locations or spending.
If you only used the local CLI and never placed a provider credential in a hosted Console workspace, the public disclosure does not currently identify your local key as affected. Even so, verify how each credential was supplied rather than relying on memory: teams often reuse the same secret in a shell environment, CI system, coding tool and shared workspace.
Revoke the old provider key first
For a confirmed or strongly suspected exposure, revoke the old credential at the provider. Disabling an OpenCode connection or changing an OpenCode workspace setting does not invalidate a key already copied elsewhere.
OpenAI
OpenAI advises customers who believe a key leaked to rotate it immediately from the API Keys page and review the Usage page for activity that does not match normal work. Organization owners can also inspect project keys and delete them through the administrative API. After creating a replacement, update every application, CI secret and developer environment that used the old value.
Do not rely on a budget alert as containment. OpenAI’s current guidance distinguishes alerts from enforced spend limits: an alert sends a notification, while hard enforcement can stop traffic after tracked spend reaches the configured limit. Separate keys by project or workload so an incident in one tool does not force a company-wide rotation.
Anthropic
Anthropic recommends immediately revoking a suspected compromised key in Claude Console by opening the API keys page, selecting the menu beside the key and choosing Delete API Key. Review both usage and logs, with attention to sudden token spikes, unfamiliar models and requests outside normal working periods.
Create a dedicated replacement rather than reusing a broad production key. Anthropic recommends separate keys for development, testing and production because that makes anomalous usage easier to attribute and limits the systems affected by a future leak.
Google Gemini
Google’s Gemini API guidance calls for generating a replacement key, updating the application, verifying the new credential and then disabling or deleting the compromised key. In an active incident where a key may already be in an attacker’s hands, minimize the overlap period and prioritize containment over uninterrupted low-priority workloads.
Use Google Cloud billing and API usage logs to look for unexpected requests. The replacement should be restricted to the Gemini API and, where the deployment permits it, to expected IP addresses or application origins. An unrestricted key can expose more services than the coding workflow actually needs.
Replace every copy, not just the one in OpenCode
Credential rotation fails when the old secret survives in a second system. Build an inventory before restoring normal traffic. Check:
- OpenCode Console provider connections and service accounts.
- CI/CD secret stores in GitHub, GitLab, Jenkins or cloud build systems.
- Production secret managers, server environment variables and container-platform secrets.
- Local
.envfiles, shell profiles and OpenCode credential storage. - Other AI gateways, editors, notebooks, automation tools and internal proxies.
OpenCode’s Console documentation says owners and admins can rotate a connected provider credential from the provider page by entering a new value. Do that only after the old key has been invalidated or tightly controlled at its issuer. Then test one low-risk request and confirm that the revoked credential now returns an authentication error.
Also rotate OpenCode Console service-account keys if there is any possibility they were exposed. OpenCode documents those keys as oc_sk_... credentials that can authorize inference and, depending on permissions, Console API access. They are separate from the OpenAI, Anthropic or Google key behind the gateway.
Audit usage before closing the incident
A successful rotation stops new requests but does not reveal what already happened. Export provider usage and billing data before short-retention logs disappear. Compare request timestamps, model names, token counts, projects, regions and user agents with known workloads. Preserve OpenCode’s notification, relevant workspace settings and provider logs for any billing dispute or internal investigation.
Do not convert the 1.4% figure into a victim count. OpenCode has not published its Console user total, and one workspace can hold multiple provider credentials. Similarly, reports of individual unauthorized charges should not be presented as a platform-wide loss estimate.
The phrase “distillation attack” also needs care. Model distillation commonly involves issuing many queries to learn from another model’s outputs. OpenCode’s brief statement links the breach to that activity but does not yet show how an attacker reached the legacy system described in the customer notice. A postmortem would need to explain the entry point, credential-storage protections, access logs, exposure window and whether provider keys were decrypted, exported or merely used through the gateway.
What OpenCode still needs to disclose
A complete incident report should identify the affected Console component, the earliest unauthorized access, the class of credentials exposed, how affected users were selected, what OpenCode revoked itself and what customers still must revoke. It should also clarify whether provider logs can distinguish attacker traffic from ordinary Console gateway requests.
Until then, affected users should assume a saved external-provider key may remain usable wherever its issuer accepts it. Revoke it at the source, replace every dependent copy, review usage and preserve evidence. That sequence contains the risk without depending on an explanation that has not yet arrived.
