Your Coding Agent Held Your API Keys. What to Do When That Tool Is Breached

What happened

Anomaly Innovations, the company behind the open-source coding agent OpenCode, said a breach affected about 1.4% of OpenCode Console users and that third-party provider keys saved in their workspaces may have been exposed. Startup Fortune's report quotes the notice as identifying "unauthorized access to a legacy system". The company says affected accounts were emailed and that it is working with Anthropic, OpenAI and Google.

Much is still open: how many accounts that is, how the attacker got in, and whether keys kept only in local config files were affected. The company called it a "distillation attack", and researchers have questioned the label, because distillation describes what stolen keys might be used for, not how they were taken. Some users have reported charges they did not make. Those are individual reports, not confirmed figures.

The tool itself is less important here than the pattern. A coding agent runs with your credentials, and anywhere it stores them becomes a second copy of your keys that you do not control.

If you were notified, or are unsure

Revoking before reissuing feels backwards, because things break in between. Do it anyway. The other order leaves a window where both keys work, and the old key is the one someone else holds.

Give each tool its own key

One key shared across an IDE agent, a CLI, a hosted console and a production service means one breach forces you to rotate everything at once. Separate keys per tool, ideally in a separate workspace or project with its own limit, turn that into a single revocation. You also find out which tool was responsible, because the usage shows up against its key.

Name keys after where they live: opencode-laptop, ci-review-bot. When the next notice arrives, you will know which one to kill without guessing.

Decide where the key should live

There are three common places, and they fail differently:

• A vendor's hosted console. Convenient, and it follows you between machines. It is also a store you cannot audit, and it can outlive your use of it. This incident involved what was described as a legacy system.
• Your machine's environment or keychain. The key never leaves your hardware, but anything the agent runs can read it. That includes a command written by the model after it has read an untrusted file.
• Outside the sandbox entirely. The agent runs in an isolated environment and its outbound calls get credentials added by something it cannot inspect. Perplexity's newly open-sourced SPACE runs each sandbox in a Firecracker microVM, with credentials and network egress handled outside the guest. It needs Linux with hardware virtualisation, so it suits teams more than laptops.

OpenCode's own documentation, as Startup Fortune notes, says it does not sandbox the agent and that its permission prompts are a UX feature rather than a security boundary. It recommends Docker or a VM for real isolation. That is an honest description, and most coding agents could say the same. A permission prompt guards against accidents. It does not stop a determined process, and it does nothing about a key stored on someone else's server.

What a breach notice should tell you

When you judge a tool, read its incident response as part of the product. A useful notice says which data was exposed, from which system, over what time window, and whether locally stored secrets were affected. If those answers have not come by the time you finish rotating, assume the wider scope.

The story is in the October 18 briefing, alongside the SPACE release. For the cost side, read AI agent cost control. For the other way an agent misuses its access, read how to test an agent against prompt injection and scope control for coding agents.