API keys used to access paid AI models, including those from OpenAI and Anthropic, may have been exposed in a security breach involving OpenCode. Compromised credentials could allow unauthorized activity on accounts outside the coding platform itself.
On Oct. 17, OpenCode identified 1.4% of its hosted Console users as affected. Accounts in that group had connected external AI providers, and the company notified the customers involved by email.
For developers and security teams, the distinction matters. A compromised API key could be used to make unauthorized requests directly to an AI provider, potentially generating charges or exposing access beyond the coding platform.
A legacy system held provider credentials
A breach notification shared by a recipient identified unauthorized access to a legacy system OpenCode was decommissioning. Third-party API keys stored in customer workspaces may have been exposed.
Console's provider documentation explains how administrators save credentials in shared workspaces so colleagues can access connected AI models without handling the keys themselves. Requests pass through a hosted gateway that also supports external tools.
Co-founder Dax Raad clarified that keys configured in the locally installed application never reach company servers, distinguishing the affected service from the broader AI development toolchain.
A follow-up notification identified stored credentials by workspace, provider, and their final four characters. It set the earliest possible exposure of the listed keys at Oct. 17, 00:30 UTC, and said no other data appeared to have been compromised at that point.
OpenCode linked the incident to what it described as a large-scale AI model distillation attack, a technique involving the collection of model outputs to train another system.
Co-founder Dax Raad also reported continued attempts against the company's systems over the preceding 48 hours. However, OpenCode has not publicly explained how attackers accessed the legacy environment or established whether the subsequent activity was connected to the initial intrusion.
Unauthorized API charges prompt key revocations and refunds
Reports of unexpected AI bills emerged on X after the breach, as well as updates from providers on key revocations and refunds.
Developer Colin Parsons described $281 in OpenAI usage and $168 in Anthropic charges on credentials he said were used only with the coding service. A copied API key can authorize requests outside the platform where it was stored.
To prevent further misuse, Anthropic revoked Claude API keys believed to be affected, according to Lydia Hallie. Google also blocked exposed Gemini credentials, with Evan Otero advising users to generate replacements through AI Studio and examine their account activity.
Reimbursements were another part of the response. Raad said that refunds were underway. On Oct. 19, OpenAI's Thibault Sottiaux announced that affected API customers would receive refunds for credits consumed during the attack.
Teams should review third-party AI credentials
Security teams overseeing developer access should account for AI provider keys stored in external coding services, including connections established by employees outside centrally managed systems. Existing secret scanning can detect credentials accidentally committed to source code, but may overlook ones deliberately saved in hosted dashboards.
Organizations using OpenCode Console should take the following steps to assess potential exposure and protect their provider accounts.
- Identify affected connections and review usage. Determine which employees linked company-paid AI accounts to Console and record the credentials involved. Examine provider activity and billing records for unexplained requests, retaining evidence needed to dispute charges.
- Revoke and replace exposed credentials. Rotate any key identified as potentially compromised, even if no suspicious charges have appeared. Invalidate it directly through the AI provider, since removing it from OpenCode will not necessarily revoke the credential. Coordinate replacement with owners of build jobs and internal services to avoid disrupting legitimate work.
- Strengthen controls over external integrations. Assign separate credentials to individual applications where supported, use API monitoring to detect suspicious requests, and configure available spending limits at the provider level. Separating credentials also allows teams to disconnect an affected integration without interrupting unrelated services.
Security and procurement teams should also ask vendors how stored credentials are handled when older systems are retired and how customers are notified when those systems are compromised.
The broader lesson is that stopping use of a service does not necessarily invalidate the credentials left behind. An API key can remain active long after developers have moved on.
More cybersecurity news: The ConnectWise breach puts third-party application permissions under scrutiny after attackers used trusted cloud integrations to access customer environments.