On 17 October 2026, OpenCode emailed some users of OpenCode Console, its hosted model gateway, with the subject "Action Required: Potential provider key breach." The email said the team had "identified unauthorized access to a legacy system that we were in the process of decommissioning," and that "third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed." Later that day OpenCode posted on X that the breach was "related to a large scale distillation attack" and affected 1.4% of Console users.
What's affected
OpenCode has shared only a few facts so far. Here is what its email and X post actually say:
- Who: about 1.4% of OpenCode Console users, described as "a subset of users who had external providers linked." OpenCode says it emailed all of them on the morning of 17 October and that "if you did not get an email you were not impacted."
- What: third party provider keys saved in a Console workspace. The email names OpenAI and Anthropic as examples. The X post says OpenCode is "working with Anthropic, OpenAI, and Google to remediate," so treat Google (Gemini) keys as in scope too.
- When: the X post, sent at 18:08 UTC on 17 October, says the breach happened "last night."
- Status: "The incident is ongoing so we cannot share more details at this point." OpenCode has not said how the attacker got in or how long they had access.
A few hours later, OpenCode's Dax Raad posted that his "personal accounts are being attacked now too."
Console workspaces let owners and admins connect their own model providers, which is where these keys lived. OpenCode's statements tie the exposure to keys saved in Console workspaces. They don't mention keys kept only in a local environment variable or local config.
Context, not cause: OpenCode's local tool has had serious bugs before. CVE-2026-22812 (CVSS 8.8) covered an unauthenticated HTTP server that let any local process, or any website through permissive CORS, run shell commands; NVD lists the fix in 1.0.216. CVE-2026-22813 covered a markdown renderer that put raw HTML from LLM responses into the page, giving script execution on the localhost:4096 origin; fixed in 1.1.10. Neither has been linked to this breach.
How to check if you're exposed
- Search your inbox for the subject line "Action Required: Potential provider key breach." No email means OpenCode does not consider you affected.
- List every provider key that was ever saved in a Console workspace, including keys added by other admins.
- Pull usage for each provider from 16 October onward. OpenCode hasn't said when access began, so look further back if you can.
You can also confirm whether an old key still works. After you revoke it, each of these should return an authentication error:
# OpenAI
curl -s -o /dev/null -w '%{http_code}\n' https://api.openai.com/v1/models \
-H "Authorization: Bearer $OLD_OPENAI_KEY"
# Anthropic
curl -s -o /dev/null -w '%{http_code}\n' https://api.anthropic.com/v1/models \
-H "x-api-key: $OLD_ANTHROPIC_KEY" -H "anthropic-version: 2023-06-01"
# Google Gemini API
curl -s -o /dev/null -w '%{http_code}\n' \
"https://generativelanguage.googleapis.com/v1beta/models?key=$OLD_GEMINI_KEY"
A 200 means the key is still live.
What to do now
-
Create the replacement first, then revoke. Google's own guidance for a compromised Gemini key is to create a new key, deploy it, then disable the old one. The same order avoids an outage with every provider.
-
OpenAI: in the platform dashboard, open the API keys page, delete the exposed key and create a new one inside a specific project rather than a broad legacy user key. Check the Usage page for spikes by day and by model. Then review the project's limits and set the lowest budget your workload can live with.
-
Anthropic: in the Claude Console, open the workspace's API Keys tab, use the menu next to the key to disable or delete it, and issue a new one. Review the Usage and Cost reports by workspace. On the Limits tab, use "Change Limit" to cap workspace spend and "Add notification" to get an email at a spend amount you choose.
-
Google: manage the key in Google AI Studio or in the Google Cloud console for the linked project. From the command line:
gcloud services api-keys list --project=YOUR_PROJECT gcloud services api-keys delete KEY_ID --project=YOUR_PROJECTRestrict the new key to the Gemini API only, then set a budget alert in Cloud Billing for that project.
-
Update every consumer. CI secrets,
.envfiles, local agent configs and teammates' machines often hold copies of the same key. Rotate once, update everywhere, then re-run the curl checks above. -
Re-add keys to Console only if you need to. If you keep using Console with your own providers, give it a dedicated key with a low spend limit, not the key your production app uses.
Why it matters
"Distillation" usually means harvesting a strong model's outputs to train a cheaper one. That takes a lot of paid API calls, and stolen keys let someone else pay for them. OpenCode hasn't described the attack beyond that phrase, but the incentive is clear: an AI provider key is spendable money and model access in one string.
Bring-your-own-key tools gather many of these strings in one place. A developer who links OpenAI, Anthropic and Google keys to a hosted workspace has made that workspace's weakest system, here a legacy one being retired, the gate to all three accounts.
The fix is boring and works. Issue one key per tool, scope it to a project, cap its spend, and keep a list of where each key lives so rotation takes minutes instead of a day of searching.
Try it yourself
Find out where provider keys have spread in your own code before the next vendor emails you. Run a secrets scan across a repo you own and count how many places an sk- or AIza string appears, including old commits.
Click through it at your own pace, or open it full screen.
Quick check
I use OpenCode only as a local CLI with keys in environment variables. Do I need to rotate?
OpenCode's statements describe keys saved in Console workspaces and say users who got no email were not impacted. If you never saved keys in Console and got no email, you are outside what OpenCode has described. Rotating anyway is cheap.
Should I delete the old key before creating a new one?
No. Create and deploy the replacement, confirm it works, then revoke the old key. Deleting first causes an outage.
Does a spend alert stop an attacker from using a stolen key?
Not by itself. An email notification tells you spend has crossed a line; it does not revoke anything. Pair it with a spend cap where the provider offers one, such as an Anthropic workspace limit, and revoke the key as soon as the alert fires.
