OpenCode incident puts AI users' API keys at risk

What this is about

OpenCode has disclosed a security incident involving its hosted Console service. According to multiple reports, attackers conducting a model-distillation attack gained access to credentials that users had linked to external AI providers. The affected credentials reportedly included keys for OpenAI, Anthropic and Google. Reports cite about 1.4% of Console users; that figure comes from the vendor's disclosure and has not been independently verified.

This is more than an ordinary password problem. An API key may let someone run models at the owner's expense, process data through the owner's account or exhaust existing quotas. People who used OpenCode only locally and did not use the affected Console service are not automatically affected based on currently public information.

What the incident actually means

OpenCode is a tool for AI-assisted software development. Users can connect accounts or API keys from different model providers so the tool can send requests to their services. That connection is convenient, but it also concentrates valuable credentials in one place.

A distillation attack normally tries to reproduce a model's behavior through many targeted queries. In this case, OpenCode and security outlets also reported access to linked provider keys. The safe response is therefore not simply to change an OpenCode password. Affected users need to revoke every potentially stored key at the relevant provider and create replacements. They should also review billing, usage logs and unusual model calls during the possible attack window.

Why it matters

In practice, API keys act like both building keys and corporate credit cards. A stolen key can create costs immediately. Dealroom reported that one user claimed losses of $1,700; Cyber Ivy could not independently verify that individual claim. The total financial impact is not publicly known.

The incident highlights a growing risk in developer tools: one service can connect several AI providers, repositories and local workflows. If that hub is compromised, the effects extend beyond the original product. Teams should scope keys to individual projects, set low spending limits and rotate them regularly. Where available, short-lived credentials and separate accounts for production, testing and personal experiments are safer.

In plain language

Imagine a key cabinet in an office. It saves time because every important key is stored in one place. But if the cabinet is forced open, changing only the office-door lock is not enough: every key inside must be treated as unsafe and replaced. Users should handle linked API keys the same way after this incident.

A practical example

A small development team connected three providers to OpenCode Console. Its OpenAI key can spend €500 per month, its Anthropic key €300 and its Google key €200. After the warning, the team revokes all three keys, creates separate replacements and adds alerts at €50, €100 and €200. It then compares provider usage logs with normal working hours. Requests at night or from unfamiliar regions are investigated.

For future work, each project receives its own key with the narrowest necessary permissions. That lets the team disable one key without stopping all development work.

Scope and limits

• It is not yet fully clear which specific keys were actually read and abused. The 1.4% figure describes the reported share of users, not automatically confirmed financial losses.
• Reporting relies heavily on OpenCode's statements and derivative coverage. Cyber Ivy has not seen an independent forensic investigation.
• Revoking keys prevents future use but does not erase costs already incurred or prove that transmitted content remained unread. Affected organizations should check their own incident-response and notification duties.

SEO & GEO keywords

OpenCode, OpenCode Console, API keys, OpenAI API, Anthropic API, Google AI, AI security, credentials, model distillation attack, developer tools, incident response, key rotation