【2026 最新】OpenCode BYOK 金鑰外洩處理：分清本機與 Console，六步撤銷、重接與用量核對

看到 OpenCode 的安全事件，你第一個念頭可能是：「我也用過它，是不是所有金鑰都要重設？」這篇 OpenCode BYOK 金鑰外洩處理教學，先帶你找到憑證住在哪裡，再完成撤銷、重接與用量核對。別急著把一串新秘密貼回原本的位置。

本文專為第一次處理 API Key 事故、願意跟著介面與幾個指令操作的讀者寫。API Key 像一張能記帳的門卡；BYOK（Bring Your Own Key，自帶金鑰）在這裡指你把模型供應商的金鑰交給工具使用。重點不是背資安術語，而是知道誰拿著哪張卡、能向誰記帳。

查核截至 2026 年 10 月 18 日。OpenCode 在 10 月 17 日官方聲明確認發生安全事件，自報影響 1.4% 的 Console 使用者，並表示已寄信通知、事件仍在處理。這個比例是官方當時的說法；它不能替你判定某一把金鑰是否曝險。以下是依官方文件整理的復原流程，並非 AlphaLab 在受害帳戶上的實測。

先說結論：OpenCode BYOK 金鑰外洩處理，先找發卡公司

復原＝舊卡作廢＋新卡接對＋帳單核對。刪掉工具裡的一張卡片照片，與到發卡公司註銷卡片，是兩個動作。把這個差別記住，就比較不會把「已登出」誤當「攻擊者手上的副本已失效」。

• 曾把供應商金鑰存進 Console：先在原供應商盤點與撤銷確認曝險的金鑰，再決定可信的新連線。
• 只在本機或自管伺服器設定：核對版本、伺服器位置、實際端點與是否重複使用同一把金鑰，別只靠「我用 CLI」判斷。
• 透過訂閱授權或 Console 自有金鑰：各自有不同的撤銷與計費位置，要分開處理。

原理：同樣打開 OpenCode，背後可能是四條路

把 OpenCode 想成叫車介面，模型供應商像車隊。你可以直接向車隊付錢，也可以交給平台代叫。外觀一樣，付款憑證的持有人卻不同。先沿連線追查，別用應用程式名稱代替證據。

①「自己保管門卡」：本機或自管伺服器直連

你在 OpenCode 選供應商，輸入該公司的 API Key；請求由執行模型連線的伺服器送出。V2 憑證文件記載，儲存的 API Key 與 OAuth Token 位於伺服器 SQLite 資料庫；環境變數則從伺服器程序讀取。換句話說，終端機開在你的筆電，仍要確認它連的是本機伺服器，還是遠端服務。

②「平台代刷你的卡」：Console 託管 BYOK

依 Console Providers 文件，管理者可在工作區連接供應商；Console 儲存憑證，經閘道替成員轉送請求。這裡至少有兩層身分：客戶端連工作區的憑證，以及 Console 連供應商的金鑰。撤銷其中一層，不代表另一層也完成撤銷。

③「登入後領通行證」：訂閱／OAuth 授權

OAuth 是透過供應商授權頁登入，再讓工具取得 Token 的方式；它不是在金鑰欄貼一段 API Key。先看 /connect 所選的驗證方法，再辨認帳號與授權。若這條授權有異常，從供應商的已連接應用程式或授權管理處置，並清理客戶端帳號；不要把刪 API Key 當成所有登入方式的共同解方。這也不代表任何訂閱登入已被本次事件確認波及。

④「用平台的額度」：Console 自有金鑰

Console Models 文件描述的是登入、儲值、取得 Console API Key，再接到 OpenCode 的路線。這把卡由 OpenCode 發出，與你交給 Console 的上游供應商金鑰分開列帳。盤點時，請把「Console 發的 Key」與「存進 Console 的 Key」寫成兩列。

OpenCode BYOK 金鑰外洩處理：六步完成一輪復原

第一步「列出門卡」：只記識別資訊，先停可疑工作

不知道從哪裡開始？先做一張不含秘密的清單。每列記供應商、組織／專案、金鑰名稱或遮罩識別碼、建立日期、使用位置、預期端點，以及「確認曝險／待確認／已復原」。例如 OpenAI｜測試專案｜console-old-…7Q2｜Console 工作區 A｜確認曝險；這是一列虛構示例，不是一把可使用的金鑰。

在自己的終端機執行 opencode --help、opencode auth --help，再用 opencode auth list看連線。版本可從應用程式資訊或本機 help 支援的版本旗標記下。只抄帳號標籤與驗證類型，不公開完整輸出；到 Console 的 Providers 核對另一份清單，並檢查 CI、容器與部署服務是否共用同一把金鑰。官方 Commands 文件可核對目前的命令語法。

先暫停會持續使用可疑金鑰的排程與工作。若同時懷疑裝置感染，改從可信裝置處置帳戶，再回頭清理原設備；這是另一條事故線，可接著看 Session 遭竊與端點復原。完成標準是：每一把待處理憑證，都能對上擁有者與發卡公司。

第二步「去發卡公司作廢」：撤銷已確認曝險的金鑰

只按 Console 的 Remove 就夠嗎？把上游撤銷當成獨立步驟。OpenCode 文件把 Disable 描述為隱藏模型並保留設定，Remove 則刪除平台上的供應商與模型；要處理別人可能持有的供應商金鑰副本，應回原供應商撤銷。

• OpenAI：從自己保存的官方入口進入 API 平台，核對組織、專案與金鑰識別資訊，撤銷對應金鑰。官方安全文件要求對疑似外洩或遭濫用的 Key 及時撤銷並替換。
• Anthropic：到 Claude Console 的 API Keys，核對金鑰，開啟三點選單，選 Delete API Key；官方應變說明建議疑似遭竊時立即撤銷，再於同頁建立新 Key。
• Google：在對應 Google Cloud 專案的 APIs & Services → Credentials核對並刪除該 API Key。依 金鑰管理文件完成刪除確認；若使用管理 API，則按 DeleteKey 文件核對長時間作業完成狀態。

這裡選的是「已確認曝險，先止血」的處理順序，可能中斷依賴它的工作；先把受影響服務記下，再用新金鑰恢復。例行、未曝險的零停機輪替，可以另設交接窗口；不要為了保持可疑工作持續執行，拖延事故撤銷。記下撤銷時間與時區，保存遮罩後的確認畫面。

第三步「換卡也換保管位置」：建立最小權限的新憑證

新卡要放回哪裡？先選可信的連線，再建立替代憑證。事件仍在處理時，保守做法是暫停向待釐清的託管路徑交付新秘密；已有可管理的本機或自管直連路線，就先在那裡恢復必要工作。尚未釐清時，維持暫停也是完成止血的一種結果。

為這次連線建立專用 Key，使用可用的專案隔離、權限限制與支出控制；哪些控制會阻擋請求、哪些只發通知，要分別確認。名稱可用 opencode-recovery-20261018，讓後續用量較容易追查。把真值存進秘密管理工具或客戶端的安全輸入流程；不要交給聊天模型幫你填，也不要寫進截圖、Git、工單或一行含明文的終端機命令。一般防護可再讀 AI Agent 密鑰與 Context 安全。

第四步「接回正確車隊」：核對伺服器、端點與驗證方式

看到回答就代表走對嗎？先把路線寫成可核對的設定。確認執行請求的伺服器位置、provider、模型與 Base URL（API 的目的位址）。V2 的 Provider 設定使用 providers與 settings.baseURL；不要把 V1 的設定片段整段覆蓋進 V2。

直連時，在 /connect選實際供應商與 API Key 方法，透過互動輸入新 Key，再用 /models選模型。若恢復 Console 託管，應先完成你對服務復原狀態的核實，再由工作區管理者於 Providers 的 credential 欄替換；官方文件也列有 Test connection。這個按鈕檢查連線，不能代替事故是否已解除的判斷。

若需要更新客戶端，先看官方變更紀錄與 opencode upgrade --help，按原安裝方式選擇版本；把升級前後版本與部署設定差異記下。不要為了事故復原順手跨越主要版本，也不要把升級客戶端當成上游金鑰已撤銷的證據。

V2 中，已儲存帳號會優先於同一整合的環境變數連線；環境變數來自執行請求的伺服器程序。只改筆電上的變數，可能改不到遠端伺服器。完成標準是：你能指出這次啟用的是哪一個帳號、哪個驗證方法，以及預期經過的每一站。

第五步「分開考兩張卡」：舊卡失效與新路線成功

怎麼知道真的完成？留下兩項分開的證據。第一項是原供應商的撤銷紀錄。若你已有安全保留、明確指定舊 Key 的測試客戶端，可對原供應商做一次最小驗證並保存脫敏結果；別把舊 Key 複製回不明閘道。已刪除舊值，就保留撤銷紀錄，不為了測試去復原或重新啟用它。

失敗也要讀原因。以 OpenAI 錯誤碼文件為例，驗證失敗可能是 Key 無效、過期或已撤銷；額度／速率限制則是不同問題。一次 401 要與正確的舊 Key、端點及撤銷紀錄合看；429、網路逾時或模型權限錯誤，都不足以單獨證明舊 Key 已作廢。

第二項才是新路線測試。在空白、無敏感資料的測試專案，明確選新帳號與模型，送出「只回答：連線成功」。這一步可能產生少量費用。記下時間、provider、模型、設定端點與可取得的 Request ID，再到供應商用量核對對應請求。設定裡寫了某個端點，與請求確實到達那裡，是兩張不同的證據。有閘道時另對其紀錄；排查設定時不要開啟會印出 Authorization 標頭的除錯輸出。

第六步「把帳單接回事件」：用量、費用與殘留設定

新回答正常，事故就結束了嗎？再做一次用量對帳。到原供應商檢查事件前後的組織、專案、模型、時間與費用；可依 Key 篩選時，分開看新舊金鑰。Console BYOK 的上游 Token 由供應商收費，平台另記錄請求與依設定價格估算的成本；因此不要只看 Console 餘額判斷是否有異常。

保存不含秘密的用量匯出、費用畫面、撤銷收據與客服案件編號。發現不認得的活動，就帶時間區間、遮罩識別資訊與請求紀錄聯絡供應商及 OpenCode；退款與事件歸因要各自取得結果，不預設一定退費。後續再次核對時，區分「較晚出現的歷史用量」與「撤銷後仍有新請求」，需要服務商協助的就保持待確認。

最後檢查其他電腦、CI Secret、容器環境與工作區設定，移除舊值並恢復必要服務。V2 可透過 /connect刪除已儲存帳號；環境變數連線要從實際伺服器的環境移除，不能只做 auth logout。這些是清理殘留，仍要和第二步的原供應商撤銷分開記錄。

走完一個例子：一把 Key 同時用在 Console 與 CI

假設阿晴確認收到與工作區相符的通知，也查到名為 shared-old的供應商 Key 曾存進 Console；同一把還給 CI 使用。她先暫停 CI，記下專案、遮罩識別資訊與通知時間，接著在供應商撤銷它。兩個使用位置，共用同一個失效邊界。

接著，她為 CI 與可管理的直連測試各建專用新 Key，分別更新各自的秘密儲存位置。用無敏感文字做最小測試後，保留兩份請求與用量紀錄；Console 路線仍待復原核實，就維持暫停。這時她的狀態是「舊 Key 已撤銷、CI 已恢復、Console 待確認」，比一句「全部修好了」更能指導下一步。這是流程示例，不是本次事件的受害者紀錄。

常見坑：最容易把復原做成第二次曝險的三件事

• 只看用的是 CLI，便宣布本機安全：還要查執行請求的伺服器、代理端點、託管設定與重複使用的 Key。連線位置可搭配 Coding Agent 出站流量稽核一起盤點。
• 照舊教學直接打開憑證檔：V2 的資料庫儲存與 V1 舊檔案不同，先看版本文件與管理命令。不要把整份 auth.json或資料庫交給模型分析。
• 為了留證保留完整秘密：收據保存時間、動作、金鑰名稱、遮罩 ID 與案件編號；真值另行安全管理。也不要點通知信裡的不明「修復工具」，改由自己核對過的官方入口處理。

OpenCode BYOK 金鑰外洩處理 FAQ：八個直接答案

1. 所有 OpenCode 使用者都確認受影響嗎？

官方當時公告的是部分 Console 使用者。本文讀到的聲明自報 1.4%，不是所有 CLI 安裝者的鑑識結論；個人應對仍要看工作區通知與自己的憑證流向。

2. 沒收到信，能把所有金鑰都標成安全嗎？

先核對工作區與管理者。信箱、垃圾郵件、管理者通知及實際存放位置要對上；這份盤點也能找出與本次事件無關的重複使用或其他異常。

3. 在 Console 按 Remove，算撤銷供應商 Key 嗎？

應分開完成。平台文件描述的是刪除平台上的供應商設定；原供應商的金鑰撤銷與確認紀錄，要另留一筆。

4. 我用 OAuth，也要去刪 API Key 嗎？

先辨認憑證種類。OAuth Token、API Key 與 Console Key 分列管理，依異常發生的那條授權撤銷；不要以刪另一種憑證代替處置。

5. 可以直接把新 Key 貼回 Console 嗎？

先核實託管路徑的復原狀態。本篇的保守流程在未釐清時維持暫停，或用已可管理的替代連線恢復必要工作；新秘密的保管位置也需要驗收。

6. 舊請求得到 429，就表示撤銷成功？

不足以證明。它可能是額度或速率限制。核對撤銷紀錄、舊 Key 指定方式與驗證錯誤類型，並排除客戶端自動改走其他帳號。

7. 新帳號能回答，就代表端點完全核對了？

還要對請求紀錄。把選用帳號、設定端點、測試時間與供應商用量接起來；有代理或閘道時，逐站核對自己的可見紀錄。

8. 今天最少應完成什麼？

一份清單與一張撤銷收據。確認曝險的 Key 先在原供應商作廢；新連線尚未驗收，就標為待恢復，不急著重啟所有自動化。

給新手的三個重點

1. 先問「哪一張卡、誰發的、放在哪裡」，再決定去哪裡撤銷。
2. 舊 Key 失效、新連線成功與費用釐清，分成三個完成條件。
3. 每一步留下遮罩證據，讓下一位接手的人知道哪裡已恢復、哪裡仍暫停。