OpenCode breach: why stolen API keys get drained

If you pasted an Anthropic OpenAI key into a hosted coding tool, the OpenCode breach is a reason to check your provider billing today. OpenCode says a legacy system awaiting decommission exposed saved provider keys for 1.4% of Console users, and it ties the incident to a large-scale distillation attack. The practical risk is a bill you never ran up.

What the OpenCode breach actually exposed

The OpenCode breach exposed saved external provider keys, not prompts or repository contents, through a legacy system the team was in the process of decommissioning. OpenCode disclosed on October 17, 2026 that 1.4% of its Console users were affected, and it described the incident as ongoing.

OpenCode is an AI coding tool with both a local open-source command-line client and a hosted Console. The two are not the same surface. A later clarification relayed through secondary summaries says the affected users were a subset who had linked external providers in the hosted product, not people running the local CLI. That distinction matters: a key stored on your laptop was never in this database.

The exposed values were API keys for Anthropic and OpenAI, the two model providers whose API keys the Console could store. A provider API key is a bearer credential. Anyone holding it can submit requests billed to the associated account until the key is revoked or the account runs out of credit.

As of October 18, 2026, several questions were unanswered: how the attackers reached the legacy system, how the keys were stored at rest, how long access lasted, and how many keys were taken. OpenCode called the investigation ongoing and declined to share more. Treat any number circulating beyond the 1.4% figure as unverified.

Why a stolen key is worth more than a fake account

A stolen key is valuable because frontier-model copying needs enormous volume, and volume from new accounts collides with the anti-abuse controls that providers have added. A real customer key arrives with an established identity and a working payment method.

Model distillation, in this context, means training a smaller model on the outputs of a stronger one. In Anthropic February 2026 post on distillation defenses, the company calls copying your own models acceptable and copying a rival's model a violation of its terms. The post reports that more than 16 million exchanges ran through fraudulent accounts operated by three labs.

That scale explains the pressure. Anthropic describes proxy networks it calls hydras, including one that managed more than 20,000 fraudulent accounts at once and mixed copying traffic with real customer traffic. Every fake account still needs an identity and a way to pay, and some were opened with false identities and stolen payment details, according to Anthropic later post.

Anthropic defenses narrow the gap. The company describes a two-stage classifier that flags copying-shaped requests with a false positive rate under 0.1%, stricter limits for repeat offenders, billing for blocked requests, bans that often land within two hours, and a measure it calls preserved thinking. Anthropic reports that these reduced the data distillers could harvest from its platform by roughly 90% to 99% on its own measurement.

Where account age and stolen keys intersect

One Anthropic control is drawn on account age, and that is where a stolen key gets interesting. Anthropic says preserved thinking stops API accounts created on or after August 31, 2026 from editing Claude prior context. How that blocks copying is not spelled out in the material available.

A long-standing customer key therefore falls on the permissive side of a rule that a fresh fake account does not. The classifier and the rate limits still apply to every account, old or new, so a stolen key is not a free pass. It is a credential that avoids one specific restriction.

The claim that this makes stolen keys more valuable to copiers and resellers is an analyst argument, not a finding. Anthropic post on distillation defenses does not mention stolen keys at all, and no source shows that the keys exposed in the OpenCode breach were used for distillation. OpenCode's link between the breach and a distillation attack remains its own unexplained claim.

What users report is the bill. A Hacker News commenter described an Anthropic account drained of 20 dollars in monthly API credit, and Colin Parsons self-reported 281 dollars of usage on OpenAI plus a smaller Anthropic charge. Neither figure has been confirmed by OpenCode or by the providers, so treat them as user accounts rather than audited losses.

The second leak path runs through MCP tool servers

A breached vendor is only one way a key escapes. The other sits on your own machine, in the Model Context Protocol servers your agent calls to read files, run Git and reach other tools.

The paper My Credentials, Please screened 4,806 MCP servers from public registries. Of those, 787 advertised filesystem capabilities despite not being classified as file tools, a screening signal rather than a confirmed-vulnerability list. Dynamic testing then confirmed 150 as exploitable. The researchers' disclosures included two published CVEs in Anthropic own Git server.

The mechanism is an approval boundary that stops at the wrong place. When your agent invokes a tool, you approve the arguments the tool declared, but the server process runs with whatever your user account can read. In the paper's Git example, a staging tool accepts a file path without checking that the path stays inside the repository. A crafted path climbs out of the folder, the file gets staged, and a later call that lists staged changes returns its contents to the agent.

A separate flaw in the filesystem server worked more plainly. Elad Biper at Simulate found that its folder check compared text prefixes, so allowing one folder also allowed a sibling folder whose name began with the same characters. A patch for that landed in July 2025, and a second issue used symbolic links to slip past the same fence. Nothing ties these flaws to the OpenCode breach, but a key stored in a file your user account can read sits within the same reach.

Four habits that cap the damage

Four documented controls limit what a leaked key can cost, and each maps to a specific capability a provider or researcher has published. None of them depends on the still-unconfirmed distillation link.

1. Create one key per tool. Anthropic Console ties each API key to the workspace it was created in, and the key cannot be moved afterward. Give each tool its own workspace so that a leak costs you one revocation and breaks one tool.
2. Set spend caps per workspace. Each Anthropic workspace can carry its own spend limit, which cannot exceed the organization's limit. Paired with a workspace per tool, a leaked key can only reach that tool's ceiling. A cap limits the bill, not the misuse. OpenAI's equivalent is less clear, and a university help page describes cost limits applying at project level, so a project per tool is the closest match. That page is secondary evidence; confirm it in OpenAI's dashboard before relying on it.
3. Stop saving keys in hosted apps. OpenCode's own email says provider keys saved in the workspace may have been exposed. Keys held by someone else's system are one more breach surface you cannot patch. OpenAI's production guidance recommends environment variables or a secret manager, with expiry and rotation, or routing tools through a gateway you operate.
4. Sandbox tool servers. The paper's registry-level recommendation is operating system process isolation, because approval prompts do not fence the process. A container or a restricted user account are common forms of that. Whether either stops the two Git flaws was not tested in this work.

Control	What it limits	Evidence status
One key per workspace	Blast radius of a single leak	Anthropic documents workspace-bound keys
Spend cap per workspace	Maximum drawable spend	Anthropic documents per-workspace limits
No keys in hosted consoles	Breach surfaces you do not control	OpenCode email; OpenAI guidance
Process sandbox	Files a tool server can read	Research recommendation, untested against Git CVEs

If you saved provider keys in a hosted console, revoke them now and stop storing them there. That is the one action this incident points at directly. If your keys live on your laptop, give each tool its own capped key. If you run many third-party MCP servers, sandbox those first.

Frequently asked questions

• Was OpenCode itself hacked, or was a third party compromised? OpenCode reported that a legacy system it was decommissioning exposed keys that users had saved with it. The disclosure came on October 17, 2026. OpenCode has not said how attackers reached that system or how many keys were taken.

• Should I revoke my Anthropic OpenAI API key after this? If you stored a provider key in the OpenCode Console, revoke it at the provider and issue a replacement. Review recent usage while you are there. A key kept only in a local environment variable was not part of the exposed Console set, according to the relayed clarification.

• Can a stolen key be used to copy a model? In principle a working key with a real payment history can push bulk requests through anti-abuse controls that catch new fake accounts. No source shows that the OpenCode breach keys were used that way. OpenCode's distillation claim remains unexplained.

• Do Anthropic anti-distillation defenses cover stolen keys? Anthropic classifier, rate limits and bans apply to every account regardless of age, so a stolen key still faces them. The preserved-thinking rule drawn on account creation date is the control a long-standing key avoids. Anthropic distillation post does not discuss stolen credentials.

• Do spend caps stop misuse of a leaked key? A per-workspace spend cap limits how much a leaked key can draw from your organization. It does not prevent the requests from running or stop a copier from harvesting outputs, so pair it with revocation and per-tool keys.

• How do MCP servers leak keys that agents can read? An MCP server process inherits the file permissions of the user account that started it. If a tool accepts a path without containing it, a crafted path can reach files outside the intended directory, as the Git staging example shows.

• Is the 1.4% figure a count of affected keys or users? OpenCode described 1.4% as a share of its Console users, not a count of exposed keys. A single user may have stored more than one provider key, so the key count could be higher. OpenCode has not published a total.

• Should I trust the dollar figures users posted? The 281 dollar OpenAI figure and the 20 dollar Anthropic credit drain are self-reported by users. Neither OpenCode nor the two providers has confirmed them. Treat them as illustrations of the risk, not audited loss data.

• Where does CrazyStack TypeScript fit into this? CrazyStack TypeScript is a TypeScript full-stack starter kit from the Brazilian developer community around Dev doido, and its relevance here is practical: fewer hand-rolled integrations mean fewer places to hardcode a provider key. Keep those keys in environment variables or a secret manager either way.

• What is still unknown about the OpenCode breach? OpenCode has not disclosed the intrusion method, how keys were stored, how long access lasted, or which model was allegedly being copied. The company called the incident ongoing and said it cannot share more, so details may change as the investigation proceeds.

Turning a security lesson into written content

Security explanations age fast, and the useful part of any incident write-up is the reasoning that survives the next disclosure. The OpenCode breach is a good example: the revocation advice is simple, but the distillation economics and the MCP tool-server boundary are what people actually want explained.

If you already talk through this kind of material on video, that recording holds the explanation, the examples and the caveats. Skala Blog turns a YouTube URL into a transcribed, structured draft you can edit and publish as an article, so the reasoning you already worked out reaches readers who will never watch the video.

Skala Blog is built for exactly this: paste the link, let the transcript come through, and shape it into something searchable. The audio and video work you already did becomes a written reference you can point people to.

Source video