The OpenCode Breach: Your Agent's Keys Were the Target

The OpenCode Breach: Your Agent's Keys Were the Target

The OpenCode breach exposed stored provider API keys for 1.4% of Console users, and spend alerts fired before any vendor notice did. Attackers ran AI agents against the platform for 48 hours, according to co-founder Dax Raad, and OpenCode's own defensive models refused to read the malicious code. What happened, what it cost, and the key-handling runbook.

What the OpenCode breach took

OpenCode is an open source, model-agnostic AI coding agent that has been gaining ground as an alternative to Claude Code and Cursor. Its Console lets users store the API keys they use with external AI providers.

Attackers broke into an older system overnight, the company said on Saturday, 18 October, per TechCrunch's 19 October report. The notification email put the earliest possible key exposure at 17 October 2026, 00:30 UTC and said no other data appears to have been exposed, according to BleepingComputer, which reviewed the email. Affected users were notified individually. No email means no impact, the company says.

The bill arrived before the disclosure

Developers noticed through spending alerts, not announcements. One wrote on Reddit that OpenAI, Anthropic and Google AI spend alerts all fired before going to bed, per TechCrunch. Others reported unauthorized charges in the hundreds of dollars, and a few described totals above $1,000. BleepingComputer documented one user with more than $1,700 in overnight charges and suspended Google Cloud projects.

The providers moved faster than the disclosure. Anthropic and Google blocked the API keys they believed were exposed, and OpenAI said it worked with OpenCode to restore access and refund credits consumed in the attack, according to TechCrunch. OpenCode said refunds for unauthorized charges are underway.

A distillation attack with reluctant defenders

OpenCode framed the incident on X as a large-scale distillation attack: harvesting a model's outputs in volume to reproduce some of its capabilities. Raad said attackers had been trying to break into its systems nonstop for 48 hours, using AI agents, while the team kept its own defensive agents running around the clock, per BleepingComputer.

Then the twist. The AI models OpenCode turned to for analysis started refusing the work, because the malicious code tripped their safety filters. That was a bit frustrating, Raad wrote on X. The situation stabilized only after OpenCode was approved, on Saturday, to use OpenAI's Daybreak cybersecurity model for defensive work.

The refusal belongs in the record we keep on this blog. In our air-gap letter breakdown, controls designed to stop agents from acting badly also stopped them from acting at all, and the OpenCode defense hit the same wall from the other side.

Why consoles that store keys are a honeypot

A model-agnostic agent needs keys for every provider a user connects, so the Console concentrated OpenAI, Anthropic, Google and other credentials in one stored place. A breach of that store converts directly into money, which is why this incident reads as theft rather than espionage.

The spend alert was the only detection that fired in time. Not EDR, not the vendor, the billing page. In our ChainDrop runbook isolation is the first move because credential theft is the payload; the OpenCode breach is the same physics on the platform side. Our untrusted code guide and zero-public-ip playbook start from the same premise for installs and infrastructure.

The key-handling runbook

1. Segment keys per application and per provider, so one console breach cannot spend your entire AI budget.
2. Set hard spend caps and route billing alerts to whoever is on call, because in this incident the spend alert beat the vendor email by hours.
3. Prefer injected or short-lived credentials over stored ones: environment injection at runtime, OIDC-federated access where providers support it, and no plaintext keys sitting in a web console.
4. Rotate on any vendor breach signal, even a careful one, since the OpenCode notice named an exposure window rather than an absence of access.
5. Check per-provider remediation: Anthropic and Google blocked exposed keys and OpenAI refunded credits, so if your provider did neither, ask why.
6. Sandbox the agent runtime, because a stolen key that chains into your infrastructure stops being a billing problem. A key leaked from a disposable environment with an egress allowlist dies with the environment, which is the posture we run on Krova.

Verdict, and the caveats on this page

Our verdict: the OpenCode breach is a key-handling story, not a model-safety story. Concentrated, stored, long-lived provider keys turned a 1.4% intrusion into real money for the affected users, and the billing page caught it first. Segment, cap, inject, rotate: the runbook is boring because boring works.

• The 1.4% figure and the exposure window are company-stated; no independent audit has confirmed either, which is a limitation of every first-party disclosure.
• Charge figures are user-reported, from hundreds to more than $1,700 overnight, so they do not aggregate into a verified campaign cost.
• The distillation framing comes from OpenCode's own post; however, the motive matters less than the mechanics here, and the mechanics are stolen keys.
• In our Linux microVM fleet we operate containment, not a console, so we can show what isolation looks like and cannot speak to OpenCode's internal architecture beyond its statements.

FAQ

Was the OpenCode breach a supply chain attack?

No. Attackers broke into OpenCode's own platform and took stored customer keys; they did not poison a package or a build. The supply chain angle is downstream: stolen provider keys fund unauthorized runs, and a distillation haul can seed a copycat model. For registry-side attacks, the ChainDrop and MALFEX posts in our npm series cover the other half of the map.

How do I know if my keys were exposed in the OpenCode breach?

Check your inbox. OpenCode notified affected users by email and says users who received no email were not impacted. If you stored provider keys in the Console at any point after 17 October 2026, 00:30 UTC, rotate them anyway, because the notice named a possible exposure window rather than a confirmed absence of access, and rotation is free.

Why did OpenCode's AI models refuse to help defend?

Safety filters. When the team asked AI models to analyse the captured malicious code, the models declined to engage with it, per Raad's account on X, and defensive work stabilized only after OpenCode got approval to use OpenAI's Daybreak cybersecurity model. The same filters that block misuse can block defense, and that trade-off is now an operational fact, not a thought experiment.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "The OpenCode Breach: Your Agent's Keys Were the Target",
      "datePublished": "2026-10-20",
      "dateModified": "2026-10-20",
      "author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
      "publisher": {"@type": "Organization", "name": "Krova Cloud"},
      "mainEntityOfPage": "https://krova.cloud/blog/opencode-breach-api-keys-distillation-attack"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Was the OpenCode breach a supply chain attack?",
          "acceptedAnswer": {"@type": "Answer", "text": "No. Attackers broke into OpenCode's own platform and took stored customer keys; they did not poison a package or a build. The supply chain angle is downstream: stolen provider keys fund unauthorized runs, and a distillation haul can seed a copycat model. For registry-side attacks, the ChainDrop and MALFEX posts in our npm series cover the other half of the map."}
        },
        {
          "@type": "Question",
          "name": "How do I know if my keys were exposed in the OpenCode breach?",
          "acceptedAnswer": {"@type": "Answer", "text": "Check your inbox. OpenCode notified affected users by email and says users who received no email were not impacted. If you stored provider keys in the Console at any point after 17 October 2026, 00:30 UTC, rotate them anyway, because the notice named a possible exposure window rather than a confirmed absence of access, and rotation is free."}
        },
        {
          "@type": "Question",
          "name": "Why did OpenCode's AI models refuse to help defend?",
          "acceptedAnswer": {"@type": "Answer", "text": "Safety filters. When the team asked AI models to analyse the captured malicious code, the models declined to engage with it, per Raad's account on X, and defensive work stabilized only after OpenCode got approval to use OpenAI's Daybreak cybersecurity model. The same filters that block misuse can block defense, and that trade-off is now an operational fact, not a thought experiment."}
        }
      ]
    }
  ]
}