The OpenCode breach and the API keys a tool leaves behind
A developer stops using an AI coding tool. The workspace becomes inactive, a replacement tool takes over, and the old integration drops out of view. The provider API key may still work.
That gap matters when a service holding those keys is breached. Removing the application does not necessarily remove its authority to spend money or access provider resources. The provider, not the application's settings page, decides whether a copied key is still valid.
OpenCode's newly disclosed Console incident puts that distinction into practical terms.
What OpenCode disclosed
On October 17, OpenCode said a security breach affected 1.4% of Console users, specifically a subset with external providers linked. It said it had emailed affected users and was working with Anthropic, OpenAI, and Google. Its statement described the incident as ongoing and related it to a large-scale distillation attack.
The customer notice described unauthorized access to a legacy system being decommissioned and warned that provider keys saved in workspaces may have been exposed. OpenCode advised affected users to revoke and replace those keys and review usage.
The scope matters. This disclosure concerns stored credentials in Console. It does not establish that every OpenCode installation, locally stored key, or connected provider was compromised. Nor does the 1.4% figure tell us how many keys were taken or the total cost of unauthorized usage.
This article reflects the disclosure available on October 18, 2026. The technical entry point and full impact remain unresolved in that account.
Bringing your own key also means choosing its custodian
OpenCode's provider documentation describes a useful arrangement. Console stores a provider credential and routes requests through its gateway. Workspace members can use the models without seeing the underlying key, while the provider bills the customer for usage.
That can reduce the number of people who handle a secret. It also makes the gateway responsible for protecting a credential that works outside the gateway.
Consider two different permissions. A workspace member may be allowed to use a limited selection of models through an application. The application's stored provider key may authorize a broader set of requests. If an attacker obtains that raw key and the provider accepts it directly, the workspace's model restrictions and member permissions no longer sit in the request path.
The question for a security review is therefore specific: which restrictions are enforced by the provider, and which exist only inside the tool?
| Control | What happens if the raw provider key is copied? |
|---|---|
| Removing a workspace member | Stops that member's workspace access, but does not revoke the provider key. |
| Disabling a provider inside a tool | Stops the tool's intended route, not necessarily direct requests to the provider. |
| A gateway-only usage limit | Cannot limit requests that bypass that gateway. |
| Provider-enforced permissions and quotas | Still constrain requests wherever the key is used, within their actual enforcement rules. |
| Revocation at the provider | Invalidates the old credential for new authenticated requests once revocation takes effect. |
These are architectural distinctions, not claims about how the OpenCode attackers operated. They determine whether a stolen key remains useful after the original service is contained.
Distillation describes a possible use, not the break-in
Model distillation uses one model's outputs to train another. Unauthorized access to a paid model API can provide a way to collect those outputs at someone else's expense.
But the attack's purpose and the method of credential theft are separate questions. The phrase "distillation attack" does not explain how a system was accessed, how secrets were protected, or which requests used exposed credentials. It also does not establish that an AI agent carried out the intrusion autonomously.
For an affected customer, the immediate response does not depend on proving the attacker's training objective. A potentially exposed key needs containment. Unrecognized usage needs investigation. Evidence about the entry point can follow without delaying revocation.
The limits of the evidence matter in the other direction too. A stolen inference key does not automatically prove that source code, historical conversations, or every resource in a cloud account was accessed. Investigators need to establish what that credential could authorize, then compare that access with provider records.
A retirement plan needs a credential shutdown step
The reference to a legacy system raises a question that applies well beyond this incident: what access survives a migration?
Teams often track whether a replacement service is working. They may be less precise about whether the old service's credentials still work, who owns them, or whether copies remain in backups and deployment settings.
A system should not count as retired while it retains usable production credentials without an explicit operational reason and owner. Taking down its interface is not sufficient evidence of revocation.
For each integration being retired, record the provider project, the credential identifier, its owner, and where it was used. Do not copy secret values into the inventory. Identify shared dependencies before revoking anything, then invalidate the obsolete credential at its issuer and verify the result. Treat stored copies according to the organization's retention and deletion rules.
This changes the completion criterion for a migration. "No traffic reaches the old service" becomes only one check. "The old credentials can no longer authorize new requests" is another.
What affected teams should do now
Start with the account and workspace identified in the notification. Do not infer exposure solely from having installed the CLI, and do not treat an empty inbox as a substitute for checking the correct workspace owner's messages.
- Revoke the affected keys at their providers. Replacing a value inside a third-party console does not invalidate an attacker's copy. Coordinate replacement with application owners, but do not leave a suspected stolen key active while waiting for a routine maintenance window.
- Replace shared credentials with dedicated ones. Give the affected integration its own credentials and the narrowest supported permissions. Check CI jobs, developer tools, and services that may have reused the old key before declaring recovery complete.
- Review provider-side usage and audit records. Compare request volume, model selection, timestamps, and available client metadata with expected activity. Keep relevant request identifiers and billing exports. Logs from the compromised service alone cannot account for requests made directly to a provider.
- Confirm containment. Verify that the old key is revoked, replacement credentials work only where intended, and unexplained usage has stopped. Escalate suspicious charges or account restrictions through the provider's support process without assuming a refund or a particular outcome.
Preserve evidence in parallel with containment. Do not delay revocation just to complete an export, and do not paste credentials into incident tickets or support chats.
The security boundary has to include provider access
Prompt inspection cannot invalidate a stolen API key. Tool-call approval cannot stop a direct provider request that never passes through the agent runtime. Those controls address different failure modes.
For teams deploying AI tools, credential custody needs its own review. Prefer dedicated provider projects and credentials over a shared organization-wide key. Use short-lived access where the provider and integration support it. Verify whether a spending setting is an alert, a delayed accounting threshold, or an enforced limit before treating it as containment.
Gateways can help keep raw provider keys off developer machines and centralize policy. They also become systems whose compromise deserves a tested response plan. Know who can revoke the upstream credentials, how quickly replacements can be distributed, and where independent usage records are available.
The useful test is concrete: if an AI tool disappeared from your environment today, could you identify and revoke every provider credential it had held? If the answer requires reconstructing months of developer activity, that inventory needs work before the next incident.