OpenCode Console Breach: AI Provider API Keys Potentially Exposed — Detection, Rotation, and Containment Guide

On the night of October 16, an intruder gained access to a legacy system at OpenCode and may have exposed third-party AI provider API keys that customers stored in OpenCode Console, the company's optional hosted service. For those not tracking the product: Console lets a workspace save its own OpenAI, Anthropic, or Google API key server-side, then uses that key to call the provider so team members can consume models without holding credentials locally. That convenience is exactly the risk — a single compromise of the hosted service potentially hands attackers working, billable, provider-level credentials for every connected customer workspace.

This is not a theoretical supply-chain concern. AI provider keys are high-value targets in 2026. They enable direct financial abuse (model consumption billed to your account), data access (depending on provider-side logging and any fine-tuned model or file associations), and in some configurations, a pivot into organizational accounts. If your organization uses OpenCode Console with stored provider keys, treat those keys as compromised until you prove otherwise. Rotate first, investigate second.

There is no CVE associated with this incident — this is a breach of a legacy system, not a disclosed vulnerability in shipped software. The defensive work here is credential containment, misuse detection, and architectural hardening.

Technical Analysis

What happened: OpenCode disclosed that an unauthorized actor reached a legacy system on the night of October 16. The system in question backed OpenCode Console, the hosted component that persists customer-supplied AI provider keys and brokers calls to OpenAI, Anthropic, and Google on behalf of workspace members. OpenCode stated the intruder may have accessed those stored keys.

Affected assets: Any API key saved in OpenCode Console — that means keys issued by OpenAI (typically sk-... prefixed), Anthropic (sk-ant-... prefixed), and Google (Google AI Studio / Vertex-adjacent credentials used via the Gemini API). The blast radius is per-key: whatever permissions and billing scope that key had at the provider, an attacker now potentially has.

Why the "legacy system" detail matters: In my experience leading breach investigations, attackers land on legacy infrastructure because it's where patching, logging, and segmentation discipline decay. The fact that a credential store for third-party secrets was reachable from a legacy system tells us the secret store was not adequately isolated from the blast radius of older infrastructure. When you do your post-incident architecture review, that trust relationship is the finding.

Exploitation status: The intrusion is confirmed by the vendor. Whether keys were actually exfiltrated is unconfirmed — OpenCode used the word "may." From an IR posture standpoint, unconfirmed exfiltration of a centralized credential store is treated as confirmed for containment purposes. Assume keys are in hostile hands. Watch for post-breach key abuse: attackers commonly validate stolen keys within 24-72 hours (a cheap models.list call), then either resell them or begin metered abuse designed to stay under billing-alert thresholds.

Attacker playbook after key theft (what defenders should expect):

1. Key validation from a VPS or residential proxy IP — low-volume calls to /v1/models or equivalent.
2. Reconnaissance of key scope — checking available models, fine-tunes, and file/vector-store access.
3. Monetization — reselling keys on criminal markets, or running their own inference workloads on your dime, often throttled to avoid quota alarms.
4. In worse cases, accessing conversation logs or files where the provider's API scope permits it.

Detection & Response

The telemetry for this incident lives in three places: (1) your endpoints, where keys may be cached locally by developer tooling or exposed in dotfiles; (2) your network, where calls to provider API endpoints should only originate from expected systems and processes; and (3) the providers themselves, where usage logs, IP addresses, and billing anomalies are your ground truth for key misuse. Prioritize provider-side review — OpenAI, Anthropic, and Google all expose usage/admin logs that will show you exactly when and from where a key was used. Pull those logs now and compare against the October 16 window and everything after.

Sigma Rules

---
title: Suspicious Read of AI Provider Credential Files on Linux
id: 3f7a2b1e-9c4d-4e8a-b1f2-5d6c7a8b9e0f
status: experimental
description: Detects shell utilities reading files that commonly store OpenAI, Anthropic, or Google AI API keys. Post-breach, attackers with host access hunt for cached AI credentials in dotfiles, env files, and tool configs. Tune the path list to your developer workstation and CI runner conventions.
references:
  - https://thehackernews.com/2026/10/opencode-console-breach-may-have.html
  - https://attack.mitre.org/techniques/T1552/001/
author: Security Arsenal
date: 2026/10/18
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: process_creation
  product: linux
detection:
  selection_reader:
    Image|endswith:
      - '/cat'
      - '/less'
      - '/more'
      - '/head'
      - '/tail'
      - '/grep'
      - '/awk'
      - '/strings'
      - '/base64'
  selection_targets:
    CommandLine|contains:
      - '.env'
      - 'credentials.json'
      - 'opencode'
      - 'ANTHROPIC_API_KEY'
      - 'OPENAI_API_KEY'
      - 'GOOGLE_API_KEY'
      - 'GEMINI_API_KEY'
  condition: selection_reader and selection_targets
falsepositives:
  - Developers legitimately inspecting their own environment files
  - CI/CD pipeline scripts sourcing credentials at build time
level: medium
---
title: AI Provider API Endpoint Contacted by Non-Standard Process
id: 8b1c4d5e-2f6a-4b7c-9d8e-1a2b3c4d5e6f
status: experimental
description: Detects network connections to OpenAI, Anthropic, and Google AI API endpoints from processes other than approved SDK runtimes or the organization's sanctioned tooling. After the OpenCode Console breach, unauthorized use of stolen keys may appear as provider API calls from unexpected hosts or binaries in your environment.
references:
  - https://thehackernews.com/2026/10/opencode-console-breach-may-have.html
  - https://attack.mitre.org/techniques/T1102/
author: Security Arsenal
date: 2026/10/18
tags:
  - attack.command_and_control
  - attack.t1102
  - attack.exfiltration
logsource:
  category: network_connection
  product: windows
detection:
  selection_dest:
    DestinationHostname|endswith:
      - 'api.openai.com'
      - 'api.anthropic.com'
      - 'generativelanguage.googleapis.com'
  filter_approved:
    Image|endswith:
      - '\python.exe'
      - '\python3.exe'
      - '\node.exe'
      - '\opencode.exe'
  condition: selection_dest and not filter_approved
falsepositives:
  - PowerShell Invoke-RestMethod calls from administrators testing keys
  - Browser access to API documentation pages (destination match is API FQDN only, so this should be rare)
level: medium

KQL — Microsoft Sentinel / Defender

Use this to baseline which devices and processes are talking to AI provider APIs, then surface outliers. During the post-breach window, any new device, process, or user agent appearing for the first time is a lead worth running down.

// Baseline and anomaly hunt: connections to AI provider APIs by device/process
// Look for first-seen devices or processes post-breach (2026-10-16)
let BreachDate = datetime(2026-10-16);
let AIProviders = dynamic(["api.openai.com", "api.anthropic.com", "generativelanguage.googleapis.com"]);
let Historical = DeviceNetworkEvents
| where TimeGenerated between (BreachDate - 30d .. BreachDate)
| where RemoteUrl has_any (AIProviders)
| summarize by DeviceName, InitiatingProcessFileName;
DeviceNetworkEvents
| where TimeGenerated >= BreachDate
| where RemoteUrl has_any (AIProviders)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), ConnectionCount = count()
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl
| where DeviceName !in (Historical | project DeviceName)
   or InitiatingProcessFileName !in (Historical | project InitiatingProcessFileName)
| sort by ConnectionCount desc;

// Linux endpoints via Syslog ingestion: processes touching AI credential material
// Requires process auditing (auditd/Sysmon for Linux) forwarded to Sentinel
Syslog
| where TimeGenerated >= datetime(2026-10-16)
| where ProcessName in~ ("cat", "grep", "less", "head", "tail", "strings", "base64", "awk")
| where SyslogMessage has_any ("OPENAI_API_KEY", "ANTHROPIC_API_KEY", "GOOGLE_API_KEY", "GEMINI_API_KEY", ".env", "opencode")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| sort by TimeGenerated desc;

Velociraptor VQL

Use this hunt to enumerate AI provider keys resident on endpoints — both to scope your rotation effort and to identify unauthorized key staging by an intruder. Adjust the glob paths to your fleet's conventions.

-- Hunt for AI provider API keys in common config/dotfile locations
-- Scopes rotation effort and surfaces unauthorized key staging
LET key_regex = '(sk-ant-[A-Za-z0-9\-_]{20,}|sk-[A-Za-z0-9]{20,}|AIza[0-9A-Za-z\-_]{35})'
LET targets = SELECT FullPath
  FROM glob(globs=[
    '/home/*/.env',
    '/home/*/.config/opencode/**',
    '/home/*/.config/**/.env',
    '/root/.env',
    '/Users/*/.env',
    '/Users/*/.config/opencode/**',
    'C:/Users/*/.env',
    'C:/Users/*/.config/opencode/**'
  ])
SELECT FullPath,
       read_file(filename=FullPath, length=100000) =~ key_regex AS ContainsAIKey,
       timestamp(epoch=stat(filename=FullPath).Mtime.Sec) AS LastModified
FROM targets
WHERE ContainsAIKey

Key Discovery and Validity-Check Script

Run this on developer workstations, build agents, and any system where OpenCode tooling was used. It inventories AI provider keys on disk, performs a low-cost validation call against each provider to determine whether a key is still active, and writes an action list for your rotation runbook. A key that validates successfully is a key that must be revoked and reissued — do not leave active keys in place "just in case."

#!/usr/bin/env bash
# ai-key-triage.sh — discover and validate AI provider keys for rotation after the OpenCode Console breach
set -uo pipefail
REPORT="ai-key-triage-$(date +%Y%m%d-%H%M%S).csv"
echo "file,key_prefix,provider,status" > "$REPORT"

scan_file() {
  local file="$1"
  # Anthropic keys
  grep -oE 'sk-ant-[A-Za-z0-9_-]{20,}' "$file" 2>/dev/null | sort -u | while read -r k; do
    code=$(curl -s -o /dev/null -w '%{http_code}' https://api.anthropic.com/v1/models \
      -H "x-api-key: $k" -H "anthropic-version: 2023-06-01" --max-time 10)
    [ "$code" = "200" ] && status="ACTIVE-ROTATE-NOW" || status="inactive_or_revoked(http_$code)"
    echo "$file,${k:0:12}...,anthropic,$status" >> "$REPORT"
  done
  # OpenAI keys (sk- but not sk-ant-)
  grep -oE 'sk-[A-Za-z0-9]{20,}' "$file" 2>/dev/null | grep -v '^sk-ant-' | sort -u | while read -r k; do
    code=$(curl -s -o /dev/null -w '%{http_code}' https://api.openai.com/v1/models \
      -H "Authorization: Bearer $k" --max-time 10)
    [ "$code" = "200" ] && status="ACTIVE-ROTATE-NOW" || status="inactive_or_revoked(http_$code)"
    echo "$file,${k:0:12}...,openai,$status" >> "$REPORT"
  done
  # Google API keys
  grep -oE 'AIza[0-9A-Za-z_-]{35}' "$file" 2>/dev/null | sort -u | while read -r k; do
    code=$(curl -s -o /dev/null -w '%{http_code}' \
      "https://generativelanguage.googleapis.com/v1beta/models?key=$k" --max-time 10)
    [ "$code" = "200" ] && status="ACTIVE-ROTATE-NOW" || status="inactive_or_revoked(http_$code)"
    echo "$file,${k:0:12}...,google,$status" >> "$REPORT"
  done
}

while IFS= read -r f; do scan_file "$f"; done < <(
  find /home /root /Users "C:/Users" -maxdepth 5 \
    \( -name '.env' -o -name '*.env' -o -iname '*opencode*' -o -name 'credentials.json' \) \
    -type f 2>/dev/null
)
echo "[*] Triage complete. Review $REPORT — any ACTIVE-ROTATE-NOW entry requires immediate revocation at the provider."

Remediation

Immediate (within 24 hours):

1. Rotate every key stored in OpenCode Console. Revoke the existing key at the provider, issue a replacement, and update the workspace configuration. Do this for OpenAI, Anthropic, and Google keys alike — the disclosure covers all three providers.
   • OpenAI: revoke at platform.openai.com/api-keys (or via the Admin API if you're on an organization plan).
   • Anthropic: revoke at console.anthropic.com under API Keys.
   • Google: delete/regenerate at aistudio.google.com or via Google Cloud console credential management if the key is tied to a GCP project.
2. Pull provider-side usage logs for the window October 16 through key rotation. Look for: unfamiliar source IPs or ASNs (VPS providers, residential proxies, geographies inconsistent with your team), first-seen user agents, calls to models you don't use, and any file/fine-tune/vector-store API access. This log review is your only ground truth on whether the keys were actually abused.
3. Set billing alerts and hard spend caps on every AI provider account if you haven't already. This caps the financial damage window for any key abuse you miss.

Short term (this week):

4. Inventory where keys live outside Console. Run the VQL hunt and triage script above across developer workstations and CI runners. Keys found in unencrypted dotfiles on endpoints are an independent exposure — rotate those too.
5. Downscope replacement keys. Where providers support it, issue project-scoped or restricted keys rather than organization-wide keys, and disable capabilities you don't use (fine-tuning, file APIs, assistants).
6. Decide on Console re-adoption deliberately. If you continue using OpenCode Console, demand answers from the vendor on: why a credential-bearing service was reachable from a legacy system, what segmentation now exists, what their logging showed about data access, and whether they support short-lived credentials or customer-side key wrapping. If they can't answer, move key brokering in-house.

Architectural (this quarter):

7. Eliminate long-lived static AI keys where possible. Prefer workload identity, OIDC-based federation, or a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) with just-in-time retrieval over any pattern where a key sits persistently in a hosted third party or a local dotfile.
8. Egress controls on provider endpoints. Restrict which hosts and processes may reach api.openai.com, api.anthropic.com, and generativelanguage.googleapis.com. Stolen keys are much harder to abuse from inside your perimeter, and provider-side IP allowlisting (where offered) should be enabled.
9. Treat AI provider keys with the same rigor as cloud IAM credentials — because functionally, that's what they are. They bill, they access data, and they authenticate as your organization. If your secrets-handling policy doesn't explicitly cover them, it has a gap.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub