1. What happened in the OpenCode Console breach?
Anomaly Innovations, the company behind the open-source AI coding agent OpenCode, disclosed on October 17, 2026 that attackers had gained access to a legacy system connected to its Console product. The intruders reached third-party API keys stored by some users, affecting roughly 1.4% of Console accounts, and the keys involved were tied to OpenAI, Anthropic and Google.
The company wrote to affected customers directly, telling them that provider keys stored in their workspaces may have been exposed. Users who received no such message were not part of the group the company identified. The notice asked recipients to revoke and reissue the keys concerned, and to check recent usage for anything they did not recognize.
The percentage sounds small, and the company has said only a subset of Console users, those who had linked outside AI providers, could have been touched. Even so, the nature of the stolen material makes the incident more serious than the headline figure implies. An API key is not a password to a single website. It is a bearer credential: whoever holds it can spend the owner's money with the issuing provider until the key is cancelled.
The company has described the matter as ongoing and said it is working with Anthropic, OpenAI and Google on the response. It had not published a full post-mortem, a list of indicators or an exact count of affected accounts beyond the 1.4% share at the time of the disclosure.
2. What is OpenCode and what does the Console do?
OpenCode is an open-source coding agent: a tool that lets developers hand programming tasks to large language models from a terminal or editor. It was built by the team behind the SST serverless framework, which now operates as Anomaly Innovations. Because the agent itself is open source, anyone can read and run its code, but the company also offers a hosted Console that sits alongside it.
A hosted console of this kind typically gives users a place to manage workspaces, billing and model access in one spot. Many people who use AI coding tools bring their own provider accounts, which means they paste in keys from OpenAI, Anthropic or Google so the agent can call those models on their behalf. Storing those keys in a workspace is convenient, since the user does not have to supply them on every machine, but it also turns the hosting company into a custodian of valuable credentials.
That custody is the core of this incident. The attackers did not need to compromise OpenAI, Anthropic or Google. By entering one system at the middleman and collecting keys saved there, they obtained working access to those providers under other people's accounts.
3. How did attackers get in through a legacy system?
The company said the entry point was an older system that was already being shut down. That detail is familiar from many security incidents. Retired or semi-retired infrastructure often keeps running during a migration, and it can fall outside the monitoring, patching and access reviews applied to the current production stack.
Such systems are attractive targets because they may hold real data while receiving less attention. A service marked for decommissioning is easy to treat as low risk, yet if it still connects to stored secrets, it carries the same exposure as anything else that does. Decommissioning plans therefore usually pair the shutdown date with an inventory of what data lives on the old system and a firm schedule to remove or migrate it.
The public statements so far do not say how the attackers broke into the legacy system or how long they were inside. Those are the details a post-mortem would normally supply, and customers and other developers will look for them once the company publishes one.
4. What did the attackers do with the stolen keys?
The company characterized the activity as a distillation attack. Distillation means using the outputs of a powerful model to train a cheaper or competing one: an operator sends large volumes of prompts to the model, records the answers, and uses that data as training material. Doing so at scale requires a great deal of paid model usage, and an attacker who pays with stolen keys shifts the entire bill onto someone else.
That is what appears to have happened to some customers. Users reported unexpected charges on their provider accounts, in some cases amounts in the hundreds of dollars. The legitimate owner of each key is the one billed, which is why the advice to affected users centers on cancelling credentials quickly rather than waiting for confirmation of misuse.
The company said it could not confirm in every case whether exposed keys had been used. The practical effect for a user is the same either way: a key that may have been copied by a stranger should be treated as compromised, because there is no way to prove it has not been used for a purpose that has not yet generated a charge.
5. Why do stolen AI keys carry real financial risk?
Frontier model providers bill by usage, typically by the amount of text processed. A key with no spending cap can therefore be driven to a large bill in a short time by automated requests. Unlike a stolen card number, which a bank may flag as unusual, a valid API key issues requests that look like ordinary traffic from a customer, so detection often depends on the account holder noticing a spike in usage or a billing alert.
The risk is also wider than money. Depending on the provider and the way a key is configured, it can be tied to a project that holds uploaded files, saved conversation history or other resources. A person who reuses one key across several tools is exposing everything connected to it every time one of those tools is breached.
This is why security teams treat model keys much like cloud-infrastructure credentials. They are long-lived, they grant spending power, and they are frequently pasted into configuration files, environment variables and third-party dashboards where they are hard to track.
6. How did the model providers respond?
Anthropic and Google revoked the keys that had been compromised, which cut off the attackers' ability to use them. Revocation is the most direct remedy available to a provider: once a key is cancelled, requests made with it fail, and the user can generate a replacement. The company said it was coordinating with OpenAI as well, along with the other two providers, on the wider response.
For affected users, the sequence is straightforward. They need to revoke every key that was stored in the Console, create new keys, update each application or tool that depended on the old ones, and then examine usage logs and billing pages for the period around the disclosure. Anyone who sees charges they cannot explain should raise them with the relevant provider.
Users who did not receive a notification were not identified as affected, although it remains sensible for anyone who ever stored a provider key in the Console to rotate it as a precaution, because rotation costs little compared with a surprise invoice.
7. What should developers do to protect their API keys?
The most effective habit is to use a separate key for every service and every project. When each tool has its own credential, a breach at one vendor exposes only that key, and cancelling it does not break anything else. A single shared key forces a user to hunt down and update every application at once during an emergency.
The second habit is to set hard spending limits on each project. Most providers let account owners cap monthly spend or set alerts at chosen thresholds. A cap converts an open-ended liability into a bounded one: even if a key is stolen, the amount an attacker can run up is limited to the ceiling the owner chose in advance.
Beyond those two steps, developers can review which third-party services hold their keys, remove keys from tools they no longer use, and rotate credentials on a regular schedule instead of only after an incident. Teams should also consider whether a hosted service really needs to store a key at all, or whether the key can stay on the developer's own machine and be supplied only when a task runs.
8. What does the breach mean for AI development tools?
The episode illustrates a structural trait of the current AI tooling ecosystem. Many popular products are thin layers that route requests to a handful of model providers, and they collect credentials from their users to do so. Each of those layers becomes a place where many users' secrets pile up, and an attacker who breaches one can reuse the stolen material against the big providers without ever touching them.
It also shows how an open-source project and a commercial service can differ in exposure. The open-source agent runs on the user's own machine and keeps keys under the user's control, while a hosted Console that stores keys centralizes them. The two have different risk profiles, and users choosing between local convenience and hosted convenience are making a security decision whether or not they frame it that way.
Companies running such services face pressure to retire old systems cleanly, to encrypt stored secrets, and to give customers clear, quick notice when something goes wrong. In this case the disclosure came with direct emails and a recommended action, which are the elements customers generally need most in the first hours.
9. What happens next?
The company has said the incident is still being handled and that it is working with OpenAI, Anthropic and Google. The items to watch are a detailed post-mortem explaining how the legacy system was reached, a firm count of affected accounts, and whether any further misuse is identified.
For customers, the immediate tasks are already clear: rotate provider keys, review usage, and tighten spending limits. For the wider industry, the case adds to the argument that stored model credentials deserve the same care as cloud access keys, with narrow scopes, caps and regular rotation as the baseline rather than the exception.