AID-H-021.005
極高
AI Coding-Agent Workspace Activation Trust Gate
啟用新工作區或變更過的工作區前，以不執行方式檢查 .git/config 與其他可能帶入命令的設定，顯示完整 activation manifest；在精確的工作區信任決策前，讓 Git 上下文蒐集維持受限。
GitSpawn：程式碼代理程式尚未取得信任，專案庫就能先執行惡意命令
資安團隊 Manifold Security 在評估 7 款主流 AI 程式碼代理工具時，發現了 8 項名為 GitSpawn 的安全漏洞。當開發者透過壓縮檔或共享資料夾開啟一個保留了完整本機 .git 目錄的專案時，Git 在執行 status、diff 或背景收集專案脈絡時，會讀取並執行 .git/config 中設定的 core.fsmonitor 命令；更嚴重的是，這個執行時間點早於 AI 工具跳出「是否信任此工作區」的確認提示。此為受控實驗室驗證，並非真實惡意攻擊事件，且一般透過 git clone 下載的專案預設不會包含此本機設定。
威脅分析
- 專案的交付方式是攻擊成立的關鍵。 GitSpawn 依賴能完整保留 .git/config 本機設定的交付途徑（例如壓縮檔解壓縮或直接開啟共享資料夾）。一般的 git clone 流程並不會下載來源端的本機設定檔。
- Git 底層工具成為突破權限的執行邊界。 當 AI 程式碼代理呼叫 Git 查詢專案狀態或檔案差異時，Git 會自動讀取並執行專案內部的 core.fsmonitor 設定，導致惡意命令以目前開發者的權限在背景悄悄執行。
- 工作區信任提示的出現時機太晚。 研究指出，惡意命令早在 AI 介面顯示「信任提示」之前、且在 AI 沙箱之外就已經執行完畢。因此，使用者事後在畫面上點擊「拒絕信任」也無法挽回先前的命令執行。
- 影響範圍應保持精準界定。 本研究證實的是受測 AI 工具在建立信任前存在程式碼執行漏洞，並未宣稱已發現特定惡意酬載、建立持久後門、或導致特定企業受害。
適用的 1 項 AIDEFEND 防禦手法
身為資安防禦者，我們應該這麼做
- AI coding agent 啟用新建、clone、搬移或變更過的工作區前，以不執行方式檢查 .git/config、hooks、資料夾工作、devcontainer 或 bootstrap 檔案、MCP 命令與本機規則。
- 提供完整的 activation manifest，列出所有能啟動行程或改變 agent 權限的工作區控制行為，並把使用者決策綁定到確切的 manifest 與工作區身分。
- 在啟用 broker 發出僅限啟用的權限前，讓 Git status、diff、fsmonitor 與背景上下文蒐集維持受限；工作區或 manifest 改變時撤銷該權限。
- 把 archive 與共享資料夾等能保留 .git 的交付方式納入回歸測試，確認信任決策前不會執行設定的命令，且命令不會跑到預期的沙箱之外。
1 個額外的防禦考量
部署範圍
研究回報七個 coding agent 的行為，但各產品的受影響版本與修補狀態不同。這項發現不能直接當成所有 Git 整合都有相同觸發路徑的證明。
建議做法: 針對每個已部署的程式碼 agent，在隔離工作區測試一個完整保留 .git/config 的儲存庫，並確認 Git 的 status、diff、fsmonitor 與背景上下文蒐集路徑都受工作區信任檢查保護。
結論
GitSpawn 的核心在於「工作區啟用時的安全檢查順序」，而非單純的惡意程式庫問題。如果 Git 與背景收集機制在使用者做出信任決策前就已具備執行能力，那麼畫面上的信任提示便形同虛設。AIDEFEND 的「AI 程式碼代理工作區啟用信任檢查」提供了具體控制：在不執行任何指令的前提下靜態審查工作區設定、將核准綁定至宣告清單，並嚴格限制啟用前的背景操作。