9 個 AI 開發平台於 2026 年 10 月披露安全事件，文章整理金鑰輪換清單

重點摘要：根據 Wiz 於2026年10月30日發布的研究文章，2026年10月至少有九個 AI 開發者平台披露安全事故。共同點是攻擊者都在尋找已儲存的環境變數，尤其是能解鎖 AI 模型的變數。被盜金鑰在約30分鐘內就遭到測試，之後更被轉售。如果你的 OpenAI、Anthropic、Bedrock 或類似金鑰儲存在託管或開發平台上，請立即輪替金鑰，再為它設定支出上限，並收窄其權限範圍。下方附有檢查清單。

若是其他月份，單一 AI 平台遭入侵已足以成為當週的安全頭條。本月卻有九宗事件，而 Wiz 的研究人員不得不指出，幾乎沒有人把它們聯繫起來。他們稱之為「Black October」。

這篇文章是寫給開發者和小型團隊，而非保安專家。大多數人都曾把 LLM API 金鑰貼到平台控制面板，因為這是最快讓示範運作的方法。本文會整理目前已確認的情況、攻擊者如何利用金鑰，以及你在接下來一小時內可以採取的行動。

Wiz 列出的九宗事件

以下是 Wiz 列出的事件及其公佈日期：

各宗事件目前已知的情況差異很大。大部分事件仍在調查中，Wiz 表示目前尚未公開的詳細技術資訊佔多數。文章提及的內容如下，並註明是相關公司所述：

• Fireworks、OpenCode 和 Warp通報有「代理程式蜂羣」攻擊的跡象。Andromeda稱其事件是「全行業攻擊」的一部分。
• OpenCode 和 CommandCode明確將其事件歸因於企圖進行「蒸餾」（利用被盜的模型存取權限來訓練或複製模型）。
• Fireworks、Zeabur 和 Lightning AI將根本原因歸於憑證遭存取。Wiz 指出，Lightning AI 先前曾在 Mini-Shai Hulud 行動中遭遇供應鏈攻擊。
• Railway已發布初步報告，並表示相信最初的入侵途徑是「我們的建置基礎設施遭到權限提升」。
• Warp指出根本原因可能與第三方供應商依賴項有關，而OpenCode則指向「舊有系統」。
• Zeabur已發布完整説明。Wiz 表示，該公司將因這宗事件而停止營運。

沒有單一共同漏洞。Wiz 表示，沒有任何單一漏洞或依賴項能把這些攻擊連繫起來。共同模式在於攻擊者的目標：每份公開報告都提到，攻擊者有針對性地搜尋已儲存的環境變數，尤其是可授予 AI 存取權限的變數。

尚未確認：是否有同一個團體策動全部九宗事件。Wiz 沒有這樣聲稱，我也沒有。

為甚麼你的 AI 金鑰現在值得被盜

Wiz 將這波行動與兩種趨勢連繫起來。代理式攻擊讓攻擊者能更快攻陷目標。另一種趨勢是 LLMJacking：被盜的模型存取權限會透過「LLM 中介商」服務轉售。轉售市場能讓被盜金鑰迅速變現，這就是現在有這麼多人在搜尋這些金鑰的原因。

Wiz 亦追查了兩宗企業金鑰遭濫用的後續情況，並判定其中一宗與供應商資料外洩事件有關。兩宗個案都值得細讀。以下是與你自己的設定最相關的數據：

• 很快便有人驗證。兩宗個案中，首次未經授權的呼叫都在供應商通報憑證遭存取後 30 分鐘內發生。有人從住宅 IP 發出單次模型呼叫，並在 1 分鐘的掃描期間測試多個機構的被盜金鑰。
• 個案 A（不受限制的金鑰）：在金鑰完成補救前約 30 小時內，攻擊者發出約 800,000 次 Bedrock 呼叫，其中約 90% 成功。該金鑰的政策允許 global.* 跨區域推理設定檔，將負載分散至不同區域，因此只有約 6% 的呼叫遭到節流。
• 個案 B（受限制的金鑰）：這個金鑰只允許透過 us.* 推理設定檔使用 Bedrock。經銷商池要求 global.*，因此最初有數千次呼叫失敗。之後，檢查工具找出可用的 us.* 模型 ID；在約 13 小時內，單一地址發出約 1.7 百萬次呼叫，其中超過一百萬次成功。其餘大部分呼叫都受到帳戶區域配額限制而遭節流。
• 成本：Wiz 估計，按牌價計算，單是這兩宗個案的用量費用很可能已超過 $100k。

個案 B 並不能證明限制設定可以讓你免受影響。限制沒有阻止濫用，只是拖慢了攻擊，而區域配額則限制了其規模。正確看待權限範圍設定的方式是：它能限制被盜金鑰造成的損害，但你仍須迅速輪換金鑰。

Wiz 亦提到社交媒體上有一些影響報告，但只是軼聞：有人聲稱利用儲存在 Railway 的加密貨幣金鑰，盜取了約 $371,000 的加密貨幣；另有被盜用的 AI 存取權限（例如來自 OpenCode）導致消費者收到數百至數千美元的帳單。這些應視為相關報告，而非經確認的總額。

Northflank 的建議適合作為所有人的預設做法

Northflank 是名單上最近發生事故的平台，並在本月提供了我見過最清晰的客戶指引。其狀態頁面告知所有客戶，應假設所有環境變數均已被解密，並輪換所有項目：工作負載上的機密資料、機密羣組和全域機密資料。該頁面亦建議停用資料庫附加元件的公開存取權，並表示已有多名用戶確認其 AI 金鑰曾被使用。之後的更新則告知客戶，應向發出憑證的供應商撤銷憑證（而非只在 Northflank 更改憑證），並檢查 AI 供應商的用量及帳單記錄，留意異常活動。

即使你不是 Northflank 客戶，這個建議也適用。若儲存環境變數的平台披露事故，安全的做法是先假設其中每項資料都已外洩。先輪換金鑰，再作調查。

金鑰輪換清單（今天就做）

先檢查所有存有 AI 金鑰的平台：託管平台、CI、筆記本服務、Agent 平台和編碼工具。

1. 建立清單。列出每一個 AI 金鑰（OpenAI、Anthropic、Bedrock/IAM、Google、Mistral、OpenRouter 等），並記下金鑰存放在哪個平台和哪個環境。如果無法確定金鑰存放在哪裏，就假設它存放在上述其中一個平台上。
2. 先建立替代金鑰。在供應商處建立新金鑰，更新平台中的機密資料，然後重新部署。確認應用程式正常運作。
3. 在供應商端撤銷舊金鑰。只從平台刪除並不足夠，因為攻擊者已經取得副本。必須在簽發金鑰的地方撤銷。
4. 其他非 AI 機密資料也要處理。包括資料庫 URL、付款金鑰、雲端憑證、Webhook 簽署密碼及加密貨幣錢包金鑰。Northflank 所説的「全部輪換」同樣適用於此，而 Railway 的報告顯示，攻擊者會拿走找到的任何資料。
5. 查看用量及帳單記錄。留意不熟悉的模型、地區或 IP、在異常時段出現的流量，或輸出 token 數量突然增加。在 Wiz 的案例中，洪水般的流量湧入前，數天來只有零星的驗證呼叫，因此即使只是少量異常用量，也值得留意。
6. 舉報濫用行為。通知供應商及平台。有些供應商可協助處理欺詐性用量，但必須盡快舉報。
7. 記下日期。在機密資料清單中記錄每次輪換的日期，這樣下次發生事故時只需十分鐘，而不是花上整個下午。

開支上限與權限範圍受限的金鑰：把 AI 金鑰當作付款卡看待

被盜的 AI 金鑰就像一張沒有消費上限的付款卡。因此，要為它設下限額。

• 設定供應商提供的最嚴格開支上限。大多數 AI 供應商的控制台都設有每個專案或工作區的預算、限額或提示。硬性上限勝過提示，而能叫醒人的提示也勝過月底帳單。限額應接近實際用量，而不是高出 10x。
• 每個應用程式、每個環境使用一把金鑰。正式環境、預備環境和週末製作的原型不應共用同一把金鑰。當其中一把外洩時，你只需輪換那一把，也能準確追查相關用量來自何處。
• 限制可用的模型和地區。在 Bedrock 上，使用 IAM 政策，只允許應用程式會呼叫的特定模型及推理設定檔。案例 B 顯示了這樣做的效果：區域配額延緩並限制了濫用行為，避免其擴散至全球。
• 盡可能使用短期有效的憑證。透過工作負載身分識別或 OIDC 角色承擔方式存取雲端模型，就無須在環境變數中放置可被竊取的長期金鑰。
• 盡可能避免把金鑰存放在平台上。如果平台支援在執行階段從專用機密管理服務提取機密資料，就使用這種方式，讓平台只保存參照，而非實際值。

我們如何處理自己的專案

在我們自己的客戶專案中，正式環境的 AI 金鑰會存放在雲端供應商的機密管理服務，而不是逐一貼到各個控制台。每個環境都使用獨立金鑰，而每個供應商帳戶都會設定預算提示。當我們使用的平台公佈事故時，我們會先輪換，再調查。本月最有幫助的做法，是以書面記錄每把金鑰的存放位置。輪換只需幾分鐘，找出金鑰在哪裏才是最費時的部分。

仍未有答案的問題

• 這些事故是否由同一個操作者所為。Wiz 將轉售基礎設施與至少一宗入侵事件中的金鑰連繫起來，但表示無法確定轉售者是否與最初的入侵有關。
• 九個平台中大多數平台的事故根本原因。據 Wiz 指，只有 Zeabur 發布了完整報告，而 Railway 發布了初步報告。
• 客戶金鑰總共被盜取了多少。至今沒有平台公佈這個數字。

如果各平台發布更詳細的報告，我會更新本文。

你的 AI API 金鑰目前存放在哪裏？

老實説：目前有多少個控制台存有你的 OpenAI 或 Anthropic 金鑰副本？你有沒有為其中任何一個設定支出上限？在留言區告訴我。我很好奇，這個月有沒有改變任何人儲存這些金鑰的方式。