OpenCode Console breach: trace AI keys to their issuer

Sources checked: 30 October 2026. FailSafe Research.

The important first question after an AI-tool breach is where the affected credentials actually lived. Treating every installation of a product as equally exposed can distract from the accounts that need action.

Console and local use are different scopes

In its October disclosure, OpenCode said a breach affected 1.4% of Console users, specifically a subset with external providers linked, and that it had notified them. It described a relationship to a large-scale distillation attack without publishing enough detail to independently establish that mechanism. Co-founder Dax Raad clarified that the scope was Console, distinguishing locally held keys that did not come to the service.

This is not evidence that OpenAI, Anthropic or Google’s underlying platforms were breached. Nor does a percentage by itself establish the number of copied or abused keys. Follow the notification for the account in question and the provider’s current recovery instructions.

A saved key is delegated purchasing power

Map the provider project, key owner, permitted models, accessible data and billing authority. Then list every service holding a copy. That inventory should make it possible to answer who revokes the credential when a hosted workspace is no longer trusted.

Removing a stored value from an integration is different from invalidating it at the issuer. A copied credential may be used outside the integration entirely. Review provider-side activity and spend controls, and distribute replacement credentials only after assessing the systems that will receive them.

Test the custody lifecycle

1. Create a dedicated test credential with limited privileges and a named owner.
2. Verify which roles can reveal, export or use it through the hosted workspace.
3. Remove the integration and revoke the key at its provider.
4. Confirm that previously issued sessions or cached credentials no longer allow the prohibited action.

Use isolated projects and approved budgets. An exercise should never create uncontrolled billable traffic or expose production keys in a report.

Keep AI security tied to real authority

FailSafe SWARM can test the application and API paths around AI services within agreed scope. Our AI security work examines how identities, tools and data interact, so teams can distinguish an interesting model response from a consequential security failure.

Enterprises with stricter processing boundaries can also review FailSafe’s sovereign hosting and inference options. Deployment location does not remove the need for credential lifecycle controls. The model endpoint, operator access and integrations still need an explicit design.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.