If you use OpenCode and saved OpenAI or Anthropic keys in its Console, revoke them and create new ones.
On 17 October 2026 OpenCode, the open source coding agent built by Anomaly Innovations, told some of its users about unauthorized access. The company links it to a "large scale distillation attack" that it says hit 1.4% of OpenCode Console users (its post on X, reported by HuggingNews). The Console is the web dashboard for accounts and workspaces, and plenty of people kept their model provider keys in those workspaces.
What happened, as far as we know
The email to users went round Reddit as a screenshot, and The CyberSec Guru reported what it says: someone got into an old system OpenCode was decommissioning, and keys saved in workspaces may have been exposed. According to HuggingNews the company is working with Google, OpenAI and Anthropic and won't say more while the cleanup is under way. It hasn't said when or how the attacker got in, or whether the keys were encrypted. That someone is already using them is plain enough: people on X are posting about charges they never ran up, like this one.
Keys you added from the app with the /connect command live in a file on your own machine (~/.local/share/opencode/auth.json, according to the OpenCode documentation), and this breach doesn't touch them: the app you install isn't involved. As for the Console, we wouldn't put keys back in there until OpenCode explains what happened.
OpenCode hasn't explained the distillation part, so what follows is our own reading. Distilling means training a model on the answers of a stronger one. It's a normal technique, and it becomes an attack when someone quietly floods another company's model with requests to copy what it can do (this is how Anthropic describes it). That takes millions of requests. With someone else's keys they cost nothing, and the traffic comes from real accounts, which providers struggle to tell apart from ordinary customers.
What to do now
- Open the Console and write down which keys you had in your workspaces.
- Revoke them from the dashboard of whoever issued them, and create new ones. Deleting them from the Console isn't enough: the stolen copy keeps working until OpenAI or Anthropic switches it off.
- Put the new keys into the apps that used the old ones, or those apps will stop working.
- Go through the last few days of usage, key by key or project by project. The signs are usually obvious: requests at hours when nobody is working, or on models you've never used. If you find anything that isn't yours, write to the provider straight away with the dates. The account holder pays to begin with, and whether you get a refund depends on the provider's terms.
A spending cap for every key
Whoever holds your key spends in your name until somebody notices, and that's usually when the invoice arrives. On OpenAI, keys live inside projects and each project can have a monthly spend limit. Check how you set it up: requests only stop if you turn on "Enforce a hard limit". Without it, the limit just keeps count. Anthropic works with workspaces: each key sees only one, and each workspace can have a monthly spend limit.
Our advice is one key per use, each in its own project with its own limit. If one gets stolen you lose at most that cap, and odd usage stands out because it isn't mixed in with everything else.
A key also opens whatever the project keeps with the provider, such as files uploaded through the API. If those held customer or employee data, an exposed key can turn into a personal data breach: Article 33 of the GDPR gives you 72 hours to notify the data protection authority, unless a risk to people is unlikely.
The weak spot was a system being shut down
You don't have to build software to have a system that was meant to be switched off and is still running. The old management system stays on "so we can still look up the history", the previous website sits on a server with working database passwords, and nobody patches it or reads its logs.
As long as it holds data or credentials that work, a system needs the same protection as the ones in use. You can stop when it's really off, after deleting or moving what was in it.
How we handle keys, ours and our clients'
We don't use OpenCode. We use OpenRouter, which does a similar job: it sits between us and the model providers, and one key reaches models from several companies. You can hand a middleman like that your provider keys, which OpenRouter says it stores encrypted, or buy credit from it and leave your provider keys in the providers' own dashboards. Either way the OpenRouter key can have its own spending cap, separate from the account balance, and once it hits the cap it stops working. Ours has one. If you use a service like this, check that first.
On client projects we hold no keys at all. When an application we build uses OpenAI or OpenRouter, the account is in the client's company name, the keys are theirs and they buy the credit. If one of our systems were breached their keys wouldn't be in it, and if they decide to work with someone else one day, they don't need to ask us for anything. If a supplier built you an application that uses AI, ask them whose name the account is in. If it's theirs, your keys are sitting somewhere you don't control, just as they were in the OpenCode Console.
The site you're reading uses a direct OpenAI key for one thing only: reading blog comments and deciding whether to publish them or leave them for us to check. It has a spending cap set in the OpenAI dashboard, it stays on the server in an environment variable, and it never reaches the browser. The model gets only the text of the comment, with no name or email. If the key stops working, comments wait in a queue and we approve them by hand, which is why we can revoke it at any moment without first wondering what will break.
How many API keys does your company have floating around, and where are they? If you don't know, get in touch. Our security audit starts there: we list the credentials and the systems still running, and tell you what to shut down first.