Here’s the scenario that should keep AI-coding-agent users up tonight: a service you trust quietly holds copies of your OpenAI, Anthropic, and Google API keys — credentials billed directly to your credit card. One breach at that vendor, and an attacker is running frontier-model queries on your dime. That scenario became real in the OpenCode API key breach disclosed on October 17, 2026, when the popular open-source coding agent revealed that customers’ stored AI API keys in its hosted Console service may have been exposed — with some users already reporting unauthorized charges.
Let’s unpack what happened, who’s in the blast radius, and what this incident teaches every team that hands API keys to third-party agent tooling.
What happened: the OpenCode API key breach disclosure
The OpenCode API key breach was disclosed on X on October 17, 2026 (edited at 6:08 PM UTC that day):
"We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users
We have notified them all this morning via email. If you did not get an email you were not impacted, it was a subset of users who had external providers linked
The incident is ongoing so we cannot share more details at this point but we are working with Anthropic, OpenAI, and Google to remediate"
Two things stand out: the incident is ongoing — a live response, not a tidy post-mortem — and the scope is deliberately narrow: OpenCode Console, the hosted service, not the open-source agent itself.
The notification email, titled “Action Required: Potential provider key breach” and sent the morning of October 17 (as reported by TechCityAuthority, based on screenshots users shared), states that OpenCode “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.”
The timeline, as far as it’s publicly known
Stitching together the disclosure and the reporting so far:
- Early October 17: An intruder reached a legacy system at OpenCode, per the notification email; one affected user’s follow-up notification put the earliest possible exposure at 00:30 UTC (as reported by AI Primer).
- Morning of October 17: OpenCode emails affected Console users.
- ~5:56 PM UTC, October 17: OpenCode posts its public disclosure on X (edited at 6:08 PM UTC).
- October 17–18: Users report unexpected provider charges — per The Hacker News, some affected users were publicly quoting charge amounts of $281/$168, others larger ones — and refunds were reportedly “already underway” per OpenCode’s maintainer. Per The Hacker News, co-founder Dax Raad also wrote on X on October 18 that attackers had been “non stop trying to attack our systems for the past 48 hours.”
A lot remains unknown, and OpenCode has been upfront about that: what the legacy system was, how the intruder got in, which keys were copied, how many users 1.4% represents. Notably, as of TechCityAuthority’s reporting, OpenCode’s status page showed no incident and the project’s GitHub had no security advisory — unusual for a breach of this scale, and presumably a consequence of the live investigation.
About that name
The phrase “distillation attack” has nothing to do with someone stealing your code agent. In AI-security parlance, distillation means training a smaller model on the outputs of a larger one — Anthropic’s research post on distillation defenses defines the illicit variant as “covert, industrial-scale campaigns to extract the capabilities of one model and replicate them in another, without the authorization of the original model’s developers.” OpenCode used the same term for its breach but has not explained the connection. The obvious implication — which TechCityAuthority and others point out — is that exposed keys would let someone run massive volumes of frontier-model queries on victims’ accounts, exactly the compute distillation campaigns consume. But at publication time that link remains the company’s assertion, not a documented technical detail.
Either way: “distillation attack” here is OpenCode’s label, not a claim that OpenCode’s models were distilled. Don’t conflate this with the distillation campaigns the major labs have reported against themselves — different event, different target, same vocabulary.
Whose keys were exposed in the OpenCode breach, and what attackers can do with them
OpenCode’s Console documentation describes the feature at the center of this incident: teams can “connect provider accounts you already pay for, such as Anthropic, OpenAI, or AWS Bedrock” by entering that provider’s API key. “Console stores the credential and serves each provider through its gateway, so members use the models without ever seeing the provider key.” The catalog includes Anthropic, OpenAI, and Google — the three providers OpenCode says it’s coordinating with — plus xAI, DeepSeek, Mistral, Groq, OpenRouter, and more.
Design-wise, that’s genuinely sensible: a shared vault so teammates never handle raw AI API keys. The trade-off is concentration: one vendor’s database now holds working keys to multiple expensive provider accounts — an attractive target.
The economics of a stolen API key
A provider key is a bearer credential: whoever holds a copy can run billable requests against the owner’s account until the provider revokes it, as The Hacker News put it. And here’s the particularly nasty property of the OpenCode API key breach: the bill lands on the victim, not the attacker.
Frontier-model tokens are expensive. Reported figures floating around social media within hours — $281 on one user’s OpenAI key, $168 on their Anthropic key, another user claiming roughly $1,700 in losses (relayed by The Hacker News, citing Dealroom), a $400 unauthorized Anthropic charge shared by @kimmonismus — are self-reported, but they sketch the damage: hundreds of dollars per affected user, accruing fast.
The blind spot that made it worse
There’s a subtle mechanism here worth understanding, because it applies far beyond OpenCode. Console’s docs say the provider bills you directly for tokens the gateway forwards, and that Console records each request for its usage reports and budgets. But Console only sees requests that pass through Console. A thief holding a copy of your key can hit api.anthropic.com or the OpenAI API directly — those requests never appear in your OpenCode dashboard and never trip your workspace budget. As one user quoted by TechCityAuthority noted, only their provider-side spending limits kept the damage contained. The bill arrives from Anthropic or OpenAI, which is why everyone steers affected users toward the providers’ dashboards, not Console’s.
The affected population is also narrower than the headline suggests:
- Affected: Console users who linked external provider keys (the ~1.4% subset), all of whom should have received the notification email.
- Not affected: anyone who never received the email, per OpenCode, and — critically — users whose keys live only on their own machines. Keys added through the agent’s
/connectflow are stored locally (per OpenCode’s client documentation, cited by AI Primer, in~/.local/share/opencode/auth.json). As co-founder Dax Raad put it, per The Hacker News: the breach involves “the OpenCode Console, not OpenCode itself,” and locally held keys “never come to us.”
The shared branding did OpenCode’s communication no favors — the Hacker News discussion filled with people asking whether the locally installed agent had been compromised. It had not, as far as anyone has said publicly. But the lesson generalizes: when a product family spans a local tool and hosted services, confusion about where your secrets actually live is itself a security problem.
Rotate, revoke, audit: what to do after the OpenCode API key breach
The notification email and the provider-specific reporting converge on the same short list. This isn’t vendor-specific instruction — it’s standard bearer-credential hygiene that would apply after any exposure of this kind:
- Revoke the key at the provider, then issue a new one. Delete the key in the provider’s own dashboard (OpenAI’s platform settings, Anthropic’s console, Google Cloud credentials) and generate a replacement. Deleting the key from Console does nothing to a thief who already copied it — and Anthropic has already revoked Claude API keys it believed were affected, per its developer-relations lead Lydia Hallie, as quoted by TechCityAuthority.
- Update every application and script that referenced the old key — the classic “I rotated the key and broke my cron job at 2 a.m.” failure mode.
- Audit usage and billing on the provider side for requests you didn’t make, going back at least to October 16 — earlier if you can. OpenCode has not said when unauthorized access began, and the trail may not exist in Console at all.
- Set spend limits and alerts at each provider. It’s the difference between an ugly afternoon and a four-figure invoice.
1 | # Conceptual: provider-side protections to enable for every key |
One more note: OpenCode’s Console docs include a key-rotation flow in its provider settings, but rotating the vault copy doesn’t help unless the old key gets revoked at the provider. Vault rotation and provider revocation are two separate actions; do both.
This isn’t a supply-chain attack: why the mechanism matters
It’s tempting to file anything with “agent” and “breach” in the headline under “supply-chain attack,” but the OpenCode breach follows a different mechanism, and the difference dictates the defense. In a code-level supply-chain attack, malicious code reaches your machine through a package or build pipeline — as in the recent npm supply-chain attack that leaned on valid certificates and stolen accounts — and the compromised component is something you run. Here, nothing on your machine was malicious. The failure was key custody at the platform: OpenCode held customer secrets, and OpenCode’s infrastructure was breached. Your laptop is fine; your Anthropic bill is not.
For that first failure mode, see our earlier coverage of a trapdoor-style supply-chain attack on AI coding assistants.
That distinction matters operationally. Defenses against malicious supply-chain code look like dependency pinning, build reproducibility, and SBOMs. Defenses against leaked vendor-held credentials look like blast-radius engineering — spend caps, key scoping, per-tool keys, and picking vendors who minimize what they must hold. Those toolsets barely overlap, so knowing which failure mode you’re facing matters.
Worth saying, too: this is not OpenCode’s first rodeo with key-handling criticism. TechCityAuthority notes the project previously fixed a bug in which its web interface sent raw API keys to the browser, though there’s no indication it’s connected to this incident. None of that proves anything about how the legacy system was breached, but it suggests credential custody in fast-moving agent tooling deserves scrutiny regardless of vendor.
Agent key-vaulting: a target class in the making
Zoom out for a moment. Any platform that vaults customer API keys to a set of high-quota frontier models has quietly become a honeypot: a single stolen credential or exposed database row grants free access to expensive compute, billed to someone else. This attack surface isn’t hypothetical either — researchers have already exploited AI coding assistants on stage at Pwn2Own Berlin 2026. Cryptobriefing’s framing of the OpenCode incident is apt — the stolen asset wasn’t passwords or card numbers, it was “the ability to make large volumes of queries to frontier models on someone else’s dime,” and a stolen frontier-model key “can generate training data worth far more to a competitor than the bill it leaves behind for the victim.”
The timing also matters. The same week, Huntress published an investigation into a compromised vendor credential belonging to ConnectWise Cloud Backup (formerly SkyKick) being used to sign in to customers’ Microsoft 365 tenants — a separate event with a different mechanism. Huntress confirmed the credential was a client assertion living in the vendor’s own tenant (“Nothing a customer did in their environment could have produced it”), with unauthorized sign-ins eventually observed in hundreds of Entra tenants. No phishing, no MFA bypass — just a vendor-side credential doing what vendor credentials do.
Two vendors, two asset types, one shared theme: the perimeter didn’t fail at the customer — it failed at the vendor that holds the customer’s identity. In the agentic-AI era, the identities worth stealing increasingly include API keys that mint tokens at list price.
There’s a supply-side angle, too. Anthropic’s distillation-defenses post notes that distillers “distribute traffic across Anthropic’s API, third-party cloud platforms, and other inference providers,” and says “platforms — as well as developers — have a role to play in reducing distillation” by “quickly detecting and disrupting abuse, and by offboarding fraudulent accounts.” If OpenCode’s naming holds up, the OpenCode API key breach is a case study in why: when the labs lock the front door, intermediaries holding customer keys become the side entrance. If you build an agent platform that vaults provider keys, expect to be attacked for exactly this reason — and expect your customers to bear the billing risk when you fail.
Practical checklist for teams using agent tooling
If your team uses coding agents, gateways, or anything that touches provider credentials, here’s a distilled — pun intended — checklist. General best practices, not vendor instructions:
-
Prefer not to hand over the key at all. Where a platform offers OAuth or provider-managed tokens instead of raw AI API keys, use it. AI Primer reports that OpenCode’s agent defaults to OAuth tokens rather than long-lived API keys for login-based connections — a design worth copying.
-
Keep local secrets local, and out of git:
1
2
3
4
5
6
7
8# .gitignore — always
.env
.env.*
credentials*.json
auth.json
# Reference secrets via environment, not literals
export ANTHROPIC_API_KEY="$(pass show anthropic/dev-key)" -
One key per tool. If your agent, your CI job, and your scripts each have their own key, a leaked key is traceable to its origin and revocable without collateral damage. Shared keys are how “one incident” becomes “every incident.”
-
Scope every key down. Restrict keys to the models and endpoints each tool actually needs. A read-only-tier or limited-model key that leaks is a smaller invoice.
-
Cap spend at the provider, not just in the tool. As the OpenCode API key breach demonstrated, an in-tool budget only observes traffic that flows through the tool. Hard ceilings and alerts at the provider are the only spend controls that survive a leaked key.
-
Review provider billing weekly while any agent tooling holds your keys — not just during incidents.
-
Ask hard questions of vendors before linking keys. What do you store, how is it encrypted, what’s your incident-notification SLA? A vendor who can’t answer quickly is telling you something.
-
Have a rotation runbook ready. Mid-breach is the worst time to reverse-engineer which of your 14 services uses which key. A simple inventory (tool → provider → key ID → owner) turns hours into minutes.
Incidents like the OpenCode API key breach will not be the last. Agent platforms are multiplying — and as our breakdown of the Gemini agent breakout that rippled into three companies shows, every one of them is a candidate for the same attack economics. The teams that come out fine won’t be the ones who picked the “safe” vendor. They’ll be the ones who engineered the blast radius so no single vendor failure could drain their accounts.
The uncomfortable takeaway: the moment you paste a provider key into someone else’s web console, your security perimeter extends to include their legacy systems, their decommissioning discipline, and their incident response. Choose like you mean it.
References and further reading
- OpenCode (@opencode) on X — the original breach disclosure, October 17, 2026
- dax (@thdxr) on X — “non stop trying to attack our systems for the past 48 hours,” October 18, 2026
- OpenCode Console docs — Providers (connected accounts and gateway)
- OpenCode docs — Providers (/connect and local key storage in auth.json)
- Anthropic — Strengthening our defenses against distillation attacks
- Anthropic — Detecting and preventing distillation attacks
- The Hacker News — OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys
- TechCityAuthority — OpenCode confirms Console breach tied to distillation attack hit 1.4% of users
- AI Primer — OpenCode reports a Console breach affecting 1.4% of users
- Cryptobriefing — OpenCode discloses distillation attack that hit 1.4% of Console users
- Huntress — ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks
- ConnectWise Trust Center — Advisories
- Hacker News discussion — OpenCode has a security breach that impacted 1.4% of console users
Please let us know if you enjoyed this blog post. Share it with others to spread the knowledge! If you believe any images in this post infringe your copyright, please contact us promptly so we can remove them.