AI security

On October 17, OpenCode, the open source AI coding agent, said its hosted Console had been breached. The company put the impact at 1.4% of Console users, all of them in the subset that had linked an external model provider. For those users, third party provider keys saved in a Console workspace, such as OpenAI and Anthropic keys, may have been exposed. OpenCode says it is working with Anthropic, OpenAI and Google to remediate, and that the incident is ongoing.

If you only run the OpenCode CLI on your own machine with keys in your own environment, you did not hand those keys to the Console. If anyone on your team ever pasted a provider key into a Console workspace, treat that key as burned. OpenCode says affected users were emailed and that people who received no email were not affected, but rotating a key costs minutes, and a stolen one bills you until it is revoked.

How a hosted gateway holds your keys

The OpenCode CLI talks to model providers directly using whatever key is in your shell or config. The Console is a hosted layer on top: teams create workspaces, link providers by pasting in an API key, and OpenCode's servers then call the provider on their behalf. To do that, the service has to store each key in a form it can decrypt and use. Whoever gets into that storage, or into a system that can read it, gets working keys.

A provider API key is a bearer credential. Anyone who presents it is treated as you, billed to your account, at whatever rate limits your account has. It carries no binding to the machine or service that was meant to use it unless you added one (Google API keys, for example, can be restricted to specific IP addresses). That makes a pile of stored keys in a third party service an attractive target: each one converts straight into free model access.

OpenCode's emailed notice, which users have posted publicly, describes "unauthorized access to a legacy system" that was being decommissioned. Its post on X links the breach to a "large scale distillation attack". Distillation here means harvesting a model's outputs at volume, usually to train another model, and stolen keys are a way to do that on someone else's bill. That reading fits the coordination with all three providers, but OpenCode has not explained the link, how the attacker got in, or how many keys were taken.

What has been reported

The confirmed part is short. OpenCode has said:

• 1.4% of Console users were affected, from the subset with external providers linked.
• Provider keys saved in workspaces may have been exposed, with OpenAI and Anthropic given as examples.
• It is working with Anthropic, OpenAI and Google, and cannot share more while the incident is ongoing.

Losses are disputed. Notebookcheck relays a Reddit user's report of $400 in unauthorized charges on an Anthropic account, Digg carries the same $400 figure from a post on X, and others on X and Reddit described usage alerts and drained balances. Developers Digest and The420.in, by contrast, say no unauthorized charges had been confirmed and that OpenCode had not disclosed any confirmed financial loss. Both can be true: individual users see charges that nobody has yet verified. Treat the dollar figures as user reports.

Commenters, including one on Hacker News quoted by Developers Digest, read the affected product as the hosted Console and gateway, not the local CLI. That is an analyst reading; OpenCode's statements do not address the CLI directly.

What to do

Work in this order. Revoke first, because a key that is still valid keeps billing while you investigate.

1. Find every key you linked. In each OpenCode Console workspace, open the Providers tab and note which providers have a key attached. Workspace admins should check for members who linked their own.
2. Create a replacement and revoke the old key at the provider. On Anthropic, revoke the key on the API keys page of the Claude Console (platform.claude.com). Archiving a whole workspace there archives every key in it within seconds, which is a fast kill switch if you put the Console key in its own workspace. On Google, create a new key on the AI Studio API Keys page (aistudio.google.com/apikey), deploy it, then disable the old key in the Cloud console credentials page (console.cloud.google.com/apis/credentials). On OpenAI, revoke the key in the API keys section of the platform dashboard and issue a project-scoped replacement.
3. Update everything else that used that key. The same key is often in more places than the Console: a .env file, a CI secret, a teammate's shell profile.
4. Check usage for the exposure window. On each provider, filter usage by API key where the dashboard allows it, and look for models you never call, spikes in output tokens, requests at hours your team is offline, or batch jobs you did not start. Anthropic's Usage and Cost API can group by workspace for a scripted check. On Google, review billing reports and API usage per project.
5. Report disputed charges to the provider's billing support. Keep screenshots of the usage graphs and the OpenCode notice.

To find copies of the old key in code and pipelines, search by prefix. Anthropic keys start with sk-ant-, OpenAI project keys with sk-proj- and Google standard API keys with AIza:

grep -rnE 'sk-ant-|sk-proj-|AIza' --include='*.env*' --include='*.y*ml' --include='*.json' .
git log -p --all -G 'sk-ant-|sk-proj-|AIza' | grep -nE 'sk-ant-|sk-proj-|AIza'
gitleaks detect --source . --log-opts="--all"

Run it across every repository the key may have touched, and check CI secret stores and shell history (~/.bash_history, ~/.zsh_history) by hand. Developers Digest advises against posting a leaked key publicly to trigger automatic revocation; rotate it through the provider's dashboard instead.

Then cap the damage for next time. Anthropic lets you set a monthly spend limit per workspace (Workspaces page, select the workspace, Spend limits) and per-model rate limits; note that the Default Workspace cannot have a spend limit, so put third party keys in a named workspace. Google lets you restrict a key to the Gemini API only and, in the Cloud console, to specific IP addresses. OpenAI lets you keep keys inside a project with its own budget and usage view.

Key custody for AI tooling

Every AI coding tool, gateway and agent framework asks for the same thing: a provider key with your billing behind it. Each place that key is stored is another system whose breach becomes your bill. A few rules keep that manageable:

• One key per tool and per environment, never one shared key reused across the Console, CI and laptops. Rotation then breaks one thing, and usage logs tell you which tool leaked.
• Give a hosted service its own provider workspace or project with a low spend cap, so a stolen key has a ceiling.
• Prefer tools that keep keys local or that use the provider's own sign-in, which can be revoked per user. Anthropic's Claude Code workspace, for example, mints per-user keys that stop working when the member is removed.
• Write down where each key lives. Most of the work in an incident like this is finding the copies.

We review how AI tools and agents hold credentials as part of our AI native systems work, and watch provider usage for this kind of abuse in security operations. If you are not sure where your team's provider keys ended up, open the chat and Yaali, our AI agent, will pass the question to an engineer.

---

Sources: Developers Digest, Notebookcheck, OfficeChai, The420.in, Digg, Anthropic workspaces documentation, Google Gemini API key documentation.