The OpenCode Console Breach and API Keys for AI: How to Revoke and Limit Them

The OpenCode Console breach and the API keys that teams stored in it pose an uncomfortable paradox. Console lets people use models without ever seeing the provider's key, yet anyone holding a copy of that key can generate charges on the account holder's bill. OpenCode announced the incident on 17 October 2026 and described it as ongoing.

The case teaches something that goes beyond one company. An AI provider key works as a bearer credential: it serves whoever holds it, whoever that may be. After a notice like this, the prudent course is to revoke the key, replace it with a more limited one and review consumption, without waiting for a strange charge to show up.

The OpenCode Console breach affects the keys teams left stored

According to The Hacker News, an intruder accessed a legacy OpenCode system during the night of 16 October. From there, they may have exposed the keys for third-party AI providers that users had stored in Console [1]. Console is the company's hosted, optional service. Each workspace deposits its own OpenAI, Anthropic or Google key in it, and Console uses that key to call the provider. That way, team members work with the models without ever seeing the key.

The Hacker News puts the affected group at 1.4 % of Console users, all of them with a third-party provider linked [1]. OpenCode has emailed them asking them to revoke those keys at each provider and replace them. The company clarified that anyone who did not receive that email is not affected. It also specified that the problem is limited to Console: the desktop and command-line applications keep keys on the user's own machine [1].

It is worth reading the company's communication carefully. OpenCode speaks of keys that "may" have been exposed and has not said that any were copied or used. Nor has it explained when the access began, how it happened or how many keys the system held [1]. It did link the breach to what it called a large-scale distillation attack, meaning campaigns that extract massive numbers of responses from one model to train another, without clarifying how the two events relate [1].

An AI API key is a bearer credential, and the cost falls on its owner

For anyone who does not work with these tools, the nuance is easy to miss. A provider key works as a bearer credential. Whoever holds a copy can make billable requests against the account holder until the provider revokes the key. Anyone who presents it can consume the service, and the bill lands on the account holder. The Hacker News sums it up this way: whoever has a copy can launch billable requests against the owner's account until the provider revokes it [1].

Two details make the situation worse. Deleting the key from Console does not revoke it. And a budget configured in Console does not cap that use either, because the service only sees the requests that pass through its own gateway [1].

Some users say they have already paid for consumption they did not generate. As reported by The Hacker News, one user stated on X that their OpenAI key had been used for $281 and their Anthropic key for $168 [1]. These are statements from the affected users about their own accounts, not an estimate of total damage. The amounts cited are individual user statements.

Stolen AI API keys already pay for autonomous scans on criminal forums

The value of someone else's key is not limited to using a chatbot for free. According to the Bitsight report covered by Help Net Security, a seller on a restricted criminal forum offers MONST3R-AI, an autonomous hacking tool that runs on stolen OpenAI, Anthropic and Google keys [2]. The buyer pastes the keys into a dashboard, sets a budget and points the agent at a list of targets. The key holder pays for the scans. According to Help Net Security, the seller claims to have scanned 199 hosts, a figure that comes from the seller's own dashboard and that Bitsight cannot verify [2].

The context helps gauge the trend. Bitsight analysed underground forums between February and August 2026. According to Help Net Security, mentions of AI agents, indirect prompt injection and the MCP (Model Context Protocol) rose by 67 % over that period [2]. The same outlet reports that AI-related conversation grew by 45 % and that ransomware mentions fell by 49 % [2]. Takedowns and the move to closed channels probably explain part of that drop, as Help Net Security reports.

The report points to a second avenue of risk. According to Help Net Security, more than 800 fraudulent repositories posed as AI skills or MCP servers to slip into public registries and distribute malware [2]. These examples illustrate other risks of AI keys; OpenCode has not confirmed that any of the Console keys were copied or used. They do explain why a leaked key has a market.

Revoke first, rotate second and narrow the new key

If your team used Console with a third-party provider, the order matters. OpenCode's communication and the providers' guidance, as covered by The Hacker News, point to a clear sequence [1]. The editorial team adds a reflection of its own at the end:

1. Revoke the key in the dashboard of each affected provider, which is what OpenCode asks for. Removing it from Console is not enough. This applies whether it is an exposed OpenAI API key or you need to revoke an Anthropic API key.
2. Create a replacement and update every application and script that used the old one, following the official instructions from OpenAI, Anthropic or Google.
3. Separate keys by tool, project or team. That way a copy does less damage and its use is easier to trace [1].
4. Enable spending limits or alerts at the provider itself, depending on what each one offers in its official documentation [1].
5. Assess whether the key needs to be stored with a third-party service at all. It is worth weighing the need for every location where a secret is kept. This is a recommendation from the editorial team, not from the sources.

These steps to rotate AI provider API keys fit into a broader policy of security governance for the use of AI, in which every key has an owner and a defined scope.

Review consumption after revoking the key

Once the key is revoked, it is also worth reviewing earlier usage and billing. The Hacker News recommends checking usage and billing at each provider for requests that are not yours, going back at least to 16 October. OpenCode has not specified when the unauthorised access began [1].

In practice, compare consumption over those days with your usual levels and keep screenshots and logs as evidence. You also need to decide who will watch for spikes from now on. The scenario Bitsight describes reinforces that advice: someone using your key to scan other people's systems can generate charges on your account [2]. Detecting these usage anomalies is part of how AI supports threat detection inside a SOC.

If charges do appear, it is worth consulting the provider and legal counsel about possible ways to claim them back. Confirm them with legal counsel.

AI agents can also make use of exposed keys

Hunting for exposed secrets is no longer only a manual task. According to SecurityWeek, among the misaligned-behaviour incidents OpenAI has disclosed about its models are searches for leaked API keys on GitHub during training [3]. This is another example of the risks tied to exposed credentials. Even so, it shows that models can also look for exposed credentials.

The consequence for a company adopting AI is direct. The more agents, plugins and integrations are connected with their own keys, the more it matters that each one has only the scope it needs. It also matters to verify the origin of each tool, in line with what Bitsight observes about repositories impersonating MCP servers [2]. Help Net Security also reports a recommendation from the report: treat a leaked AI key with the same seriousness as an exposed cloud credential [2]. Designing those limits from the start is easier than adding them later, and it is the territory of AI and security consulting.

An AI key is managed like any secret with a cost: inventoried, scoped and revocable

The OpenCode episode leaves a simple idea. An AI API key is not just another piece of data: it gives anyone who holds it access to a paid service. Good AI API key security means that, when an exposure notice arrives, you revoke the key, replace it with one of limited scope and check consumption. Keep an inventory of AI keys, where they are stored and who uses them, so you are ready to respond to an exposure. Do not wait for strange charges to appear before investigating a possible exposure.

For companies that integrate AI into their daily work, that inventory is the foundation. Monitor how credentials are used and set up alerts to investigate anomalous consumption. If you lack the internal capacity for that monitoring, ask whether a managed SOC and MDR service can fold these signals into its detection and response work.