OpenCode Data Breach: Agentic Architecture, API Keys and Distillation

01What the breach report actually establishes

On 17 October 2026, OpenCode said a security breach associated with what it called a “large scale distillation attack” affected 1.4% of OpenCode Console users. It said those users had external model providers connected and had been emailed. The public statement does not identify the entry point, the number of exposed keys, a confirmed extraction mechanism or how the distillation activity relates to the breach. Read OpenCode’s statement.

Reporting on the customer notification says an unauthorized party accessed a legacy Console system being retired and that provider keys stored in affected workspaces may have been exposed. That wording supports urgent rotation; it does not prove that every key was copied or used. Cyera’s incident summary and the notification analysis describe the same scope.

02What OpenCode is, and why “agentic” matters

OpenCode is an open-source coding assistant available through terminal, desktop and IDE experiences. A coding agent accepts a goal, asks a model to propose next steps, supplies context, and may call tools to read files, edit code, run commands or query services. The model’s text is a proposal; an operation occurs only when OpenCode’s runtime passes that proposal through its permission and execution path. OpenCode documents built-in agents, tools and per-tool permissions. Agent documentation · tool documentation.

“Agentic” describes that iterative decide–tool–observe loop. It does not mean the model has its own operating-system identity or that it autonomously bypasses authorization. The relevant security questions are which tool is reachable, which process executes it, whose credentials it carries and what policy checked the call.

Does OpenCode use MCP?

Yes, it supports MCP, but an MCP server is optional. OpenCode can register local or remote MCP servers and expose their tools beside built-in tools. A particular installation uses MCP only if its configuration enables a server or a hosted integration supplies one. The current Console credential incident has not been attributed to MCP. OpenCode MCP documentation describes the transports and tool configuration.

MCP expands the trust boundary: a tool server can supply tool descriptions and accept structured arguments, while the executing service has its own identity and permissions. An agent policy such as ask for a matching MCP tool is a useful control, but the server must still authorize the caller and protect downstream credentials. Do not infer that a prompt, tool description or model output has authority simply because it appears in an agent trace.

03OpenCode’s layered architecture and credential boundaries

The diagram below combines documented product interfaces. It is an architectural model for investigation, not a reconstruction of the undisclosed legacy system. Select a layer to read its trust boundary. The two credential routes remain separate.

Two different places to keep provider credentials

OpenCode’s documented local /connect flow stores provider credentials in a local application data file for the client release described in its provider guide. The Console’s provider guide describes a separate hosted path: workspace administrators connect providers, Console retains credentials and a gateway forwards member requests without revealing raw provider keys to members. Version, deployment and integration determine which path applies.

The trust boundary shifts when a provider key enters hosted infrastructure. A compromised endpoint may threaten local credentials; unauthorized access to a Console component may threaten keys reachable there. The public record does not show where the legacy system sat in the current gateway topology, what it could read, or how it was entered. Console’s Providers API documentation explains gateway substitution of workspace credentials for requests.

04Protocol and context boundaries: where agentic risk actually lives

The diagram separates four documented or optional routes. It is a review model, not OpenCode’s undisclosed Console incident topology. The local coding agent, optional MCP services, repository context and hosted provider credentials have different owners and controls. A weakness in one route does not prove compromise of another.

MCP lifecycle and session semantics evolve by protocol version; do not assume a legacy initialize handshake or session header exists in every deployment. Pin and inspect the negotiated version. See the official specification changelog and OpenCode’s MCP configuration guide.

MCP is an optional extension, not the reported breach vector

• Tool discovery: a server supplies tool names and descriptions to the client/model. Treat those descriptions and results as lower-trust content; verify server identity and provenance.
• Tool call: OpenCode’s permission configuration governs its own tool invocation. The MCP server still needs independent authentication and authorization for the requested resource and tenant.
• Remote delegation: check issuer, audience, expiry, scope, consent, session owner and whether downstream credentials are reused. A bearer token in configuration is not a substitute for least privilege.
• Local subprocess: the configured command inherits a process environment and host access. Pin the server package, review its command and environment, and avoid unrestricted shell or credential mounts.

Incident boundary: no public evidence cited here attributes the Console key exposure to MCP, a tool description, local server access or an agent prompt. These are architectural review questions, not facts about the breach.

Retrieval and RAG: separate context integrity from access control

OpenCode can use file-reading and search tools to place repository or external content into model context. That is retrieval; it does not establish that every OpenCode installation runs a conventional vector-database RAG pipeline. If a team adds documentation search, memory or a third-party retrieval MCP server, the extra data store and its tenant filters become separate security boundaries.

• Test ingestion: who can write or replace a document, and is source/version provenance preserved?
• Test retrieval: can a lower-privilege session obtain another tenant’s file or stale memory item?
• Test instruction boundary: does retrieved text alter tool arguments or approval decisions beyond the user’s task?
• Test impact separately: did an authorized executor perform the proposed action, and under which identity?

05Reconstruct the incident without filling in missing edges

1. 16–17 OctoberOpenCode described a breach on the previous night. No public start minute or initial access technique was supplied.
2. 17 OctoberOpenCode notified affected Console users and described the affected group as 1.4% of Console users with external providers.
3. Customer noticeResearchers report warning language about unauthorized access to a legacy system and provider keys that may have been exposed.
4. 18 October reviewKey extraction, misuse, attacker identity, persistence and the technical link to distillation remain publicly unresolved.

This is a credential exposure incident for responders even while forensic details are incomplete. A copied provider key can remain valid after a Console password change or after removing a connection from a workspace. Revocation must occur at the provider that accepts the key. Conversely, provider usage spikes alone cannot prove that this incident caused them; correlate the key identifier, project, time, known workload and billing record.

The Console percentage does not translate into a number of installations, organizations, keys or dollars. Reported individual charges are leads for investigation, not aggregate impact. OpenCode’s local CLI, Console gateway, optional MCP servers and the legacy system are different components; do not collapse them into one compromised “agent.”

06Distillation attacks: the model, the credential and the data

Knowledge distillation normally trains a smaller “student” model to imitate a stronger “teacher” model’s responses. It is a legitimate technique when the operator has the rights to use the teacher and its output. An unauthorized extraction campaign instead collects a large response corpus from a model service and trains or evaluates another model against it. This is behavioral replication, not necessarily theft of model weights, source code or the teacher’s training data. NIST’s model-extraction taxonomy and Anthropic’s first-party analysis describe the distinction.

Why a provider key matters

A provider API key is an authorization credential for a separate service. If copied, it may let a third party make billable requests within its scope without controlling the original developer’s OpenCode session. The key’s permissions, project boundaries, quotas and provider records determine the actual consequences. Console’s own budget applies to traffic mediated by Console; direct calls with a copied provider key can fall outside that budget. Cyera explains the response consequence.

How to distinguish extraction from heavy legitimate usage

Look for coordinated request patterns across accounts or keys, repeated task families and variations, unusually high output collection, shifts in model mix, unfamiliar client or network context, and divergence from a known workload baseline. Preserve raw provider records under privacy controls and compare them with authorized batch jobs or evaluations. None of these signals by itself proves model training. Training artifacts, actor infrastructure or corroborating provider intelligence would raise confidence. Anthropic’s October 2026 research discusses account and behavior based detection, along with false positive tradeoffs.

OpenCode has not published a technical mapping from its reported legacy-system access to a particular key, provider request or student training job. The page therefore treats distillation as the vendor’s incident characterization, not a fully demonstrated chain for this case.

07Attack path intelligence: inspect every claimed relationship

Use the controls to inspect three related but differently supported paths. A documented edge describes a product feature; a reported edge relies on the incident notice; an inferred edge is a testable hypothesis. “Disproven” requires evidence that the particular candidate path did not occur, not merely a lack of logs. Compare all paths to see why the incident should not be flattened into a single arrow.

For a defensible incident graph, preserve the source and time of each edge: workspace → stored provider connection; legacy system → ability to read a specific secret; that key → provider requests; those responses → a corpus. The first edge is documented product design. Public evidence for the remaining edges is incomplete. Absence of evidence may reflect missing telemetry, so attach a coverage assessment before marking an edge disproven.

08Detect misuse across the Console and provider boundary

Correlate provider billing with the Console workspace and each legitimate consumer of the same credential. If a key is shared with CI or an internal service, record those consumers before rotation so outages and misleading anomalies can be explained. Console request logs describe traffic through its gateway; provider-side usage is needed to evaluate direct use of a copied key. Neither view necessarily contains the actor’s intent.

09Rotate exposed keys and close the credential path

1. Identify: use the exact OpenCode notice and Console workspace inventory to enumerate linked providers and key owners. Do not paste keys into tickets or scanners.
2. Revoke at each provider: disable potentially exposed keys in official provider dashboards or supported APIs. Removing the Console connection alone may leave a copied key valid.
3. Replace consumers: create narrowly scoped keys or short-lived credentials where supported, update authorized CLI, CI, gateway and service consumers, and verify the retired key fails.
4. Review activity: preserve provider usage and billing around the suspected window; compare with known workloads, and escalate unexplained requests to the provider and OpenCode.
5. Review Console access: reset Console account credentials or sessions where indicated by the notice, inspect provider connections and access policies, and remove unused linked providers.
6. Retire legacy storage deliberately: inventory credentials in backups, caches, logs and replicas; revoke any key whose copies cannot be accounted for.

Key rotation addresses the credential risk. It does not establish how the legacy system was entered or whether a model extraction operation occurred. A later incident report should update the edge labels in the attack-path diagram, not quietly rewrite an unknown into a proven fact.

Incident review checklist

The checklist is a local reading aid. It does not verify your provider keys or access the Console. This article was reviewed on 18 October 2026 against the cited statement, vendor documentation and incident reporting.

Related K8SEC research: Anatomy of a Modern Agentic Attack and Hermes agent trust boundaries.