助手遞來一份套件建議，開發者按下同意：工作階段就這樣被借走了

先把日期補上。2026年9月，Mandiant 公開一份調查報告，描述一家未具名 SaaS 業者遭入侵的過程：開發者工作站上的 AI 程式助手工作階段被劫持，攻擊者藉此推薦一個遭污染的 PyPI 套件，開發者接受建議安裝後，資訊竊取程式跟著進駐，GitHub OAuth 存取權杖外流，最後 Shai-Hulud 蠕蟲擴散到約百個內部儲存庫，機密與產品原始碼被搬走。事過一段時間，這份報告在技術社羣被反覆引用，原因很簡單：它把「開發者每天在做的事」變成了攻擊鏈的一段。

攻擊鏈怎麼走：每一次「同意」都是一次交接

把報告描述的過程攤開，會發現它不是什麼新型態的駭客技術，而是對日常習慣的精準利用。

攻擊者先入侵了那家 SaaS 業者，接著盯上開發者工作站上正在使用的 AI 程式助手工作階段。助手推薦安裝外部套件，這在今天的開發現場再平常不過：程式碼寫到一半卡住，丟給助手，它回你一段建議，順手附上「你需要先裝這個套件」。開發者照做。問題在於，那個套件已經被動過手腳。

安裝完成後，惡意程式利用工作階段裡的資訊找到憑證，其中包含 GitHub OAuth 權杖。拿到權杖，等於拿到一把能代表開發者身份行事的鑰匙。攻擊者用它部署 Shai-Hulud 蠕蟲，自動蒐集儲存庫裡的機密、外傳產品專有原始碼。更麻煩的是後續：攻擊者回頭污染了企業官方命名空間下的套件，另一名員工拉取這個「看起來是自己家」的版本，於是出現第二次感染。

這條鏈上每一站，原本都是被信任的：AI 助手被信任、套件管理器被信任、官方命名空間被信任、OAuth 權杖被信任。攻擊者沒有打破任何一堵牆，只是沿著信任的方向走。

這也呼應了先前技術社羣那場 AI 程式碼助手大調查裡的討論：當越來越多人把工作流交給 AI 工具，工具周邊的權限邊界就成為新的檢查重點。可以參考380人投票選AI寫程式幫手那場討論的脈絡。

已知的事實，與還不能下的結論

這裡必須踩個煞車。公開報告有幾件事說得很清楚，也有幾件事完全沒說。

已知部分：受害者是一家 SaaS 業者；攻擊涉及被劫持的 AI 助手工作階段、遭污染的 PyPI 套件、被竊的 GitHub 權杖，以及約百個內部儲存庫的蠕蟲擴散。

未知部分：工作階段最初是怎麼被入侵的，報告沒有交代。因此，把這起事件直接歸因於某個 AI 產品的漏洞、某種特定的憑證外洩途徑，或者開發者操作失誤，都超出了報告能支撐的範圍。同樣地，也不能據此推論所有 AI 程式助手都有相同問題。「約百個儲存庫」是報告裡的約數，不該拿來推算其他組織的風險規模。

能確認的只有一件事：一個已登入、掛著各種權限的工作階段，一旦被濫用，正常工作流程就會變成攻擊的一部分。這句話對所有用 AI 助手寫程式的團隊都成立，與用的是哪一家產品無關。

換個角度想：假設明天失守的是你家的工作階段

報告裡最值得一般團隊帶走的，其實是一個演練題目：假設某個開發工作階段失守，它能摸到什麼？

第一層是工作站本身。AI 助手、IDE 擴充套件、命令列工具、各種外掛，能讀取哪些檔案和環境變數？API 金鑰、長效 OAuth 權杖、雲端憑證，是不是就放在擴充套件伸手可及的地方？如果是，工作站被入侵的影響就不會只停在單一專案。把高敏感憑證移進受控的祕密管理服務、限制不同工具的讀取範圍，是最直接的縮損動作。

第二層是套件來源。內部命名空間的發布權限誰握有？下遊同事拉套件時，有沒有任何驗證機制？Mandiant 案例裡的第二次感染，正是靠官方命名空間的信任度完成的。

第三層是權杖與自動化。GitHub 權杖能讀寫哪些儲存庫？CI/CD 流程裡掛了多少長效憑證？異常讀取或異常發布，事後查得到紀錄嗎？找得到負責查核的人嗎？每項控制如果有名有姓有 log，防線才算存在。

一個實際的做法是把盤點分成兩欄：一欄記錄外部事件的事實，另一欄列自家的假設，例如「我們的助手能不能讀終端機輸出」「環境變數裡有沒有雲端金鑰」。每個假設附上驗證方式，查擴充套件權限、測執行環境隔離、問平臺管理者。假設沒驗證之前，就只是假設。

信任變快了，檢查腳步也要跟上

這起事件真正刺到人的地方，在於它展示了「加速」的代價。AI 助手把開發節奏加快，套件建議、指令執行、權限調用全被壓縮成幾次按下同意。速度本身沒有錯，但每一次加速的交接，都值得問一句：這一步誰在把關？

報告沒有給出萬靈丹，它給的是一張檢查清單的起手式。對大多數團隊來說，與其爭論 AI 程式助手能不能用，不如今晚就打開工具清單，看看那個天天幫你寫程式的助手，究竟能讀到什麼。