On the night of October 16, an unauthorized party got into a legacy system that OpenCode was in the middle of shutting down. That system still held the OpenAI, Anthropic, and Google API keys customers had saved in OpenCode Console, the company's hosted service for sharing model access across teams. By the time affected users read OpenCode's notification the next morning, some had already found charges on their provider accounts for usage they never ran.
By headcount, the incident is small: it touched roughly 1.4% of Console users. But it exposes two problems that reach well beyond one vendor. Most organizations don't govern AI provider keys like privileged credentials. And when those keys are stolen, the abuse looks almost exactly like legitimate use.
Console was built to solve a real problem. Instead of handing raw provider keys to every developer, a team stores its credentials in Console, which authenticates requests to OpenAI, Anthropic, or Google on the team's behalf. Developers get model access without ever seeing a key.
OpenCode disclosed the breach on October 17 and tied it to a large-scale distillation attack. Distillation means querying a model at high volume to harvest its outputs for training a competing one. According to the company's customer notification, the intruder reached a legacy Console system that was being decommissioned. Affected users were told to revoke their keys with each provider and review recent usage. Only workspaces with external providers linked were in scope. OpenCode co-founder Dax Raad stressed that the open-source CLI and desktop apps, which store keys locally, were not involved.
Some details remain unsettled. OpenCode says the keys "may have been exposed" and has not publicly confirmed that specific keys were copied, although user reports of unauthorized charges suggest at least some were used. According to Dealroom, Anthropic revoked affected Claude keys. OpenCode says it is coordinating remediation with all three providers.
The breach landed where it did because of what Console was holding. Centralizing keys beats scattering them across laptops, but it also concentrates them in one place. "The platform becomes a single point of failure," said Chris Hughes, Vice President of Security Strategy at Noma Security, "where one compromise exposes access to several frontier providers at once."
Pathlock's Chris Radkowski, a security and risk expert, argues the deeper issue is how organizations classify these credentials in the first place. He compares them to firefighter access in ERP systems. That kind of access grants broad, powerful privileges for a short window, and it is requested, approved, monitored, and reviewed afterward. An AI provider key carries comparable power: it can run up costs, expose prompts and data, and let an attacker act as the organization. Yet the key, Radkowski noted, "often has no expiry, no owner, and no review."
That governance gap also explains how live keys ended up sitting in a retired system. "Old infrastructure that still holds live credentials is a common target," said Shreyans Mehta, co-founder and CTO of Cequence Security, "because it tends to drop off the monitoring list before it's actually shut down." Mehta's prescription for any credential broker is to protect it like a password vault, and to keep doing so for systems on their way out.
The second lesson is about detection. In a traditional credential theft, the credential is a way to get inside. A stolen AI key is the prize itself.
"A stolen model key isn't used to break in," Mehta explained. "Its value is running large volumes of valid requests on someone else's account." That is why the distillation link matters. Harvesting frontier model outputs at scale is expensive, and stolen keys shift the bill to the victim while the attacker walks away with training data.
Because every request carries a valid key, authentication offers no signal. The warning signs are behavioral: sudden spikes in volume, calls to models a team doesn't normally use, and activity at odd hours. For many affected users, the first indicator wasn't a security alert; it was a drained balance or an unexpected invoice.
This is where the two problems compound. Behavioral monitoring only works if someone owns the key and knows what normal usage looks like. A credential with no owner and no defined scope has no baseline, so when usage turns abnormal, nobody can notice.
For organizations that linked providers to OpenCode Console, the experts agree on the immediate response. Assume exposure and rotate every provider key stored there, revoking each key at the provider rather than simply deleting it from Console. Radkowski recommended creating replacement keys before revoking the old ones so production doesn't break, and reviewing provider usage from October 16 onward.
Next, limit what any single key can do. Mehta and Hughes both recommended scoping each key to one project and setting hard spending caps with usage alerts. That turns a silent drain into a contained, visible incident.
The longer-term work is inventory and ownership. Hughes urged teams to map which agents and developer tools hold or broker AI keys across their environment, and to build visibility into how those tools reach frontier models. Radkowski's prescription borrows directly from privileged access management: assign every AI credential an owner, enforce least privilege, set expiry and rotation, and review on a schedule.
OpenCode's breach doesn't argue against centralizing AI credentials. It raises a different question: whether anyone is treating those credentials as the privileged access they've become. "Organizations that treat AI keys as privileged entitlements will contain the next incident quickly," Radkowski said. "Those that treat them as developer conveniences will find out the hard way."