The OpenCode breach shows that in the agent era the weak link is the legacy system where keys are stored

By Startup Fortune · October 17, 2026.

Anomaly Innovations, the company formerly known as SST and developer of the open-source coding agent OpenCode, has warned its users by email that third-party API keys (OpenAI, Anthropic and Google) stored in their workspaces may have been exposed. According to the company, the incident affects about 1.4% of OpenCode Console users, and only those who had external providers linked to their account.

The company attributes the incident to a “large-scale distillation attack” and, according to the message cited by the source, detected unauthorized access to a “legacy system” that was being decommissioned. It says it is working with Anthropic, OpenAI and Google on remediation, that the incident is ongoing and that, so far, it has found no evidence of other data being leaked. Nor can it confirm whether the keys were used maliciously.

There are signs pointing the other way, though unverified: according to the source, some users say they saw charges of “hundreds of dollars” for queries they did not make, even before the first notice. Others claim on X that Google suspended their cloud project or that OpenAI closed their account. These are unconfirmed individual accounts. There is not even agreement on whether the emails went out on the 17th or the 18th.

The terminology is what is most disputed. Distillation means training a model on the outputs of another. A “distillation attack” would, in principle, mean firing massive volumes of queries at a model to copy its behavior, something an attacker could do with stolen keys. But that does not explain how the keys were obtained. Researcher Nathan Lambert publicly asked whether this is distillation to train other models or illegitimate use of illicitly obtained tokens. Both can be true at once, but the company has not confirmed that sequence.

Still unanswered: how many accounts that 1.4% represents, how the attackers got in, when the access was detected, and whether keys stored in local configuration files, rather than in the Console, were also affected.

The recommendation is that of any incident response. Keys should be revoked and regenerated from each provider's dashboard, without clicking links in the email. It is also advisable to review usage since October 17 and set spending limits. For a solo developer or a startup running OpenCode in production, this means touching every pipeline, every continuous integration job and every local machine.

**Our take.** The thesis is simple: a coding agent holding your credentials is only as secure as its vendor's least-maintained system. OpenCode's documentation already warned, according to the source, that it does not sandbox the agent and that its permission prompts are a usability convenience, not a security barrier. But that warning protects against the agent, not against a leak in the vendor's back office. Here the failure was not in the model or in the developer's judgment, but in a system that was still alive while being shut down.

In general, the industry has wired agents into sensitive billing accounts with more haste than hygiene. The short-term consequence is uncomfortable: key rotations, unexpected bills and distrust. It is the price of a fast transition. It fits an idea we have been arguing: the model is getting cheaper and the real risk is moving to the identity and permissions layer. Long-lived keys stored by third parties are the pattern to eradicate, in favor of ephemeral, narrowly scoped credentials with spending caps.

There is also a communications lesson. Calling what, as far as is known, is first and foremost a key exposure a “distillation attack” inverts the order of what matters to the user. Withholding details during an active investigation is reasonable. But a clear follow-up, covering scope, cause and cost to users, would restore more trust than a list of partners.

In the long run, the balance remains optimistic: these frictions push toward more mature agent infrastructure, with verifiable identities and least-privilege permissions. That foundation is what will be needed to delegate real work to AI, not just test tasks.