OpenCode Distillation Attack Reportedly Drains AI API Keys

What Happened

A post on r/artificial alleges that a distillation attack against OpenCode, an open-source coding agent, resulted in the exfiltration of users' stored API keys for Anthropic, OpenAI, and Google models. The claim is community-sourced and has not been independently verified; no vendor advisory, CVE, or incident report corroborates it at the time of writing. Details on the attack vector, affected versions, and the number of compromised credentials remain undisclosed in the original post.

Why It Matters

Coding agents are among the few AI tools that routinely hold long-lived, high-privilege provider credentials on developer machines and in CI environments. A distillation attack against such an agent does not merely degrade model quality — it converts the agent's own credential store into an exfiltration target. For teams running open coding agents against metered provider APIs, the exposure is direct: a drained key represents both immediate financial loss and a potential pivot into billing accounts, usage logs, and any downstream services authenticated through the same secrets. The incident, if confirmed, would establish that open agent tooling carries supply-chain risk comparable to package-manager compromises, and that credential isolation — not model selection — is the binding constraint on safe deployment. The absence of independent verification is itself operationally relevant: teams cannot wait for a vendor statement to audit their own posture.

Technical Details

Distillation attacks in this context typically involve a malicious or compromised model endpoint that issues crafted prompts or tool calls to induce the host agent to emit sensitive context — in this case, environment variables or config files containing provider keys — into model-visible channels. OpenCode's architecture, like most coding agents, resolves provider credentials from local configuration and environment at runtime and passes them to whichever endpoint the session is pointed at; the trust boundary is the endpoint, not the agent. The reported attack surface is therefore the combination of stored credentials plus configurable base URLs, a pattern common across open agent frameworks. No performance numbers, benchmark results, or version-specific patch data have been published. Integration requirements for mitigation are unremarkable — scoped keys, per-session credential injection, and egress controls — but adoption is inconsistent because these measures add friction to local development workflows.

Operational Impact

Operators should treat any stored provider key used with an open coding agent as potentially exposed and rotate accordingly, prioritizing keys with billing exposure over those limited to read-only or low-quota scopes. Day-to-day workflow changes are concrete: replace static keys in shell profiles and .env files with short-lived, scoped tokens issued per session; pin agent versions and endpoint allowlists rather than accepting arbitrary base URLs; and route agent traffic through egress logging so anomalous outbound calls to unfamiliar hosts are visible. For teams, the cost is added setup and key-management overhead; the benefit is that a single compromised agent session no longer implies full provider-account compromise. CI pipelines that inject provider keys into agent steps should be audited first, since they concentrate credentials and run unattended.