OpenCode를 썼다면 API 키부터 확인해야 할까? 침해 범위와 대응법

If you only installed the open-source OpenCode command-line tool, the available evidence does not show that every local installation was breached. The incident disclosed by OpenCode concerns its Console service. The company says about 1.4% of Console users were affected and that some externally connected AI-provider API keys may have been exposed. It also says affected users were notified by email.

That distinction is the first thing to get right. “OpenCode was hacked” is too broad to be useful. A developer who ran only the local CLI has a different risk profile from someone who created a Console account and saved a provider key there. But anyone who connected a billable key should still treat uncertainty as a reason to check, not as proof that nothing happened.

What is confirmed—and what is not

The official notice confirms a breach involving the Console service, a limited share of its users, and potential exposure of third-party provider credentials. OpenCode connected the event to a large-scale model-distillation attack and said it contacted affected accounts.

The missing detail matters just as much. There is not yet a full public postmortem explaining the initial entry point, how an attack associated with model extraction reached stored credentials, how long access persisted, or which controls failed. Without that timeline, outsiders cannot independently determine the complete blast radius.

An email from the company is useful evidence that an account was affected. The absence of an email is not an immutable security guarantee. Messages can be delayed, filtered, sent to an old address, or based on an investigation that later expands. The practical response should therefore depend on whether a key was stored and what that key could spend.

Who should act now

The highest-priority group is anyone who used OpenCode Console and connected an external API key for a model provider. That includes keys with broad access, no spending cap, long expiration, or permission to use expensive models. Shared team keys deserve special attention because one leaked credential can obscure which person or service generated the usage.

Users of only the local open-source agent should verify that they never signed into Console or synchronized credentials before assuming they are outside the incident. Local environment variables and configuration files are not automatically equivalent to a cloud-stored Console key, but agents can still leak secrets through logs, prompts, extensions, or shell history. This incident is a prompt to audit the whole path rather than panic about every installation.

The five-step response

First, identify every provider key that was ever connected. Check the Console account, password manager, deployment configuration, and provider dashboard. Record the key identifier and services that depend on it before revoking anything, so production systems can be updated safely.

Second, revoke and replace exposed candidates. Rotation means creating a new credential, updating the legitimate service, testing it, and then invalidating the old key. If the old key can be revoked immediately without breaking critical work, do that first. Do not merely rename it or change an OpenCode password; the provider credential is a separate secret.

Third, audit usage and billing. Review requests, model names, regions, timestamps, and cost spikes from the earliest plausible incident window through today. A small number of high-priced calls can matter more than a large count of cheap ones. Save evidence before dashboards roll older data out of view.

Fourth, report suspicious charges to the provider. Include the key identifier, timestamps, affected projects, and actions already taken. Do not publish the full key in a ticket, screenshot, or social post. If the account uses prepaid credit, check the remaining balance; if it uses postpaid billing, inspect pending as well as finalized usage.

Fifth, reduce the next blast radius. Set project-level budgets and alerts, issue separate credentials per service, choose the narrowest available permissions, and remove unused keys. A single master key reused across a laptop, coding agent, server, and CI system converts one incident into four investigations.

Why a spending limit is a security control

Developers often treat token budgets as finance settings. For externally billable AI keys, they are also containment. A leaked credential with a low project cap may still expose prompts or data, but it cannot silently generate an unlimited invoice. Usage alerts shorten detection time, while per-service keys make it possible to disable one integration without stopping everything.

Rate limits alone are not enough. An attacker can operate slowly, use an expensive model, or distribute calls across time. Combine a hard budget where the provider supports it, near-real-time alerts, separate projects, and automatic key expiration for temporary experiments.

The architecture lesson for coding agents

An AI coding tool sits close to source code, terminals, repositories, cloud credentials, and paid model APIs. Convenience encourages users to connect everything to one account, but that makes the control plane unusually valuable. The right question is not only whether the model is safe; it is where secrets are stored, who can read them, and how quickly they can be invalidated.

Teams should maintain an inventory of every AI tool that holds a credential. Prefer short-lived tokens or brokered access when available. Keep production secrets out of interactive agents, restrict network egress, and ensure logs redact authorization headers. If a product cannot explain its secret-storage and deletion model, do not give it a high-value unrestricted key.

Verdict

The confirmed incident does not justify telling every OpenCode CLI user that their key was stolen. It does justify immediate action from Console users who connected external provider credentials. Rotate plausible keys, inspect usage, contain spend, and wait for a detailed postmortem before accepting a confident root-cause story.

The durable lesson is broader than OpenCode: an API key entered into an AI tool is not merely a setup field. It is a financial and operational credential. Treat it with the same inventory, isolation, and rotation discipline as a production password.