OpenCode Console breach and linked AI accounts
Report edition: 22 October 2026 · PDF page 8
Research reviewed 22 October 2026 · Evidence and editorial planning guidance are distinguished below.
- Operational priority
- Critical*
- Evidence
- Vendor-confirmed breach
Credential incident • OpenCode statement, 17 October 2026
Priority is conditional on actual exposure. An asterisk highlights especially conditional exposure; these are editorial judgments, not CVSS scores.
Explore this topic in depth
Ten detailed reports: four shared analyses and six audience perspectives. Research reviewed 22 October 2026; the original PDF account remains below as a dated snapshot.
Research update and qualifications
OpenCode’s documentation confirms that workspaces can use customer-supplied provider API keys and that these requests are billed by the provider. The original incident statement linked in the PDF could not be retrieved during this pass. The dated report’s incident account is retained, but fresh scope or restoration claims are not independently confirmed here.
OpenCode Zen documentation · Incident post unavailable in this research pass; product documentation checked.
Product documentation explains the credential relationship; it does not verify the incident, affected accounts or reimbursement eligibility.
The original PDF snapshot
What the report establishes
OpenCode reported a breach affecting 1.4% of Console users: a subset with external providers linked. It described a large-scale distillation attack and said it was working with Anthropic, OpenAI and Google. This scope should not be expanded to every local OpenCode installation.
Impact and potential reach
Affected Console accounts and connected provider credentials. The percentage is a vendor-reported share of Console users, not a count of compromised people or all product users. Unauthorized use can create financial loss and exhaust service quotas.
Required actions
AI platform owners: check incident notifications, revoke and replace potentially exposed provider keys, and review usage and billing logs. Apply account limits, investigate unexplained charges, and retain evidence for provider support.
Six perspectives on this topic
For the business manager
Keep development work moving through an approved fallback while the account owner investigates. The operational focus is the team’s ability to work without sharing new credentials informally or creating untracked paid accounts.
Read the business manager report for priorities, evidence and a decision checkpoint.
For the business owner
Assign responsibility for AI spending and credential custody. An intermediary interface can make several provider accounts feel like one product, while the bills and access rights remain separate. A commercial dispute needs account evidence and supplier terms, not an assumption of automatic reimbursement.
Read the business owner report for priorities, evidence and a decision checkpoint.
For the technical manager
Treat the console and model provider as separate control boundaries. Catalogue who can add keys, which members can use them and which logs remain available if the console is inaccessible. Preserve this inventory outside the tool being investigated.
Read the technical manager report for priorities, evidence and a decision checkpoint.
For the software engineer
Remove secret reuse from the developer workflow and make credential changes verifiable. Do not paste full tokens into issue trackers or chat to prove which key was affected. Use provider key identifiers, timestamps and approved log exports.
Read the software engineer report for priorities, evidence and a decision checkpoint.
For the customer service
If customers ask about AI-assisted support or delivery delays, describe the verified service effect rather than making broad claims about the tool incident. Staff should not request provider API keys or promise refunds on behalf of another vendor.
Read the customer service report for priorities, evidence and a decision checkpoint.
For the customer
Ask the business whether the issue affects the service or information it handles for you. An AI-provider billing event does not by itself prove exposure of your records. Account-specific statements should come through established service and privacy channels.
Read the customer report for priorities, evidence and a decision checkpoint.
In this section
- OpenCode: Evidence and scopeProduct documentation explains the credential relationship; it does not verify the incident, affected accounts or reimbursement eligibility.
- OpenCode: Business impact and costsThe business may face unexpected inference spending and uncertainty about how a shared key was used. Developer interruption and investigation effort should be tracked separately from any disputed charges.
- OpenCode: Technical exposure and controlsInventory the provider accounts connected to the console, which keys were shared, the scopes available to each, and the independent billing and audit views at the provider.
- OpenCode: Response and recoveryRestore the integration when its owner accepts the current vendor guidance and the business can observe and limit the new credential’s use.
- OpenCode: Business manager reportWhich team can keep working safely while the shared integration remains restricted?
- OpenCode: Business owner reportCan we see and stop spending at the provider without access to the intermediary console?
- OpenCode: Technical manager reportIs any replacement key also reused by an unrelated production service?
- OpenCode: Software engineer reportDoes deleting the tool configuration actually invalidate the credential at its issuer?
- OpenCode: Customer service reportAre we reporting our own verified service status or repeating an unconfirmed external claim?
- OpenCode: Customer reportWhat is confirmed about my service, and what is still being investigated?