OpenCode: possible exposure of AI suppliers in Console affects 1.4% of users

On the night of October 16 there was an unauthorized access to a system inherited from OpenCode which, according to the company, could have exposed keys from IA suppliers that users kept in their hosted OpenCode Console service. Console is a OpenCode option to centralize the use of third-party APIs: work spaces store the OpenAI, Anthropic or Google key and Console use it to make calls on behalf of the computer, with the intention that members do not see the original key.

Confirmed facts: OpenCode notified the affected users by mail on the morning of October 17 under the "Action Required: Potential provider key break" case and said that the affected group equals 1.4% of Console users; all affected had an external supplier linked. The company indicated that the incident affects OpenCode Console - the service hosted - and not the OpenCode product itself, and specified that those keys "never reach us" in the normal flow. OpenCode described the incident as "related to a large-scale distillation attack" and claimed to be working with Anthropic, OpenAI and Google. He also warned that the intrusion is still developing and that the attackers have continued to try to access their systems.

Confirmed and technical: a supplier key is a bearer. Whoever has a valid copy can issue applications that generate billing consumption against the owner's account until the key is revoked by the supplier. OpenCode has been explicit on two points relevant to mitigation: delete the key from Console does not revoke it on the supplier panel, and the budget set up in Console does not limit the use of a copied key because Console only sees the requests that pass through its own gateway.

What remains uncertain or unconfirmed publicly: OpenCode has not detailed when exactly unauthorized access began, which legacy system was violated, how many specific keys were stored in that system, or whether the filtered keys were copied or used. The company has also not published technical traces (input vectors, exploited vulnerability, access and login) to allow the chain of engagement to be verified.

How this leak could be used and why it matters: in addition to the direct use to generate fraudulent billing, API keys are bought and sold in criminal markets and serve for automatic "distillation" campaigns - massive search campaigns for models to collect outputs and train competitive models. Anthropic has previously warned that these types of campaigns use false account networks, stolen cards and compromised keys to orchestrate mass access. That is why an exposed key not only puts credit and quota at risk, but can fuel abuses on a scale.

There are already public complaints of unauthorized billing attributed by users to keys linked to Console: network messages and forums quote charges in OpenAI, Anthropic and Google accounts for amounts ranging from a few hundred to thousands of dollars. These claims are statements of the affected and, except for external audit, should be considered unverified testimonies; OpenCode at the moment only states that the keys "may have been exposed."

What users should do now (practical and concrete steps): 1) Revocate immediately any key that would have been stored in Console from October 16 onwards. The revocation is done from the supplier panel - it is not enough to remove it in Console. Official vendor instructions: OpenAI (key creation / rotation) https: / / platform.openai.com / account / api-keys, Google (API key management) https: / / cloud / google.com / docs / authentication / api-keys, Anthropic (console key management) https: / / console.anthropic.com / docs / api-keys.

2) Generate new keys and replace them in all applications and scripts using the old one. 3) Review the use and billing history on suppliers' panels to detect unauthorized requests from at least October 16 and report them to the supplier; if there are charges, open billing disputes with the documentation. 4) Set expenditure limits and alerts in each supplier and, where possible, issue keys with minimum or temporary permits instead of long-term keys. 5) Assign separate keys by tool or project to reduce blast radius and facilitate the tracking of abuse.

Additional technical recommendations for equipment: ensure that local keys are not stored in flat text in unencrypted disks or SQLite; use the operating system key manager or managed secrets (secret managers) that issue temporary credentials; audit who has access to Console and apply minimum privilege policies; enable multifactor authentication and regular rotation of credentials; put an internal proxy that applies quotas, logging and filters before sending requests to the supplier.

What can happen if you do not act: fraudulent billing that can lead to account blocking by suspicious activity, exfiltration of keys that nurture large-scale distillation attacks or resale, service interruptions when the supplier sanctions a compromised account. At the reputational level, tools and equipment that depend on shared keys risk exposing data or being paralyzed by the need to force mass rotations.

Context and why this is again relevant: the incident is a reminder that many development workflows adopt operational shortcuts - storing keys in centralized or local services - that create a single failure point. The "distillation" attacks and the abuse of keys have escalated with the economy of LLMs models; suppliers and equipment must adapt traditional safety controls (rotation, segregation of functions, spending limits, detection of anomalies) to the particularities of IA APIs.

Finally, it distinguishes between facts and estimates: it is confirmed that there was access and that OpenCode notified 1.4% of its users of Console; the rest (effective use of keys, actual scope of extraction, total magnitude of fraudulent charges) has not yet been publicly demonstrated. The affected users should act as if their keys had been copied and follow the specific list of steps above to cut the immediate risk and minimize additional damage.