開源 AI 編程代理 OpenCode 於十月十七日透過官方帳號披露：前一晚發生與大規模「蒸餾攻擊」相關的安全事故，影響約百分之一點四的 OpenCode Console 用戶；受影響者均為已連結外部模型供應商的帳戶子集，並已於當日早上以電郵通知。第三方報道指通知郵件警告工作區內儲存的 OpenAI、Anthropic 等供應商 API 金鑰或已暴露，社群亦出現未授權用量與帳號被鎖定的指控。來源真實性已核對官方披露原文、產品文件與獨立報道；事故仍在進行，技術細節與實際存取範圍官方尚未公開。

OpenCode／官方：Console 遭與蒸餾攻擊相關安全事故——約百分之一點四用戶受影響；外部供應商 API 金鑰或已暴露

開源 AI 編程代理 OpenCode 於二〇二六年十月十七日經官方帳號公開表示，前一晚發生與「大規模蒸餾攻擊」（large scale distillation attack）相關的安全事故，影響約百分之一點四的 OpenCode Console 用戶。官方強調：已於當日早上以電郵通知全部受影響用戶；若未收到電郵，即不在影響範圍；受影響者為「已連結外部供應商」帳戶子集；事故仍在處理中，暫未能公開更多細節，並正與 Anthropic、OpenAI 及 Google 協調修復。本文已核對官方披露措辭、OpenCode 產品說明，以及獨立科技媒體對通知郵件與用戶反應的報道，並在此說明來源真實性已驗證。

值得先釐清產品邊界：OpenCode 官網將自身定位為可於終端機、IDE 或桌面使用的開源編程代理，並聲稱每月有逾一千六百萬開發者使用；OpenCode Console 則是可選的線上服務（團隊工作區、用量與預算控制，以及把自有供應商帳戶經閘道接入）。今次官方數字與通知，均針對 Console，而非所有僅使用開源代理本體的用戶。

一、事件與官方已知範圍

技術細節

根據獨立媒體 TSN 引述的官方披露全文，OpenCode 聲稱：

事故與大規模蒸餾攻擊相關，發生於披露前一晚；
影響約百分之一點四的 OpenCode Console 用戶；
已全部以電郵通知；未收到電郵者不受影響；
受影響者為已連結外部供應商的帳戶子集；
事故仍在進行，細節暫未能公開，並正與 Anthropic、OpenAI、Google 合作修復。

Notebookcheck 等於十月十七日報道指，用戶收到的通知郵件標題大致為要求採取行動、並提及潛在供應商金鑰外洩；郵件內容指有人未獲授權進入一個「正準備退役的舊系統」（legacy system），並警告工作區內儲存的第三方供應商金鑰（例如 OpenAI、Anthropic）可能已暴露，要求撤銷並更換金鑰、更新相關應用，以及檢查近期用量是否異常。該報道亦轉述社群指出現未授權消費（例如有用戶稱 Anthropic 帳號出現約四百美元異常用量、另有用戶稱 Google 用量約二百歐元且項目被暫停），惟此類金額屬用戶自述，官方並未公布絕對受害人數或確認金鑰確實被盜用的比例。

OpenCode 產品文件說明：Console 允許團隊連接「已自行付費」的供應商帳戶（例如 Anthropic、OpenAI、AWS Bedrock 等），由 Console 保存憑證並經閘道代為呼叫，使成員可使用模型而無須直接看見供應商金鑰。此架構解釋了為何修復需與多家模型供應商協調，但官方披露本身並未明文確認「哪些欄位／憑證已被讀取」。

二、技術原理：為何「蒸餾攻擊」會波及開發者閘道

模型「蒸餾」（distillation）本意是用較大模型的輸出訓練較小模型以模仿其行為。當未經授權、以工業規模蒐集前沿模型回覆（尤其是推理過程）來複製能力時，業界稱為蒸餾攻擊。Anthropic 於十月十二日公開文章指，此類攻擊常透過大量欺詐帳戶與代理網絡進行，並把流量分散到原廠 API、第三方雲端與其他推理供應商；該文亦稱其新防衛措施估計可把蒸餾者採集到的數據量減少約百分之九十至九十九（屬 Anthropic 自身評估，與 OpenCode 事故成因尚未由官方建立公開因果鏈）。

把供應商 API 金鑰集中存放於可選的團隊閘道，本來是為了簡化權限與計費；一旦閘道或相關舊系統被未授權存取，風險會由「單一開發者本機金鑰外洩」放大成「多成員、多供應商憑證可能一併暴露」，並可能觸發未授權推理用量、帳號鎖定或供應商端濫用偵測。蒸餾攻擊者若需要大量、穩定的模型輸出，也有動機盯上這類已聚合多家供應商流量的中介層——惟 OpenCode 仍未公開攻擊路徑與蒸餾行為如何具體連結。

三、日常應用場景

1. 開發者與技術團隊

若團隊曾把 OpenAI、Anthropic、Google 或其他供應商金鑰存入 OpenCode Console（或任何類似「自帶金鑰的代理閘道」），應先假設金鑰可能已暴露：在供應商控制台撤銷並輪替金鑰、檢查審計日誌與異常用量、更新 CI／本機環境變數，並暫時改為本機或私有閘道持有金鑰、避免把長期有效的高額度金鑰集中於第三方 SaaS。僅使用開源 OpenCode 代理、從未連結 Console 外部供應商者，按官方說法不在今次百分之一點四的通知範圍，但仍宜覆核本身金鑰管理習慣。

2. 企業與隱私敏感行業

金融、法律、醫療與受 NDA 約束的企業，若允許員工把生產級 API 金鑰寫入第三方編程代理的雲端工作區，等於把計費權與模型呼叫權交給該服務的安全邊界。事故說明：即使代理本體強調「不儲存程式碼／上下文」，金鑰保管面仍可能獨立成為攻擊面。較穩妥做法是企業自建私有模型閘道、短期權杖、按專案隔離配額，並禁止把主帳戶長期金鑰存入外部 Console。

3. 一般用戶

個人開發者若收到 OpenCode 通知電郵，應立即按指示輪替金鑰並檢查帳單；若未收到電郵，官方稱不受影響，但仍建議開啟供應商用量警報。社群流傳的異常收費數字不宜直接外推為全體損失規模。

4. 香港與亞洲市場視角

香港金融科技、外包與初創團隊廣泛使用雲端大模型 API 與 AI 編程代理。本地團隊常以「自帶金鑰＋開源代理」兼顧成本與彈性，卻容易忽略閘道層的憑證託管風險。金管局等監管框架持續強調銀行與金融業對人工智能的問責與韌性；即使今次事故發生於海外開發者工具，其教訓與香港企業私有化部署、雲端資安與供應商風險管理直接相關：代理愈「好用」，金鑰與權限設計愈要像對待生產憑證一樣嚴格。

四、專業評價與潛在考量

優勢／正面意義

官方相對迅速公開影響比例（Console 用戶約百分之一點四）與通知機制，並劃定「未收電郵＝未受影響」的溝通界線。
點名與 Anthropic、OpenAI、Google 協作，顯示供應商端可能同步處理濫用或金鑰輪替。
突出 Console 與開源代理本體的產品邊界，有助降低「全體開源用戶皆中招」的恐慌性誤解。

需要留意的地方

事故「仍在進行」，官方尚未公開入侵途徑、是否確認金鑰被讀取、以及蒸餾攻擊與系統入侵的技術因果。
用戶自述的未授權金額與登入故障屬旁證，不宜當成已審計損失。
蒸餾攻擊敘事有助理解產業背景，但在 OpenCode 補齊技術報告前，外界不應過度推論攻擊者身份或國家層級動機。
任何「把多家供應商金鑰集中託管」的開發者體驗產品，都需預設高價值憑證保護、退役系統隔離與入侵偵測，否則便利性會轉成單點風險。

結語

OpenCode 十月十七日的披露，把 AI 編程代理生態裡一個容易被忽略的環節推到台前：開源代理可以強調隱私與本機執行，但可選的雲端 Console 一旦託管外部供應商金鑰，安全事件就會直接衝擊企業帳單與模型帳戶。在官方技術細節尚未公開前，最務實的應對仍是輪替金鑰、審計用量、縮小憑證暴露面，並檢視團隊是否應改為私有閘道或地端部署。

若香港企業希望把編程代理、私有模型與雲端防護納入同一套可問責架構，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security），以及企業私有 LLM 全託管方案（https://ysk.hk/services/ai-automation），以降低把生產級 API 金鑰長期存放於第三方工作區的風險。

參考來源

OpenCode 官方帳號披露（二〇二六年十月十七日；全文見 TSN 引述）：https://tsnmedia.org/opencode-console-breach-distillation/
Notebookcheck：OpenCode hacked, users urged to revoke their API keys（二〇二六年十月十七日）：https://www.notebookcheck.net/OpenCode-hacked-users-urged-to-revoke-their-API-keys.1426957.0.html
OpenCode 官網產品說明（開源代理定位與用量聲稱）：https://opencode.ai/
Anthropic：Strengthening our defenses against distillation attacks（二〇二六年十月十二日；蒸餾攻擊背景）：https://www.anthropic.com/research/distillation-defenses
Hacker News 討論串（二手指標，釐清 Console 與開源代理本體區隔；非主要事實來源）：https://news.ycombinator.com/item?id=50133401