Our read is that this moves the concentration somewhere else without removing it. What limits the damage is keys that expire quickly and can do very little.
Summary
OpenCode says unauthorized access, which it connects to a large-scale distillation attack, may have exposed third-party provider API keys belonging to 1.4% of its Console users. Only customers who had linked external providers such as OpenAI and Anthropic were affected, and OpenCode is also working with Google on remediation. Whether attackers want such keys to feed distillation is a plausible hypothesis, not an established fact. Either way, the incident shows that any hosted layer holding many customers' keys is a single point of failure, however well it hides those keys from its own users.
What happened
According to iSec News, OpenCode detected unauthorized access on October 17, 2026 and tied it to a large-scale distillation attack. The intruder reached a legacy system that was being prepared for decommissioning. The exposure was limited to Console customers with linked external providers, whose stored provider keys may have been exposed. OpenCode emailed the users it identified and said anyone who did not get an email was not affected. Its advice was to revoke and replace keys, update applications that use them, and review recent usage. It has not said how many keys or accounts were involved, whether any keys were used, or how the intrusion worked. CellCog's account of OpenCode's post on X quotes the company saying the incident is ongoing and that it cannot share more details yet. In the same week, 1Password introduced 1Password for Agents, which it says lets AI assistants use credentials and secrets without seeing or storing them. OpenAI and Anthropic are among the named launch partners. Our evidence includes no published interfaces, pricing or terms.
What the archive adds
An archived bulletin (d1) describes the episode as a 48-hour attack that may have exposed OpenAI, Anthropic and Google keys. The Hacker News (d2) confirms the legacy-system entry point, the 1.4% figure, and that the affected users were those who had linked an outside provider to the hosted Console. Anthropic's September 2026 threat intelligence report (d3) describes illicit distillation campaigns as harvesting frontier-model capabilities through large volumes of queries and outputs, often routed through proxy services. That gives a possible motive for wanting customer keys, but none of these sources shows that keys taken from OpenCode were used for distillation. The Karpathy piece in the pack is about the AI capability gap and has no bearing on this incident.
Trend signal
More and more products sit between developers and model providers: hosted coding-agent consoles, BYOK gateways, and self-hosted proxies of the LiteLLM kind. Each one offers convenience and governance. Members of a workspace call models without ever handling the raw key, and the gateway applies routing, budgets and logging. That design does protect against one class of risk, such as a developer pasting a key into a repo or a departing employee keeping it. It also creates another risk: the gateway has to hold the real, long-lived provider keys so it can make calls on users' behalf. In a hosted multi-tenant console, that means many customers' keys sit behind one perimeter, and that perimeter includes whatever legacy systems the vendor has not yet shut down. Credential tooling for agents, including 1Password's new product, belongs to the same trend. It changes who can see a secret, but it does not by itself shorten how long a secret stays valid or narrow what it can do.
Why now
1) Central storage by design: the affected users were exactly those who had linked outside providers to the hosted Console, so their keys sat in OpenCode's systems (primary; d2). 2) Legacy debt: the intruder reached a system being prepared for decommissioning (primary; d2), so an old storage path outlived its purpose. 3) A plausible new motive: according to Anthropic's September 2026 report (d3), illicit distillation runs on large query volumes routed through proxies, which would give provider keys direct value to attackers. This is unconfirmed for this case. 4) More intermediaries: hosted consoles, gateways and agent credential tools keep multiplying, and each one holds keys on users' behalf.
Connections to other events
The common reaction to a key leak is to put keys behind a gateway or vault so nobody handles them directly. OpenCode's Console already worked roughly like that for its users, and the keys were exposed anyway, because they were still stored centrally and an attacker got to where they lived. Brokering by a gateway changes who can read a key. It does not change what a stolen key can do, or for how long. If you swap a hosted gateway for a self-hosted proxy, the pile of keys moves into your own infrastructure: it gets smaller and becomes your responsibility, but it is still a pile. Our read is that the variable that actually limits damage is the key itself. How long is it valid? Which models and endpoints can it call? What spend cap applies? Is it shared across tools, or issued to one? A key that expires within hours and can only reach one model under a hard budget is worth little to anyone, distillation operator or not. Long-lived, broadly scoped keys copied into third-party storage are the real exposure. The distillation link makes this more pressing but is not needed for the argument: if d3's picture of query-hungry campaigns routed through proxies is right, stolen keys are directly useful to such operators. Even if it is wrong, an unscoped key still exposes billing and data. Agent Skills, which can bundle scripts, may become another place keys end up as adoption grows. We have no evidence of a leak through skills so far.
Why it matters
For builders of gateways and agent consoles, hiding keys from workspace members is the minimum, not the goal. The stronger design keeps raw provider keys out of the tool entirely, or keeps only keys that are narrowly scoped and spend-capped, and retires legacy storage paths instead of leaving them half-decommissioned. OpenCode's entry point was exactly that kind of system. For buyers, the questions to ask a vendor are: which keys does it hold, how long are they valid, what can they reach, and how quickly can it tell you which ones were touched? Where providers support it, give each tool its own key with a budget, so that a breach means revoking one narrow key rather than cutting off company-wide access. For providers, the pressure is likely to grow for expiring and scoped credentials that third-party tools can use without holding a master key. That is our inference, not an announced plan.
What happens next
- OpenCode will publicly disclose either the number of exposed keys or whether any were misused. (3 months, 40%). Watch for: A post-incident report or updated statement from OpenCode giving key counts, misuse findings or a root cause.
- At least one of OpenAI, Anthropic or Google will announce a new credential control aimed at third-party tools, such as scoped or expiring API keys or automatic revocation of leaked keys. (6 months, 45%). Watch for: A provider changelog or docs entry introducing short-lived or narrowly scoped keys meant for third-party integrations.
- Another AI developer tool, gateway or agent platform will disclose a breach exposing customer-stored LLM provider keys. (12 months, 60%). Watch for: A public incident notice telling users to rotate OpenAI, Anthropic or Google keys stored in a third-party product.
Limits and uncertainty
OpenCode has not disclosed key counts, misuse, root cause, or how the distillation attack and the intrusion are actually connected. Stolen keys feeding distillation is a hypothesis based on Anthropic's general description of proxy-based campaigns, not a confirmed finding. We do not know how OpenCode encrypted or isolated stored keys, so we cannot say whether a better-built central store would have held. The scoping and expiry options that provider APIs offer today vary and may not match what this argument calls for. 1Password for Agents has no public technical details in our evidence, so we do not know whether it reduces key lifetime or only visibility. Self-hosted proxies shrink the pool of keys but bring their own operational risks, which we have not weighed here.
Skill to build now
Practise reducing the blast radius of a key, not just hiding it. First exercise: take one service that calls a frontier model through a gateway or console. Issue it a dedicated provider key restricted to the models it uses, with a spend cap. Then revoke the old shared key and time how long the service takes to recover. If recovery needs a redeploy, have the service read the key from a secret manager at runtime and write the rotation steps down as a runbook.
Reader takeaway
This week, list every provider key that sits in a third-party console, gateway or proxy. Record each one's lifetime, scope and spend cap. Any key that is long-lived, unscoped and shared across tools is your real exposure: replace it with a per-tool key that has the narrowest permissions and budget the provider allows, and set a rotation schedule. Treat "the gateway hides it from our engineers" as a convenience feature, not a security control.
Open question
If gateways that hold keys centrally and self-hosted proxies both still concentrate long-lived keys, should model providers be expected to issue short-lived, narrowly scoped credentials that make third-party key storage pointless? And if they do not, who carries the cost when a stored key is abused?