Why did the models stop helping halfway through OpenCode's incident?
The frontier models helping with the investigation started refusing. The fix was a vetted-access tier from the vendor, which works, but only once someone approves you.
On October 17, OpenCode emailed about 1.4% of the people who use its Console. “We identified unauthorized access to a legacy system that we were in the process of decommissioning,” it said, and the OpenAI and Anthropic keys those users had saved in their workspaces “may have been exposed.” The next day, co-founder Dax Raad wrote that the attackers had been “non stop trying to attack our systems for the past 48 hours.” Someone asked whether the cyber safeguards on frontier models were getting in the way. He said they were.
So why did the models stop helping halfway through? Because the defender didn’t own the setting that mattered. The model’s vendor decides how much security work it will do, and OpenCode’s request to change that setting was still being processed when the attack began.
What happened#
| When (UTC) | What |
|---|---|
| Night of Oct 16 | The breach, which OpenCode later described as happening “last night”. |
| Oct 17, morning | OpenCode emails affected Console users to revoke and replace their provider keys. |
| Oct 17 | OpenAI approves OpenCode for Daybreak Blue, a few days after it applied. |
| Oct 17, 18:08 | OpenCode on X: “a large scale distillation attack”, 1.4% of Console users, incident ongoing. |
| Oct 17, 18:41 | Dax posts: “my personal accounts are being attacked now too.” |
| Oct 17, 21:04 | Anthropic’s Lydia Hallie says it has revoked the Claude keys it believes were affected. |
| Oct 18, 12:04 | Dax posts about 48 hours of non-stop attacks. |
| Oct 18, 14:46 | Dax replies that the models started refusing mid-investigation, and that the team now has Daybreak Blue. |
The breach was in the Console, OpenCode’s hosted service, not in the open-source coding agent. Dax made that point himself: keys you give the local agent “never come to us.”
OpenCode hasn’t explained “distillation attack,” because the incident is ongoing. The usual meaning is querying a frontier model at scale and training a cheaper model on the answers. Stolen provider keys suit that well, since somebody else pays for the queries. Users have reported charges from a few hundred dollars to $1,700.
Who is the attacker? Unknown. Who is the victim? The Console users, who pay for the tokens, and the model vendors, whose outputs are being harvested. What did the attacker gain? Frontier model output on someone else’s bill. OpenCode was just where the keys were kept.
The refusals#
You might say the models were being sensible. A stranger asking how an attacker got into a system, and what the attacker did next, looks a lot like an attacker asking the same thing. AWS’s write-up of Daybreak puts it this way: cybersecurity is “inherently dual use,” and “general-purpose models resolve that ambiguity by declining the request.” An investigation is about as dual-use as security work gets. You read the attacker’s tooling and replay their steps to see whether they still work.
OpenAI’s own explanation fits “did quite a bit and then started refusing.” In production, it says, “we deploy system-level safeguards to screen cybersecurity-related requests to prevent misuse, but they can also block legitimate defensive work.” A screen like that judges each request as it arrives, so an investigation can go fine until it reaches the part that looks like an attack.
Daybreak settles the ambiguity with identity instead. “Daybreak Blue access removes those guardrails,” OpenAI says, “helping defenders get more out of the model in real-world security tasks, including incident detection and response, investigations, vulnerability management, and security assessments.” In exchange, OpenAI controls access “through identity verification, account security, monitoring, approved-use restrictions, and legal attestations,” and it has required hardware security keys on individual Daybreak accounts since September 1.
Blue doesn’t loosen everything. OpenAI says that even without the screens, GPT-5.6 Sol still refuses “highly dual-use” prompts such as pentesting production systems. On its internal Advanced Cybersecurity Completion Rate eval, which asks for exploit chains, authentication bypasses and privilege escalation, GPT-5.6 Sol completes 1.5% of requests and Blue completes 2.0%. GPT-5.6-Cyber, on the separately approved Red tier, completes 95.0%. So Blue loosens the defensive work and leaves the offensive refusals roughly where they were. For an investigation, that’s the right shape.
This is the same dial as in the Hugging Face breach, with a different hand on it. There, OpenAI’s own models ran with their cyber refusals turned down for an evaluation, and Hugging Face, unable to get commercial APIs to read its own logs, switched to an open-weight model on its own hardware. OpenCode asked the vendor to turn the dial for it, and the vendor did.
Both approaches work. The difference is when they’re available. An open-weight model is yours as soon as it’s downloaded. Vetted access is yours once someone approves it. OpenCode, as it happens, had applied before anyone attacked it. Dax says they “coincidentally applied for it a few days ago and it got approved yesterday.” That’s a few days from application to approval, and the approval still landed the day after the breach, with refusals in between. OpenAI doesn’t publish approval times, and its documentation warns that “submitting an application or completing identity verification doesn’t guarantee approval.”
So treat model access like any other incident-response dependency, and arrange it well before you need it. A few days early was almost early enough. Apply for your vendor’s vetted tier while nothing is on fire, keep an open-weight model ready on hardware you control, or do both. OpenAI takes applications from individuals and organizations. On Amazon Bedrock, there’s a second step through your AWS account team. OpenAI’s $1 billion subsidy for Daybreak access names open-source maintainers among the groups it prioritises, which would cover a team like OpenCode’s.
Postscript: OpenCode isn’t the first platform this month to lose customers’ secrets. Fireworks AI’s bulletin says that someone using internal Fireworks credentials reached the environment variables of some customers’ evaluation jobs, and captured the API keys and tokens stored there as secrets. Fireworks spotted it on October 6, started notifying customers on October 7, and published the bulletin on October 9.
Exercise: A Console user reads the email, opens their workspace and deletes the saved Anthropic key. A day later, their Anthropic usage is still climbing. What did they miss?
Show an answer
Deleting the key in the Console removed OpenCode’s copy. The attacker has their own copy, and a key stays valid at the provider until it’s revoked there.
The fix is in the Anthropic console: revoke the old key, create a new one, put the new one wherever it’s needed, and check usage for the period the old key was exposed. Anthropic revoked the keys it believed were affected, so an affected key it missed is still live until the owner revokes it. Fireworks’ bulletin gives its own customers the same warning: “Removing a stored secret alone does not invalidate the underlying credential.”