Session Inception：啟動無介面的子工作階段，讓儲存庫設定越過信任檢查

將父層客戶端、Bash 程序、子 CLI 以及 hook 所衍生的所有後續程序，全數置於經嚴格驗證的受管虛擬機（MicroVM）或作業系統原生沙箱中，僅提供最小且不含真實憑證的合成環境，嚴格禁止掛載開發者認證或機敏的主機目錄。在第一個程序啟動前就必須徹底剝離所有 secrets，否則子程序在繼承環境變數時仍會造成外洩。必須完整驗證整棵程序樹及其可存取的環境變數範圍；此防護能有效圍堵主機機敏資料的曝露，但若任務刻意將 secrets 注入該環境中，仍存在外洩風險。

在整個沙箱程序樹外層強制執行預設拒絕的網路存取控制，僅放行檢驗儲存庫所嚴格必需的特定對外連線。測試時必須涵蓋攻擊者腳本主機、原始 IP、重新導向與 Proxy 路徑，並特別針對 DNS TXT 記錄查詢與替代解析器進行驗證。一般不受限的 DNS 查詢或僅包覆父程序網頁讀取工具的過濾器，均可能使此類外洩管道暢通無阻。在底層路由完全受控時，此外層防禦可阻斷未經核准的遠端腳本傳送；但本機 hook 是否具備執行信任，仍須仰賴獨立的啟用授權機制判斷。

由組織管理的端點感測器，檢查儲存庫中新建或修改的 .claude/settings.json，使用自訂規則辨識未核准的 SessionStart 命令。G001 範例的 YARA 關鍵字，不能偵測任意 hook 程式碼；必須另外驗證實際 hook 範例、編碼與替代路徑的涵蓋範圍。端點隔離或審查可能在無介面子程序已執行 hook 後才發生，因此只列為補強控制。只有證明產品能同步拒絕寫入或使用，才能宣稱可以預防。受管的 disableAllHooks 或 allowManagedHooksOnly 政策是另一種機制，不能當成這裡對映的內容掃描指引。

在不可被繞過的啟用中介服務驗證確切工作區與啟用內容清單並核准前，必須嚴格維持儲存庫內所有 hook 的停用狀態。進行設定盤點時不得執行任何程式碼；核准判定必須嚴格綁定正規 checkout 身分與 hook 的確切內容雜湊值，一有變更即自動撤銷，且防護範圍必須同時涵蓋子 CLI 程序的啟動與父層目錄切換介面。此項控制需要由受控客戶端或軟體供應商在底層完成整合；研究中 Desktop UI 提示有效，並不代表能涵蓋無介面的子程序呼叫。任何可被原始 Bash 命令直接繞過的前端封裝層，均不足以建立有效的信任邊界。若系統允許無介面模式啟動，必須由儲存庫本身無權竄改的安全通道提供明確的組織層級核准，並嚴密綁定確切工作區、啟用內容雜湊值、客戶端軟體版本、工作負載身分與安全政策。每次受保護的啟用事件均須與獨立的程序及網路觀測日誌相互勾稽，並完整完成包含無介面模式與直接命令呼叫在內的繞過測試矩陣。G003 提供受管政策核准與涵蓋面驗證，仍須搭配 G002 的中介代理與強制執行配接器；單純的證據檢查邏輯本身無法阻止惡意子程序的生成。

要盯著工具呼叫的順序，抓出讓這次攻擊成立的那個轉折：互動式工作階段裡的一次 Bash 呼叫，先切進剛 clone 下來的目錄，再啟動另一個 AI 客戶端，這裡就是 claude -p。先定義儲存庫檢閱任務核准的工具呼叫轉換，把「啟動子客戶端」「啟用 hook」「子程序對外抓取」標成禁止或高風險的轉換，一出現就連同父工作階段、完整命令列與工作區路徑一起發出警示通知。這是偵測：研究中資料在子程序的模型察覺之前就已經送出去了，所以它的價值在於快速分流，以及在所有開發機上找出同樣的模式，不在於預防。