On October 17, 2026, OpenCode disclosed that its Console product had been breached and that OpenAI, Anthropic and Google API keys saved by some users may have been exposed. The OpenCode Console breach came only days after Fireworks AI reported its own incident, and together they make an uncomfortable point: any platform that stores your AI provider keys is a place where someone else can start spending your money. If your team has pasted a key into a coding agent, LLM gateway or evaluation tool, this is the week to act.

What happened in the OpenCode Console breach

According to OpenCode's post on X, as quoted by Safeguard and DEV Community, the breach was tied to a “large scale distillation attack” that affected 1.4% of OpenCode Console users, specifically a subset who had linked external providers. Those users were notified by email. OpenCode said the incident was still ongoing, so it couldn't share more details, but that it was working with Anthropic, OpenAI and Google on remediation.

The customer email, as reported by Safeguard, said attackers had gained unauthorized access to a legacy system OpenCode was in the process of decommissioning, and that third-party provider keys saved in workspaces may have been exposed. Users were asked to revoke and replace those keys in each provider's dashboard, update the applications using them, and review recent usage for anything unexpected.

A few details define the scope:

  • Console keys lived on OpenCode's servers. Console is built so team members can use models without ever seeing the provider key, which means the key is held centrally by OpenCode.
  • Local CLI keys may be a different case. As DEV Community's write-up points out, keys added with /connect in the CLI are stored on the user's own machine in ~/.local/share/opencode/auth.json. OpenCode hasn't said anything about local keys in this incident.
  • Anthropic acted. Anthropic said it revoked affected Claude API keys. OpenCode says it is working with OpenAI and Google as well; the reports we reviewed don't describe any steps of their own.

The damage reports so far come from individual users and are not confirmed by OpenCode, but they show what's at stake. Dealroom collected posts from users on X: one said his OpenAI key was hit for $281 and his Anthropic key for $168, another put his losses at $1,700, and a third saw more than $700 in OpenAI usage before cutting access. Co-founder Dax Raad also posted that his personal accounts were now being attacked.

Not a one-off: platforms that hold other people's keys

OpenCode is a large target. The company says 16 million developers use its open-source agent each month, connecting to models from more than 75 providers. But the real lesson is architectural, not about one vendor.

Fireworks AI's security bulletin describes unauthorized use of internal Fireworks credentials and access to environment variables used in evaluation jobs in a limited number of customer accounts. According to Dealroom, Fireworks spotted the activity on October 6 and published its bulletin on October 9. The bulletin contains a warning every team should internalize: removing a stored secret from a platform does not invalidate the underlying credential. Only the issuing provider can do that.

The wider context matters too. On October 12, Anthropic said new defences had cut what distillers harvest from Claude by around 90 to 99%, describing distillation attacks as industrial-scale campaigns usually run through networks of fraudulent accounts. Our reading, not a confirmed attribution: as fraudulent accounts get harder to run, legitimate customers' keys stored in third-party tools become a more attractive target. Plan as if these incidents will repeat.

Why AI provider keys are spendable secrets

Most teams treat an AI API key like a configuration value: generate it, paste it into a tool, move on. That habit is now expensive. A raw provider key is effectively a payment method plus your account's standing with the provider. When it leaks, you can lose:

  • Money, through usage billed directly to your account.
  • Availability, if the provider suspends a project for abuse.
  • The account itself, if the provider treats the misuse as a terms violation.

Monitoring alone won't save you. As Safeguard notes, a spend notification tells you a threshold was crossed; it doesn't revoke anything. You need limits and fast rotation, not just emails.

What to do this week

Here is a checklist for this week.

1. Inventory every place a raw key lives

List each SaaS tool, coding agent, LLM gateway, evaluation platform and CI pipeline that holds a provider key. Include tools you've stopped using. The OpenCode keys sat in a system that was already being retired.

2. One key per tool, with a spend cap

Never share a single key across tools. Issue a dedicated key per integration and set a spend limit for it at the provider. When something leaks, you know exactly which key to kill, and the damage has a ceiling.

3. Rotate in the right order

Deleting the old key first causes an outage. The safe sequence:

  1. Create the replacement key at the provider.
  2. Deploy it to every application and tool that uses it.
  3. Confirm traffic is flowing on the new key.
  4. Revoke the old key at the provider, not just inside the third-party tool.
  5. Review recent usage and billing for activity you don't recognize.

If you used OpenCode Console with linked providers, run this now whether or not you received the email.

4. Decommission secrets along with systems

When you retire a tool or service, revoking its keys at the provider should be a required shutdown step. To an attacker, a “legacy” system with live credentials is still a production system.

Going keyless on Azure with Entra ID

The strongest fix is to have no key to steal. Microsoft's Foundry guidance recommends Microsoft Entra ID for production workloads so you get conditional access, managed identities and least-privilege RBAC. It is direct about the downside of API keys: they grant full access to the resource, are hard to scope to specific users or actions, and need manual rotation.

With a managed identity and a least-privilege role assignment on the resource, your app can call models without any secret in its configuration:

from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import AzureOpenAI

# Managed identity in Azure, developer login locally
token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), "https://cognitiveservices.azure.com/.default"
)

client = AzureOpenAI(
    azure_endpoint="https://my-ai-services.openai.azure.com/",
    azure_ad_token_provider=token_provider,
    api_version="2024-10-21",
)

Then turn key authentication off so that a leaked key is useless. In Bicep, set disableLocalAuth to true:

resource aiServices 'Microsoft.CognitiveServices/accounts@2023-05-01' = {
  name: 'my-ai-services'
  location: location
  kind: 'AIServices'
  sku: {
    name: 'S0'
  }
  properties: {
    customSubDomainName: 'my-ai-services'
    disableLocalAuth: true
  }
}

To enforce this across a whole estate rather than resource by resource, assign the Azure Policy “Azure AI Services resources should have key access disabled (disable local authentication)” at subscription or resource group level. Two practical caveats:

  • The cutoff isn't instant. Microsoft says propagation typically completes within a few minutes but can take up to several hours depending on region, load and gateway cache state. Don't rely on it as an emergency kill switch; rotate keys too.
  • Many third-party tools still require keys. Coding agents and gateways often accept only raw keys. For those, keep a dedicated, capped key per tool, and prefer tools that store credentials locally or support identity-based auth.

Key takeaways

  • OpenCode disclosed on October 17 that provider keys stored in Console may have been exposed; affected users should revoke and replace them at each provider.
  • Together with the Fireworks AI incident, this shows that any platform storing your keys extends your attack surface and your billing risk.
  • Deleting a key inside a tool doesn't invalidate it; only the provider can revoke it.
  • Use one key per tool with a spend cap, and rotate by deploying the new key before revoking the old one.
  • On Azure, prefer Entra ID with managed identities and enforce disableLocalAuth via Azure Policy so stolen keys can't be used.
  • Retiring a system should always include revoking the secrets it holds.