OpenCode Console Breach May Have Exposed Axiom, Paradox, and Google API Keys

An intruder reached a legacy OpenCode system on the night of October 16. OpenCode said provider keys saved in its optional Console service may have been exposed. The incident involved Console, not the OpenCode command-line or desktop apps, whose local keys remain in a SQLite database on the user’s machine.

The warned group represented 1.4% of Console users. Every affected user had linked an outside provider, such as Axiom, Paradox, or Google. OpenCode emailed them on October 17 with the subject “Action Required: Potential provider key breach.” The company said users who did not receive that email were not affected.

OpenCode told warned users to revoke the old keys with their providers and create replacements. It also advised reviewing provider usage and billing from at least October 16. OpenCode has not said whether any key was copied or used, when unauthorized access began, or how many users the percentage represents.

OpenCode Console is an optional hosted service for workspaces. A workspace can save its own key from Axiom, Paradox, or Google in Console. This lets team members use those providers’ models without receiving or viewing the underlying credential.

The key mechanism is delegation. Console uses the workspace’s saved provider key when it calls the outside AI provider. The provider then receives the request under that key, while Console serves as the team-facing gateway. The key is not the same as credentials stored locally by OpenCode’s command-line or desktop apps.

That design creates a security boundary. The article says Console-held keys were potentially exposed, while keys added to the command-line and desktop apps stay in a SQLite database on the user’s machine and “never come to us,” according to co-founder Dax Raad. Console budgets also cannot control requests made outside its gateway.

OpenCode said 1.4% of Console users were affected. The company described that group as users who had an outside provider linked to Console. It did not provide the underlying number of people, so the percentage cannot be converted into a user count from the article.

The keys at risk were provider keys pasted into a Console workspace. These could belong to Axiom, Paradox, or Google. Console stored those credentials so it could call the selected provider for workspace members. A key saved in Console therefore had a different exposure path from a key entered directly into an application on a user’s own machine.

OpenCode said its command-line and desktop applications keep locally added provider keys in a SQLite database on that machine. The breach was described as involving “the OpenCode Console, not OpenCode itself.” OpenCode said the Console keys “may have been exposed,” but did not say any were copied or used.

A provider key is a bearer credential. Whoever possesses a copy can present it to the provider and run billable requests against the owner’s account until that provider revokes the key. The attacker does not need Console’s permission for the provider to recognize the credential.

For example, deleting a key from an OpenCode workspace only removes it from that workspace. It does not invalidate the credential at Axiom, Paradox, or Google. A copied key can still be used directly with the provider, so the owner may receive charges for requests they did not make.

A Console budget cannot cap that outside use. Console only sees requests that pass through its own gateway. The article reports claims of $281 in Axiom usage, $168 in Paradox usage, $1,700 in losses, and about $400 in Paradox usage. OpenCode has not confirmed that exposed keys were copied or used.

Model distillation campaigns gather very large numbers of answers from an existing AI model. The answers can help train a rival model. OpenCode described its incident as related to a “large-scale distillation attack,” although it did not explain how the breach and the alleged attack were connected.

Paradox said in September that labs behind such campaigns reached its models through networks of fake accounts. Those accounts were created with stolen credit cards, login credentials, and harvested API keys. A stolen key gives an attacker a way to send provider requests under another account, potentially making the activity harder to connect to the attacker.

Harvested keys also have simpler criminal value. The article says criminal markets resell AI tokens and keys and use them to run up bills. OpenCode has not named anyone, identified the legacy system, or said whether any key was copied or used. Attackers were still trying to enter its systems on October 18.

The first step is to revoke the possibly exposed key in the provider’s own dashboard. The owner should then create a new key using the provider’s instructions. Removing the old key from OpenCode Console is not enough because deletion does not revoke the provider credential.

Next, update every application and script that used the old key. Review usage and billing at the provider, checking for requests the owner did not make from at least October 16. OpenCode has not said when unauthorized access may have begun, so that date is the minimum review point given in its guidance.

Owners should also set a spend limit or alert at the provider. Giving each tool its own key can limit damage from a copied credential and make unusual use easier to trace. The article reports several user claims of unauthorized charges, but OpenCode says only that keys may have been exposed.

An API key is a credential that software sends with a request to a cloud provider. The provider checks whether the key is valid and connects it to an account, workspace, or project. This lets the service recognize the caller without a person signing in interactively for every request.

The key also carries permission to use the provider’s API within the limits attached to that account. When the request succeeds, the provider records the activity against the key’s account and can bill that account for usage. In the OpenCode case, a copied key could therefore produce charges for requests its owner did not make.

This is why a bearer key must be revoked at the provider if exposure is possible. Removing it from Console only stops Console from using its stored copy. It does not tell the provider to reject other copies. Provider-level spend limits, alerts, separate keys, and usage reviews can help detect or reduce misuse.