OpenCode Security Breach Exposed AI Provider Keys, but Local Installations Face a Different Risk

OpenCode disclosed a security breach affecting 1.4% of Console users after attackers accessed a legacy system and potentially obtained linked AI provider keys. Those credentials could authorize billable requests to services from OpenAI, Anthropic, Google, and other model providers.

The OpenCode security breach did not establish that every local OpenCode installation was compromised. The reported exposure centered on OpenCode Console, an optional hosted service that can store provider credentials for shared workspaces. OpenCode’s local application uses a different credential path, according to its documentation and maintainers.

That distinction limits the confirmed scope, but it does not eliminate the operational problem. Security teams still need to find OpenCode installations, identify who used Console, trace linked credentials, and review provider activity. The incident turns an AI coding tool into a credential-management investigation across developer machines, hosted workspaces, and external billing accounts.

What the OpenCode Security Breach Actually Exposed

The central event was unauthorized access to provider keys stored by OpenCode Console, not a confirmed compromise of every OpenCode client.

OpenCode disclosed the incident on October 17, 2026. The company said it had experienced a security breach related to what it called a large-scale distillation attack. It reported that 1.4% of OpenCode Console users were affected and said it notified those users by email.

The company’s customer notification attributed the exposure to unauthorized access involving a legacy system that was being decommissioned. It warned recipients that third-party provider keys saved in their workspaces might have been exposed. The notification told affected customers to revoke those keys, replace them, and review recent usage.

OpenCode Console is a hosted service associated with the open-source coding agent. Its workspace features let administrators connect provider accounts and make approved models available to other members. OpenCode’s Console provider documentation says the service stores the provider credential and inserts it when forwarding requests through its gateway.

That architecture prevents ordinary workspace members from seeing the underlying secret. It also places stored credentials behind a shared service boundary. If that boundary fails, one incident can affect accounts at several upstream providers.

Reports from affected users described unexpected model usage and spending alerts. Some said unauthorized activity appeared across more than one provider account. OpenAI, Anthropic, and Google reportedly worked to block exposed credentials, restore access, or address unauthorized charges.

The available reporting does not provide a verified number of exposed keys. OpenCode has not published the total number of Console users, so the company’s 1.4% figure cannot be converted into a reliable victim count.

The company also has not publicly detailed how the attackers entered the legacy system. It has not explained how the credentials were protected at rest, which controls the attackers bypassed, or whether the intruders accessed other workspace data.

Those gaps matter because the phrase “distillation attack” describes the presumed purpose of the stolen model access, not necessarily the intrusion technique. Model distillation generally involves collecting outputs from one model to train or improve another. Stolen API keys can fund that activity, but they do not explain how the keys were obtained.

The initial disclosure therefore supports a narrower conclusion. Attackers reached a legacy Console system, provider keys may have been exposed, and unauthorized model usage followed. The precise intrusion path and the evidence connecting that access to model distillation remain undisclosed.

Independent reporting also documented an unusual complication during the response. OpenCode co-founder Dax Raad said some frontier models initially helped analyze the incident but later refused requests when malicious material triggered their safety controls.

OpenCode subsequently received access to OpenAI’s Daybreak Blue program, which reportedly gives vetted defenders access to models less likely to refuse legitimate security investigations. That episode adds a second issue to the breach: defenders increasingly depend on AI systems whose safety policies can interrupt incident analysis.

The Console Boundary Changes Who Is at Risk

Organizations must separate confirmed Console exposure from the broader security posture of the local OpenCode agent.

OpenCode can run locally and connect directly to model providers. Its documentation says credentials added through the legacy local /connect flow were stored in ~/.local/share/opencode/auth.json. Newer OpenCode V2 installations store saved credentials in a local SQLite database, usually under the same OpenCode data directory.

Those local credentials follow a different path from provider secrets saved in a Console workspace. OpenCode maintainer Dax Raad said the breach involved OpenCode Console rather than OpenCode itself. He also said keys configured directly in the application did not reach the company.

That statement is important, but it should not end an enterprise investigation. Asset inventories rarely distinguish a command-line tool from its optional cloud account. Developers may use a local agent, sign into Console, join multiple workspaces, and connect different provider accounts over time.

A machine can therefore contain OpenCode without being affected by the reported breach. Conversely, a developer might have used Console from a browser or another machine that no longer contains the executable. Searching endpoints alone will not produce a complete victim list.

The correct unit of investigation is the relationship among four records: the developer identity, the local OpenCode installation, the Console workspace, and the provider credential. Security teams need to reconcile all four.

This creates immediate pressure for engineering organizations with decentralized tool adoption. An employee may have connected a personal provider key, a team credential, or a project-specific service account. Each choice produces a different blast radius.

A personal key can create direct charges and expose the employee’s provider account. A shared team key can affect several applications. A broadly privileged cloud credential can create consequences beyond model usage if it belongs to a larger cloud project.

The same distinction applies to source code and conversation data. Current public reporting supports potential exposure of stored provider credentials. It does not establish that every repository, prompt, local file, or OpenCode conversation was accessed.

Investigators should avoid turning uncertainty into assurance, however. Until OpenCode publishes a detailed post-incident report, affected organizations should ask whether the legacy system contained request records, account metadata, workspace membership, or other information useful to an attacker.

OpenCode’s own security documentation also states that its local agent is not sandboxed. The permission system helps users see and approve actions, but it does not provide security isolation. OpenCode recommends a container or virtual machine when true isolation is required.

That threat model is separate from the Console incident. Still, it explains why finding installations matters. An agent that can execute shell commands, modify files, and reach the web deserves deliberate governance even when there is no evidence that its endpoint was breached.

Organizations should treat the Console exposure as an urgent credential incident. They should treat discovered local agents as a broader endpoint and development-security question. Combining those conclusions into one claim would either overstate the breach or understate the agent’s normal privileges.

How to Find OpenCode on Developer Machines

A useful discovery process combines executable searches, process evidence, local data paths, package records, and identity information.

Start by asking developers whether they used OpenCode Console or received an incident email. That inquiry is faster than a blind endpoint scan and directly addresses the confirmed exposure group. Preserve the email and record every named workspace and credential before changing anything.

Identity teams should search single sign-on logs, browser access records, DNS telemetry, secure web gateway events, and expense records for OpenCode domains. These sources can identify former users and browser-only access that endpoint package inventories miss.

On macOS and Linux, defenders can check whether the executable is available in the current shell:

The first two commands locate executable paths known to the shell. The version command can confirm that a discovered binary runs, but teams should avoid executing an untrusted file during forensic collection. Hash or quarantine a suspicious binary instead.

Active processes provide another signal:

Process searches only show software running at collection time. They cannot prove that OpenCode was never installed, and an executable may have been renamed.

Package managers can supply historical or current installation evidence. On developer systems, review Homebrew formulas and casks, globally installed JavaScript packages, shell installation records, managed application catalogs, and software inventory from endpoint-management tools.

Teams should search explicitly for an opencode executable rather than assuming a single package name. Packaging and installation methods can change, while similarly named projects can generate false positives.

OpenCode data directories provide stronger evidence than an executable alone. For legacy local installations, inspect the documented path:

Do not print credential-file contents into terminal logs, tickets, or chat systems. A simple directory listing can establish presence without exposing secrets.

OpenCode V2 can report its database location through its debugging commands. Its provider documentation says the usual local database path is ~/.local/share/opencode/opencode.db, although environment settings and release channels can change it.

On Windows, defenders can look for the executable and active processes with built-in commands:

User profiles, package-manager inventories, Windows application-control logs, and endpoint detection telemetry can reveal additional installations. Search each profile rather than checking only the account running the scan.

Containerized development environments require separate coverage. Search approved development images, Dev Container configurations, Docker histories, remote workspaces, and ephemeral CI environments. A scan of employee laptops will miss an agent installed only inside a container or cloud development host.

Repository searches can find OpenCode configuration files, policy references, or setup scripts. They should not indiscriminately collect source code or secrets. Restrict the search to known configuration names and installation commands, then validate each result with the repository owner.

Shell histories may also contain installation or invocation evidence. These records are sensitive because they can include tokens and private commands. Collect them only under the organization’s incident-response and privacy procedures.

Detection should answer more than whether a binary exists. For each confirmed installation, record the user, device, version, installation method, last observed execution, local data location, Console sign-in status, workspace membership, and connected providers.

The most important question is whether the user saved a provider credential in an affected Console workspace. A local installation with only local credentials falls outside the breach scope described so far. A Console user may require immediate rotation even if no OpenCode executable remains on the current device.

OpenCode’s regular local provider flow supports many services. Its local provider guide documents direct credentials and environment-based cloud authentication. That variety means discovery scripts must look for relationships, not copy every possible secret into a central report.

Environment variables deserve special handling. Their names can indicate which providers were available to a process, but their values are secrets. Detection systems should record that a variable existed without capturing its full contents.

Endpoint teams should also search for unauthenticated OpenCode server mode. According to the project’s threat model, server mode is optional and should use OPENCODE_SERVER_PASSWORD for HTTP Basic Authentication. An exposed local or remote server represents a separate risk that requires containment, even though it is not the reported cause of the Console breach.

For organizations without reliable software inventory, this event is a reason to build one. AI coding agents are executable development tools with network access and credential relationships. They should appear in the same asset controls used for IDE extensions, package managers, build tools, and remote administration software.

A searchable technical-document system can help teams preserve installation records, response decisions, and ownership without scattering them across private messages. The same principle applies to an engineering knowledge base: evidence is useful only when responders can retrieve and connect it.

Response Starts With Provider-Side Containment

Revoking an exposed credential at its issuing provider is more reliable than deleting it from the application that stored it.

First, preserve the notification and identify every credential named by OpenCode. Record its provider, workspace, owner, project, permissions, creation date, and known dependent services. Never paste the complete secret into the incident record.

Second, revoke each affected key in the provider’s own console. Removing a credential from OpenCode does not invalidate a copy already held by an attacker. Provider-side revocation closes the authorization path.

Third, create replacement credentials only after confirming the old ones are disabled. Use separate keys for separate projects, environments, and tools. Avoid replacing one shared secret with another broadly shared secret.

Fourth, update legitimate applications that depended on the revoked key. Coordinate this step with service owners because rapid rotation can interrupt development environments, scheduled jobs, testing systems, and production workloads.

Fifth, review provider usage from the earliest plausible exposure time. Reports place potential exposure as early as October 17, 2026, at 00:30 UTC. A cautious investigation should include an earlier buffer and continue through confirmed revocation.

Look for unfamiliar models, sudden token spikes, unusual request timing, new source networks, unexpected regions, and projects reaching budget limits. Compare those events with development activity, CI jobs, and known automated workloads.

Sixth, inspect billing and security alerts. Unauthorized model requests can appear first as a spending anomaly rather than a login alert because an API key does not require an interactive account session.

Seventh, contact the provider through its official support or security channel. Ask it to preserve relevant request metadata, identify abusive usage, restore incorrectly suspended projects, and explain the reimbursement process.

Eighth, remove obsolete credentials and provider connections from every Console workspace. Do not reconnect replacement secrets until OpenCode supplies enough technical information for the organization’s risk owner to approve that decision.

Ninth, reduce the value of any future stolen key. Use provider-side budgets, rate limits, project separation, minimal permissions, expiration, network restrictions, or service identities where supported.

Budget controls are not a security boundary. They can limit financial loss and accelerate detection, but an attacker may still consume sensitive model capacity or trigger account enforcement before the budget is exhausted.

Tenth, inspect local machines without assuming they caused the exposure. Review OpenCode data paths, versions, active processes, configuration, and server-mode settings. Preserve suspicious artifacts before uninstalling software.

If local credentials were never stored in Console, rotate them based on evidence and organizational policy rather than an unsupported claim that all OpenCode secrets leaked. Rotation is inexpensive for an isolated development key, but careless mass rotation can create outages and obscure the incident timeline.

Eleventh, identify downstream secrets available to the local agent. OpenCode can access shell tools and project files with user approval. A compromised provider key does not automatically expose repository tokens, cloud credentials, or signing keys, but those assets deserve review if endpoint evidence shows malicious commands or unauthorized access.

Twelfth, monitor the replacement credentials. New keys should receive tighter alerts than the old ones. Investigators need to know whether suspicious requests stop after rotation or reappear through another access path.

Thirteenth, document the decision about continued Console use. The record should name the accountable risk owner, the evidence reviewed, the remaining unknowns, and the controls required before credentials can be stored there again.

Finally, keep the investigation open until provider activity, billing records, identity logs, and endpoint findings agree. A clean laptop scan cannot clear a Console credential. A revoked key cannot clear an exposed local server. Each layer answers a different question.

The Distillation Label Is Still the Weakest Part of the Story

OpenCode has linked the incident to large-scale model distillation, but the public evidence does not yet establish that motive or mechanism.

A distillation campaign can use one model’s outputs to train or refine another model. At scale, that process requires many requests and can generate substantial provider charges. Stolen API keys would give an attacker access to paid inference without using its own billing account.

That explanation is plausible, but plausibility is not attribution. OpenCode has not released request samples, traffic patterns, model targets, attacker infrastructure, or other indicators showing that the unauthorized usage fed a training pipeline.

The phrase can also blur two separate actions. Unauthorized access to a legacy system is the breach. High-volume queries using stolen credentials are the abuse. Distillation is one possible purpose for that abuse.

Security teams do not need to resolve the attacker’s ultimate goal before acting. The response remains the same for credential theft used for distillation, spam, benchmarking, resale, or other unauthorized inference.

The label matters for accountability, however. Calling an event a distillation attack can shift attention toward model competition and geopolitical access restrictions. Calling it a credential breach directs attention toward storage, segmentation, monitoring, and retirement of legacy systems.

Both subjects deserve investigation, but only one has been clearly established. The documented incident involves unauthorized legacy-system access and exposed bearer credentials. The claimed distillation connection remains a company characterization awaiting supporting evidence.

The incident also exposed a conflict in AI-assisted defense. OpenCode’s team reportedly used AI agents continuously while attackers kept probing its systems. Some models later refused to analyze malicious content because the requests resembled prohibited offensive activity.

A similar problem surfaced in an earlier incident involving Hugging Face. Defenders argued that model guardrails could not reliably distinguish incident responders from attackers analyzing the same exploit material. The response often becomes a switch to locally controlled or specially approved models.

That tradeoff does not mean unrestricted models are automatically safer. A model with fewer refusals can help an authorized responder, but it can also assist an attacker. Access controls, audit trails, isolated analysis environments, and verified responder programs remain necessary.

The breach therefore places two promises against operational reality. Hosted AI gateways promise simpler access to many providers, but they can centralize valuable credentials. Guardrailed models promise safer behavior, but those controls can interrupt legitimate incident response.

Neither problem has a single product-level fix. Organizations need architecture that assumes a gateway can fail and response procedures that do not depend on one model agreeing to analyze hostile code.

OpenCode’s public threat model is useful context. The agent can execute commands and access files, while its permission prompts are not a sandbox. That design gives developers flexibility, but it also makes identity, endpoint isolation, and credential scope central security controls.

The breach should not be used to claim that open-source agents are inherently unsafe or that proprietary tools are inherently secure. The central issue is where credentials live, who can use them, how activity is monitored, and what happens when a trusted service is compromised.

A technical postmortem would allow stronger conclusions. It should explain the initial access vector, affected system, credential protection, exposure window, detection method, attacker actions, containment timeline, and evidence behind the distillation assessment.

Until then, buyers should evaluate the incident with a clear evidence hierarchy. OpenCode’s 1.4% scope figure is a company statement. User reports support real unauthorized usage. The Console architecture explains why stored provider credentials mattered. The attacker’s identity and exact objective remain unresolved.

Three Signals Will Show Whether the Response Is Working

The next test is whether OpenCode and the affected providers replace an urgent disclosure with verifiable evidence and durable controls.

The first signal is a detailed OpenCode post-incident report. It should explain how the legacy system remained reachable, how credentials were stored, which controls failed, and why the company believes the campaign involved distillation.

A complete report would strengthen confidence that the exposure is understood and bounded. Continued reliance on the 1.4% figure without a denominator, root cause, or credential count would weaken that confidence.

The second signal is provider-side resolution. OpenAI, Anthropic, Google, and other affected services should be able to identify unauthorized requests, complete appropriate reimbursements, restore wrongly suspended projects, and help customers verify that revoked keys no longer work.

That process will show whether model providers can coordinate around cross-platform credential incidents. It will also reveal whether current fraud controls detect stolen AI keys before large volumes of billable requests accumulate.

The third signal is architectural change inside OpenCode Console. Users should watch for shorter-lived credentials, stronger separation of provider connections, improved audit logs, stricter legacy-system retirement, and clearer alerts when a key behaves abnormally.

Those controls would reduce reliance on a single stored bearer secret. If replacement keys return to substantially the same architecture, the immediate incident may close while the underlying concentration risk remains.

The OpenCode security breach is not evidence that every developer machine running OpenCode was penetrated. It is evidence that an optional hosted layer can turn linked provider accounts into a shared incident surface.

Security teams should act on that narrower finding with precision. Find the installations, identify the Console relationships, revoke affected credentials at their source, and verify activity with each provider.

Then ask a harder question: does your organization know which AI agents can execute code, where their credentials live, and who owns the response when one of those trust boundaries fails?