On the morning of October 17, a subset of OpenCode Console users opened an email with the subject line "Action Required: Potential provider key breach."
The key sentence inside: "Third party provider keys (for example OpenAI, Anthropic) saved in your workspace may have been exposed."
Hours later, OpenCode confirmed on X that it had "a security breach last night related to a large scale distillation attack" that impacted 1.4% of OpenCode Console users. Security researcher Matt Johansen had already posted the now-viral summary: "Confirmed. OpenCode hacked. Keys stolen. Telling customers to revoke."
If you use any AI coding tool that asks you to paste in your own API keys, and most of them do, this breach is about you even if you never touched OpenCode. Not because of the specific vulnerability, which is still under investigation, but because of what the design itself makes inevitable: every "bring your own key" agent is a credential vault, and you have probably never audited what is inside yours.
What actually happened
Here is the timeline, assembled from OpenCode's public statements, the customer email shared in the Hacker News thread, and reporting from security researchers.
- October 16 to 17, overnight. An unauthorized party accessed a legacy OpenCode Console system that was, according to the customer email, "in the process of decommissioning." That system contained API keys users had saved in their Console workspaces to connect the coding agent to external providers like OpenAI, Anthropic, and Google.
- Morning of October 17. OpenCode emailed affected users, urging them to revoke and replace their provider keys, update any applications using them, and review recent usage for unexpected activity.
- Around 15:18 UTC. Matt Johansen posted that OpenCode customers were receiving breach notices and that people were DMing him about API keys "running up charges."
- 18:08 UTC. OpenCode publicly confirmed the breach on X, calling it a "large scale distillation attack" affecting 1.4% of Console users, and said it was working with Anthropic, OpenAI, and Google on remediation.
- Still unknown. How the attacker got in, how long access lasted, how many keys were actually taken, and whether every exposed key was misused. OpenCode has declined further technical details because the incident is ongoing.
The scope was narrow, and OpenCode has been clear about that: only Console users who had linked external providers were in the affected group, and anyone who did not receive the email was not impacted. Anthropic, according to a post shared in the coverage, proactively revoked some Claude API keys it believed were affected.
But narrow scope does not change the shape of the problem. The affected population was precisely the group that followed the intended workflow: link your provider key in the dashboard so the agent can bill your own account. The convenience feature was the attack surface.
Distillation changes what a stolen key is worth
The strangest word in OpenCode's statement is "distillation," and it matters more than the dollar amounts.
Distillation, as Anthropic defines it in its own writing, is training a less capable model on the outputs of a stronger one. It is one of the main ways smaller labs catch up to frontier models. The catch is that you need massive volumes of frontier model output, and generating that output normally costs enormous amounts of money.
Now look at the breach through that lens. A stolen provider key is not just a wallet to drain. It is free access to frontier model output at someone else's expense. The reports from affected users fit this pattern: charges run up dramatically in a short window, with one reported at around $400 and another reportedly exceeding $1,700 before the keys were disabled. That spending pattern looks less like someone joyriding on your account and more like industrial-scale data collection.
This reframes the threat model entirely. If keys were only being stolen to run a few extra queries, spend caps would mostly solve the problem. But if the economics of distillation make your key valuable as a data pipe, then attackers have a rational reason to extract maximum volume before detection, and your exposure is measured in both dollars and the risk that your account gets flagged or terminated by the provider for anomalous usage.
The design problem: your agent is a credential aggregator
Here is the part that should make every user of an AI coding tool uncomfortable, regardless of which tool it is.
Most AI coding agents support dozens of providers, and the standard onboarding is the same everywhere: paste your API key into a dashboard or config file, and the platform handles the rest. Each platform that does this is, functionally, a key vault. OpenCode Console happened to be the one that got breached this week, but the property is not unique to OpenCode. It is the architecture.
Run the math on your own setup. If you use three AI tools and each holds a copy of your provider keys, a breach at any of the three exposes keys that can bill you at every provider. Your real attack surface is not your laptop and not your provider account. It is every third-party dashboard holding a credential with your name on the invoice.
And there is a second-order effect worth sitting with: the reports say OpenCode's own guidance is that users who did not get an email were not impacted. That is a reasonable thing to say during an ongoing incident, but it means your safety depends on the vendor's breach-detection being complete. With a legacy system being decommissioned, the honest assumption for any platform is that the discovery lags the exposure.
The 20-minute API key audit
This is the checklist worth saving. It applies to every AI tool you use, not just OpenCode. Fifteen to twenty minutes, and you only need terminal access and your provider dashboards.
Step 1: Find every key living on your machine.
Before you can rotate anything, you need an inventory. These commands surface keys hiding in shell history, dotfiles, and environment configs:
# Scan shell history for pasted keys (works for zsh and bash)
grep -aE "sk-ant-|sk-proj-|sk-[A-Za-z0-9]{20}|AIza[A-Za-z0-9_-]{30}" \
~/.zsh_history ~/.bash_history 2>/dev/null
# Find .env files in your active projects
find ~ -maxdepth 4 -name ".env*" -not -path "*/node_modules/*" 2>/dev/null
# Check common agent config directories for stored credentials
ls ~/.config 2>/dev/null | grep -iE "opencode|claude|codex|cursor|aider"
Anything that shows up in shell history was typed in plaintext and may already be in backups. Treat it as exposed.
Step 2: Map which tools hold which keys.
Open each AI tool you use and list which provider keys it has saved. Write it down. The output is usually uncomfortable: the same OpenAI or Anthropic key reused across two or three tools, sometimes the exact same key that has not been rotated since you created the account.
Step 3: Break the reuse. Create one key per tool.
This is the single highest-value change. In your provider dashboard, generate a separate key for each tool that needs one. When a platform gets breached, as OpenCode did, you revoke exactly one key and nothing else breaks. With a shared key, one breach forces you to rotate everywhere at once, which is exactly the kind of day nobody plans for.
Step 4: Cap the blast radius with spend limits.
Most provider dashboards let you set monthly usage or budget limits per project or key. Set them below what would hurt. A stolen key with a $50 cap is an annoyance; an uncapped key is a $1,700 surprise. While you are in the dashboard, check the usage page filtered to the last seven days and look for volume you do not recognize. That is where affected OpenCode users found their surprise charges.
Step 5: Rotate anything stored on a hosted dashboard you do not control.
The OpenCode email itself has the right order of operations, and it generalizes: revoke the key at the provider's dashboard first, not just inside the tool. Deleting a key from a workspace does not kill it. Only revocation at the provider does. Then create the replacement and update the applications that use it.
Step 6: Stop pasting keys into shells.
Load them from a file or a secret manager instead. If a key never crosses your shell history, an entire class of accidental exposure disappears.
If you are an OpenCode Console user
Follow the guidance from OpenCode's email directly, in this order:
- Revoke the affected provider keys in the OpenAI, Anthropic, or Google dashboard, not just in the Console.
- Create replacement keys and update every application or script that used the old ones.
- Review recent usage on each provider dashboard for charges or volume you did not generate.
- If you did not receive OpenCode's email, OpenCode's position is that you were not affected, but the audit above costs twenty minutes and removes the doubt.
What I would do differently going forward
The lesson I would take from this week: treat every agent platform's key storage as if it will eventually be breached, because some platform in your stack eventually will be. That means no master keys, no unlimited budgets, and no key older than a few months living in a third-party dashboard.
Concretely: one scoped key per tool, a spend cap on every key, a calendar reminder to rotate them quarterly, and a standing rule that a key pasted into any hosted dashboard is a key you have decided the vendor can lose.
None of this means stop using coding agents. The productivity gains are real. It means the credential hygiene has to catch up to the tooling, and right now, for most developers, it has not. The industry spent two years teaching everyone to paste their provider keys into every agent that asked. The OpenCode breach is the invoice for that habit arriving in batches of 1.4%.
Full disclosure: This article is based on OpenCode's public statements, the customer email shared publicly in the Hacker News discussion, and coverage from security researchers including Matt Johansen. The writer has not used OpenCode Console directly, and details of the intrusion remain unconfirmed while the investigation is ongoing.
I write about developer tools, AI infrastructure, and backend engineering every week. Subscribe, it is free, and next week's pieces will dig into what the distillation economy means for open model releases.
Do you actually know which tools hold copies of your API keys right now? If you did the audit above, comment with how many keys you found and the oldest one still active.
Sources:
