
OpenCode Breach Exposed Provider Keys—Deleting Them Is Not Revocation

OpenCode disclosed on October 17 that a breach affected 1.4% of its hosted Console users, and one user reported more than $1,700 in unauthorized API charges. The affected group had external AI providers linked, and keys saved in Console may have been exposed. To stop a copied key from authorizing further requests, an affected user must revoke it at the provider that issued it; removing the Console connection does not invalidate the credential.
Attackers entered an older OpenCode system overnight, and co-founder Dax Raad drew a boundary around the incident in TechCrunch’s account: keys held by local installations “never come to us.” Anthropic and Google blocked keys they believed were exposed, while OpenAI worked with OpenCode to restore access and refund API credits used in the attack. Those provider responses do not establish the status of every individual key or bill.
Which OpenCode users were affected

The reported percentage applies to users of OpenCode Console, the hosted service, rather than everyone running the OpenCode coding agent. The affected subset had connected an outside provider in Console. OpenCode emailed the users it identified; for a team, the relevant inventory is the provider credentials saved in its Console workspaces, including credentials shared with other applications.
That scope matters because a credential can have several legitimate uses. A key stored in Console might also authenticate a production application, a scheduled job or another development tool. Revoking that key at its issuer will end all uses of the old value, so each dependent workload needs a replacement. A provider key entered only into a local desktop or command-line installation was described as outside the affected hosted system.
The exposure warning concerns provider keys, not a confirmed count of copied credentials. Reports of unauthorized charges show why affected accounts need a billing review, but an individual user’s reported loss is not a total for the incident. OpenCode has not published a complete account of how the older system was entered or the full extent of misuse.
Why removing a Console connection cannot revoke a key
OpenCode’s Console provider documentation says that Remove deletes a provider and its models from a workspace, while the outside provider bills for tokens used with its credential. Console stores the credential and sends requests through its gateway. Removing the connection ends that workspace’s use of it; the issuing provider controls whether the credential remains valid.
An API key is a bearer credential: a valid copy can authenticate requests wherever the provider accepts it. Deleting one stored value in Console cannot erase a copy already obtained elsewhere. Even entering a new key into Console leaves the old one usable until the provider disables or revokes it. This is the practical reason rotation has two parts: end the old key’s authority at its issuer, then install a new key wherever authorized work must continue.
The billing boundary follows the same path. Console records requests that pass through its gateway, but a copied key used directly against a provider would create usage in that provider account. An empty Console usage view cannot settle whether the provider has billed for direct requests.
What to check at OpenAI, Anthropic and Google

For each credential saved in an affected Console workspace, identify the issuing account and the applications that depend on the key. Revoke the old credential in that account, create a replacement for continuing use and update those applications. Then confirm the old value is disabled and review the provider’s usage and billing records for unfamiliar requests.
- OpenAI: Find the affected key in the organization or project that issued it and revoke it there. Replace it in every application or script that still needs access. Review API usage and credits, and compare any unfamiliar activity with the account’s refund or restored-access notice.
- Anthropic: Disable or delete the affected API key in the issuing Claude Console account, then update workloads that used it. Check usage and costs for requests the team did not initiate. If the provider has already blocked the key, verify its status in the account before treating rotation as complete.
- Google: Identify the Google credential saved in Console and the project or account that issued it. Revoke or disable that credential on the relevant issuing resource, replace it in dependent workloads, and inspect usage, billing and any project suspension notice. The required action depends on the credential type; a Google AI API key and a Vertex AI service account credential are managed differently.
Keeping a list of dependent applications prevents a revoked shared key from becoming an avoidable outage. It also makes the final check unambiguous: legitimate requests should use the replacement, while the exposed old value should no longer authenticate. Re-enabling the old key to restore a failing job would restore the same risk.
Charges and spending controls after rotation
Review billing with each issuing provider, including requests made outside Console. Compare unfamiliar activity with application logs, retain the relevant usage records and raise disputed charges through the provider’s support channel. The reported blocking and refund work is a response to the incident; the outcome for a particular customer depends on that customer’s key status and account records.
Provider-side spending controls can limit a later incident, but their behavior must be checked in the provider account. An alert warns about spending; it does not necessarily stop requests. Use an enforceable limit where one is available and suitable, and consider separate credentials for separate applications so one key can be retired without interrupting unrelated work. A Console budget applies to traffic through Console’s gateway, while the provider’s controls govern direct use of its credential.
Revocation stops new requests made with the old key. Charges incurred before revocation remain a billing matter, making the provider’s final usage record and refund decision the consequential next results for each affected account.
Also read:
Related articles


Supabase vs Firebase: Predictable Bundle or Pay-as-You-Go Scale?

GitHub Actions vs GitLab CI: Cheap Minutes Can Lose to Seat Pricing

Mercury 3 Claims 1,068 Tokens per Second—Independent Tests Find Trade-offs

Sentry vs Datadog: Error Volume or Host Count Decides the Bill

Replit Makes OpenAI Its Preferred Partner—but Claude Remains Selectable
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.