← 所有文章

AI代理設定的安全，就是供應鏈安全

2分鐘閱讀
From the guide: Claude Code Comprehensive Guide

2026年4月29日，安全團隊通報SAP生態系套件遭入侵。這起事件並未止於憑證竊取。Mini Shai-Hulud攻擊活動還把持久化機制寫進開發者設定：Claude Code掛鉤、VS Code工作，以及儲存庫工作流程檔案。123

這個細節改變了審查邊界。遭投毒的套件只要能在開發者信任的檔案中留下啟動命令，就不必一直留在系統裡。移除相依套件或許能拔掉第一個觸發點，但代理或編輯器設定仍可能讓下一個觸發點繼續存活。

AI代理設定是可執行軟體。每一個掛鉤、工作、MCP伺服器定義、技能、外掛程式、套件指令碼與工作流程檔案，都應視為軟體供應鏈的一部分，因為這些檔案可以在人類讀完差異前，決定要執行哪些程式碼。

重點摘要

Mini Shai-Hulud展示了一條實際路徑：從相依套件安裝，走向開發者工具持久化。安全研究人員通報，惡意npm套件在安裝期間使用生命週期指令碼，收集開發者與CI憑證，並寫入.claude/settings.json與.vscode/tasks.json，讓程式碼能從受信任的開發者介面再次執行。124官方文件也證實，這些底層介面確實具有執行權限：Claude Code掛鉤會執行生命週期命令，命令掛鉤會以使用者權限執行；VS Code的folderOpen工作則可在使用者允許該資料夾自動工作後，於資料夾開啟時執行。56

這裡的教訓不是「關掉代理」。更精準的教訓是：代理設定必須納入相依套件審查、程式碼審查、事件應變與發布關口。過去看似只是本機偏好的隱藏點目錄，如今已位在執行路徑上。嚴謹的AI工程實務需要設定差異審查、掛鉤審查、工作審查、最低權限權杖，以及啟動介面稽核。

關鍵要點

給開發者： - 信任儲存庫前，先審查.claude/settings.json、.vscode/tasks.json、.github/workflows/*、package.json指令碼、MCP設定，以及代理外掛程式或技能清單。 - 把新的啟動掛鉤與資料夾開啟工作，視同新的可執行檔案審查。 - 發生可疑安裝後，移除持久化檔案並輪替憑證。只移除套件，並不能證明清理完成。

給安全團隊： - 將代理設定檔納入供應鏈偵測、CODEOWNERS、機密應變與事件範圍界定。 - 任何PR若新增啟動執行、廣泛shell命令、不透明下載二進位檔，或隱藏於點目錄的酬載，都應標記。 - 優先採用短效發布憑證與唯讀安裝憑證。長效寫入權杖仍是蠕蟲燃料。

給代理平台建構者： - 讓執行介面可見、可審查、可解釋。 - 將載入脈絡的掛鉤，與執行命令的掛鉤分離。 - 為啟動動作、外部網路呼叫與遭修改的設定，提供完整內建的稽核檢視。

Mini Shai-Hulud改變了什麼

針對套件管理器的供應鏈攻擊，早已有熟悉模式。受信任套件收到惡意版本。安裝指令碼執行。酬載竊取權杖。套件登錄庫下架或版本回復，通常要等到若干開發者與CI工作已安裝惡意版本之後才發生。

Mini Shai-Hulud加入了更具代理時代特徵的一步。Endor Labs、Wiz、Socket、StepSecurity與Cloud Security Alliance的報告，都描述了相同的大致輪廓：SAP開發者生態系中的受入侵套件，利用npm安裝時執行，收集GitHub、npm、雲端與CI憑證，並透過開發者工具設定建立持久化。12347

Wiz記錄了一條備援路徑：攻擊者把檔案放進儲存庫，讓未來在Claude Code或VS Code中開啟時，能再次觸發執行。2Endor Labs描述了Claude Code的SessionStart掛鉤，以及一個帶有runOn: "folderOpen"的VS Code工作。1Socket的攻擊活動追蹤器則列出透過.claude/settings.json與.vscode/tasks.json建立持久化，並與npm、PyPI套件入侵並列。3

具體酬載應留在事件報告中，不適合放進一般工程文章。真正持久的教訓是：

舊有供應鏈假設 代理時代的新失效模式
移除遭投毒套件，就能移除觸發點。 掛鉤或工作可能在儲存庫中保留第二個觸發點。
相依套件審查聚焦於套件檔案。 審查必須涵蓋產生的設定、工作流程檔案與隱藏點目錄。
開發者設定只是本機偏好。 開發者設定可能以本機憑證執行程式碼。
CI機密是主要目標。 本機代理工作階段、編輯器與AI工具設定，成為持久化介面。

目標已從單一套件版本，轉向套件周圍的開發者環境。

設定檔變成啟動程式

Claude Code的掛鉤參考文件指出，掛鉤是使用者定義的shell命令、HTTP端點，或LLM提示，會在生命週期事件中自動執行。5同一份文件也說明，SessionStart會在Claude Code啟動或恢復工作階段時執行；安全章節並警告，命令掛鉤會以使用者的完整權限執行。5

VS Code的工作文件提供了另一個執行介面。工作可以將runOn設為folderOpen；使用者允許該資料夾的自動工作後，VS Code會在包含該工作的資料夾開啟時執行。6這個同意提示很重要。相較於在每台機器上靜默執行，它降低了風險。但這不代表該檔案無害。受信任的儲存庫、疲憊的開發者、先前已允許的工作區，或組織政策，仍可能把一次設定變更轉化為程式碼執行。

npm則提供安裝時的橋接點。npm指令碼文件列出，preinstall、install與postinstall都屬於npm ci與npm install的生命週期指令碼；npm最佳實務也說，除非是目標架構編譯，否則作者幾乎不應明確設定preinstall或install指令碼。8

這3個事實形成了攻擊鏈：

  1. 安裝相依套件時，安裝指令碼執行。
  2. 指令碼寫入或修補開發者工具設定。
  3. 編輯器或代理稍後執行已設定的啟動動作。
  4. 開發者信任該工具介面，因為提示或UI看起來像日常工作。

危險之處不在單一功能。安裝指令碼、掛鉤、工作與工作流程都支援正當自動化。真正危險的是信任傳遞。套件安裝不應能靜默定義未來每一次代理工作階段或資料夾開啟時要執行什麼。

審查邊界錯了

多數程式碼審查習慣把原始檔視為主要產物，設定檔則只是輔助材料。當設定檔會執行命令時，這個習慣就會失效。

新的掛鉤應接受與新shell指令碼相同的審查。新的工作應接受與新二進位檔相同的審查。新的MCP伺服器應接受與新網路整合相同的審查。新的套件生命週期指令碼，應接受與測試前會執行的新程式碼相同的審查。

可以使用這張審查表：

檔案或介面 審查問題 忽略時的風險
.claude/settings.json 是否有任何生命週期掛鉤會執行命令、擷取脈絡、傳送資料或修改檔案？ 代理工作階段啟動成為執行路徑。
.vscode/tasks.json 是否有任何工作會在資料夾開啟時執行，或呼叫shell命令？ 開啟儲存庫就可能執行未審查程式碼。
.github/workflows/* 工作流程是否能讀取機密、寫入儲存庫、發布套件，或執行不受信任輸入？ CI把儲存庫寫入轉化為憑證存取。
package.json指令碼 相依套件或PR是否新增了安裝時執行？ npm install變成程式碼執行。
MCP設定 哪些伺服器取得憑證、檔案系統存取或網路可達性？ 工具橋接在未經產品審查下擴大權限。
代理技能或外掛程式 指令是否包含掛鉤、shell存取、網路呼叫或廣泛檔案讀取？ 受信任脈絡變成命令介面。

工具增強代理的執行環境防禦曾主張，強制管控應放在工具呼叫邊界。Mini Shai-Hulud把同一標準往前推了一層。啟動邊界也需要強制管控。

啟動權限需要最低權限

團隊已經會把最低權限套用在API金鑰上。代理設定也需要同樣規則。

Claude Code區分了PreToolUse、PostToolUse與SessionStart等掛鉤事件。5這種區分應該形塑政策。載入靜態脈絡的掛鉤，不應需要shell存取。驗證命令的掛鉤，不應需要網路存取。記錄本機中繼資料的掛鉤，不應需要憑證。

同樣規則也適用於VS Code工作與CI工作流程：

自動化需求 更窄的權限
載入專案脈絡 讀取已知文件並輸出文字。無shell，無網路。
驗證命令 檢查命令參數。不寫入檔案。
格式化已變更檔案 僅寫入符合條件的原始碼路徑。無憑證。
發布套件 只在發布工作流程執行，並需要核准與短效憑證。
翻譯或部署內容 使用範圍受限的執行器與明確的變更路徑。

npm受信任發布文件說明了短效憑證的重要性。受信任發布使用OIDC，讓套件發布不必依賴長效npm權杖；npm也建議在設定受信任發布者後，停用傳統權杖式發布。9npm另建議，若發布使用OIDC，安裝私有相依套件時應使用唯讀細粒度存取權杖。9

這項建議不會消除工作流程風險。若工作流程遭入侵且權限過大，仍可能造成損害。教訓是兩邊都要收窄：短效憑證，以及窄範圍工作流程。

把代理設定當成相依套件

相依套件審查通常問：哪些套件版本變了。代理時代的審查還應該問：哪些執行介面變了。

接受相依套件更新、外掛程式安裝、產生的設定或範本變更前，先檢查：

檢查項目 實務測試
啟動檔案已變更 搜尋新增或修改的掛鉤、工作、啟動指令碼與工作流程觸發條件。
隱藏酬載出現 標記點目錄下的大型新檔案，或看似產生的檔名。
新增網路呼叫 審查任何URL、curl、wget、node fetch、套件下載或遙測目的地。
新增憑證路徑 搜尋.npmrc、雲端設定、SSH金鑰、.env、鑰匙圈、保管庫與CI機密脈絡。
新增shell間接層 審查呼叫sh、bash、node、python、bun或下載二進位檔的命令。
缺少審查負責人 要求代理設定與CI工作流程必須由負責人核准。

重點不是疑神疑鬼，而是分類準確。掛鉤檔案看似設定，行為卻像程式碼。工作檔案看似編輯器設定，卻能啟動shell。工作流程看似發布管線，卻可能接觸憑證。

AI代理安全始於小型軟體從設計角度提出過類似論點：工具越窄，藏錯的地方越少。安全版本的說法是：設定越窄，藏持久化的地方越少。

安全的設定掃描

防禦性審查不需要執行可疑程式碼。先從唯讀檢查開始：

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

這些命令不能證明一台機器是乾淨的。它們只是讓審查者先看過最可能把設定轉成執行的介面。若可疑安裝已經發生，應轉入事件應變，而不是把乾淨的搜尋結果當作保證。

復原需要設定掃描

遭入侵相依套件的事件應變，不應停在解除安裝套件。

建議採用以下復原順序：

  1. 確認受影響套件版本是否曾安裝在開發者機器或CI執行器上。
  2. 凍結該環境，避免它繼續執行更多工作。
  3. 稽核儲存庫中的啟動設定檔，以及家目錄下的代理或編輯器設定。
  4. 移除可疑掛鉤、工作、工作流程、產生的酬載檔案與非預期分支。
  5. 輪替受影響程序可存取的每一項憑證，包括套件權杖、GitHub權杖、雲端金鑰、SSH金鑰與CI機密。
  6. 檢查套件發布者權限與儲存庫寫入權限。
  7. 檢閱工作流程記錄，尋找機密暴露與非預期對外呼叫。
  8. 從乾淨簽出的版本與已知良好的相依套件組重建環境。

GitHub的Actions安全指引支持這項回應中的憑證面：工作流程權杖應採最低權限，暴露後輪替機密，稽核機密處理方式，並考慮要求工作在存取環境機密前先經審查。10GitHub也建議為工作流程檔案使用CODEOWNERS，讓.github/workflows下的變更必須由指定審查者核准。10

請把代理設定加入同一條治理路徑。如果.github/workflows/*因為能接觸機密而需要程式碼負責人審查，那麼.claude/settings.json與.vscode/tasks.json也需要審查，因為它們能在機密附近執行命令。

代理平台應該建構什麼

代理平台與編輯器可以讓啟動權限更明確，進而降低審查負擔。

有用的產品介面包括：

介面 重要性
啟動動作紀錄 顯示工作開始前可能執行的每個掛鉤、工作、外掛程式、MCP伺服器與命令。
設定差異警告 將新的執行路徑與一般偏好變更分開標記。
權限摘要 說明每個啟動動作的檔案系統、網路、憑證與shell權限。
首次執行來源 顯示掛鉤來自使用者、儲存庫、外掛程式、技能、市集或產生的範本。
安全模式 在完成審查前，以停用所有自動執行的方式啟動儲存庫。
審查封包 讓團隊能帶著證據與回復步驟核准設定變更。

這些介面不應仰賴模型讀取JSON檔案後自行判斷。執行環境應直接揭露權限。使用者應能清楚看見「從README載入脈絡」與「工作階段開始時執行shell命令」之間的差異。

MCP工具需要動作層級授權曾主張，持有者權杖驗證必須進一步落實到每個工具、每個角色與每個動作的檢查。代理設定也需要相同形狀：每個啟動動作都應宣告所需權限，而執行環境應強制採用最小可行集合。

實用的本機政策

即使平台尚未把介面做得更好，團隊也可以先從一份小型政策檔開始：

規則 預設值
代理啟動掛鉤 除非已審查且有負責人，否則停用。
編輯器資料夾開啟工作 僅允許用於已記錄的專案設定，不得用於下載酬載。
CI中的套件安裝指令碼 專案可支援時使用--ignore-scripts，或在拋棄式執行器中隔離安裝。
工作流程檔案 必須有CODEOWNERS，預設唯讀權杖，機密需環境核准。
MCP伺服器 首次安裝採唯讀；寫入、管理、匯出、花費與shell工具需明確審查。
技能與外掛程式 啟用前審查來源、發布者、版本、掛鉤，以及檔案／網路影響。
發布憑證 優先使用OIDC或短效憑證；移除未使用的長效權杖。

好的政策會指出檔案與權限。像「小心使用代理工具」這種模糊規則，經不起真實工作。像「沒有負責人審查，不得新增SessionStart命令掛鉤」這種清楚規則，才讓審查者有可執行的依據。

FAQ

AI代理設定真的屬於供應鏈嗎？

是。供應鏈風險跟著執行與信任移動，而不是跟著副檔名移動。若套件安裝、外掛程式、範本或儲存庫變更能修改代理設定，且該設定稍後會執行命令，那份設定就在供應鏈內。

團隊應該禁止Claude Code掛鉤或VS Code工作嗎？

不需要。掛鉤與工作支援正當自動化。團隊應審查、限縮並記錄它們。載入脈絡的掛鉤，與執行shell的啟動掛鉤，不應取得相同信任。

VS Code會在執行資料夾開啟工作前詢問嗎？

VS Code文件指出，使用者第一次開啟含有folderOpen工作的資料夾時，VS Code會詢問是否允許該資料夾的自動工作。6這個提示有幫助，但該工作仍應接受程式碼審查，因為一旦核准，該檔案就成了執行路徑。

npm受信任發布能解決套件入侵嗎？

不能。受信任發布透過短效OIDC憑證，降低長效npm寫入權杖的風險。9團隊仍需要工作流程審查、最低權限、套件監控，以及針對遭入侵儲存庫或惡意安裝指令碼的事件應變。

可疑安裝後，我應該先稽核什麼？

先稽核安裝時指令碼、代理與編輯器啟動設定、工作流程檔案、非預期點目錄檔案、新分支，以及受影響程序可接觸的憑證。接著輪替受影響環境中的憑證。

結語

AI程式碼代理讓設定更強大，也讓設定更危險。

正確回應不是害怕自動化，而是誠實面對執行究竟住在哪裡。只要某個檔案能執行命令、擷取資料、讀取機密、發布套件或改變代理行為，它就應進入審查路徑。

代理設定已跨過這條線。請把它當成程式碼。

參考資料

  1. Endor Labs, “Mini Shai-Hulud: npm Worm Hits SAP Developer Packages,” 發布於2026年4月29日。來源涵蓋受入侵SAP生態系套件摘要、npm安裝時酬載描述、開發者憑證目標、.claude/settings.json的SessionStart持久化、.vscode/tasks.json的folderOpen持久化，以及補救搜尋介面。 ↩↩↩↩

  2. Wiz, “Supply Chain Campaign Targets SAP npm Packages with Credential-Stealing Malware,” 發布於2026年4月29日。來源涵蓋TeamPCP歸因用語、惡意preinstall指令碼行為、開發者與CI憑證鎖定、備援儲存庫投毒、.claude/settings.json、.vscode/tasks.json，以及受影響套件名稱。 ↩↩↩↩

  3. Socket, “Mini Shai-Hulud,” 攻擊活動追蹤器，存取於2026年5月18日。來源涵蓋自2026年4月29日開始的攻擊活動時間軸、跨生態系套件入侵、受影響SAP套件版本、憑證目標類別、透過具發布能力的npm權杖自我傳播，以及透過Claude Code與VS Code設定建立持久化。 ↩↩↩

  4. StepSecurity, “A Mini Shai-Hulud Has Appeared: Obfuscated Bun Runtime Payloads Hit SAP-Related npm Packages,” 發布於2026年4月29日。來源涵蓋已確認遭入侵的SAP套件版本、安裝時preinstall執行、受控執行環境觀察，以及該攻擊活動鎖定AI程式碼代理設定作為持久化與傳播向量的說法。 ↩↩

  5. Anthropic, “Hooks reference,” Claude Code文件，存取於2026年5月18日。來源涵蓋掛鉤生命週期行為、SessionStart語意、設定巢狀結構、命令掛鉤行為，以及命令掛鉤會以使用者完整權限執行的安全警告。 ↩↩↩↩

  6. Microsoft, “Integrate with External Tools via Tasks,” Visual Studio Code文件，存取於2026年5月18日。來源涵蓋runOn: "folderOpen"行為，以及首次自動工作核准提示。 ↩↩↩

  7. Cloud Security Alliance, “Mini Shai-Hulud: Cross-Ecosystem Supply Chain Attack Targets AI Developers,” 研究筆記，存取於2026年5月18日。來源涵蓋跨登錄庫框架、憑證類別、AI工具設定目標、GitHub儲存庫外洩框架，以及審查生命週期指令碼等短期緩解建議。 ↩

  8. npm Docs, “Scripts,” npm CLI 11文件，存取於2026年5月18日。來源涵蓋npm生命週期指令碼、preinstall／install／postinstall在npm ci與npm install期間的執行，以及明確preinstall或install指令碼除目標架構編譯外應屬少見的最佳實務警告。 ↩

  9. npm Docs, “Trusted publishing for npm packages,” 存取於2026年5月18日。來源涵蓋以OIDC為基礎的受信任發布、工作流程專用短效憑證、設定受信任發布者後停用傳統權杖發布的建議、自動來源證明註記，以及私有相依套件安裝的唯讀權杖指引。 ↩↩↩

  10. GitHub Docs, “Secure use reference,” 存取於2026年5月18日。來源涵蓋最低權限工作流程權杖、暴露後機密輪替、機密處理稽核、環境機密審查、第三方action風險、完整SHA釘選指引，以及工作流程檔案的CODEOWNERS審查。 ↩↩

相關文章

Fork Bomb 拯救了我們

LiteLLM 的攻擊者犯了一個實作錯誤。正是這個錯誤，讓 47,000 次安裝在 46 分鐘內被發現。

1 分鐘閱讀

Ralph 迴圈：我如何在夜間運行自主 AI 代理

我建構了一套自主代理系統，搭配停止鉤子、生成預算與檔案系統記憶體。以下是失敗經驗與真正能交付程式碼的方法。

3 分鐘閱讀