工具增強型代理的執行期防禦

一週前，我發表了橫跨 SSRF、工具投毒及信任繞過模式的 50 個 MCP 漏洞。隱含的結論令人憂心：攻擊面的擴張速度遠超稽核能力。Wei Zhao、Zhe Li、Peixin Zhang 與 Jun Sun 共同發表的一篇新論文提出了結構性解方——而同週發生的一起真實遙測事件，恰好印證了這個解方為何至關重要。

ClawGuard 於4月13日發表在 arxiv，是一個執行期安全框架，在每個工具呼叫邊界執行使用者確認的規則集。¹ 在其評估配置中，該框架套用基本的存取控制規則——阻擋未授權的檔案存取、防止憑證外洩、限制網路呼叫——所有這些都在任何外部工具調用之前完成。無需修改模型、無需變更基礎架構、無需針對安全的微調。¹ 作者在 AgentDojo、SkillInject 與 MCPSafeBench 上使用五個最先進的 LLM 進行了測試。¹ 論文還描述了一個任務專屬的規則推導元件，可從使用者陳述的目標自動衍生約束條件，但此元件並未納入評估配置。

最關鍵的主張：ClawGuard 將依賴對齊的防禦轉化為確定性、可稽核的機制。¹

為何對齊不是安全邊界

我上週彙整的許多 MCP 漏洞都利用了一個共同的結構性缺口。代理從工具描述、擷取的網頁或技能檔案接收指令——而在注入與執行之間，唯一的屏障就是模型區分合法指令與對抗性指令的能力。（部分漏洞如 SSRF、RCE、路徑穿越等利用的是伺服器端缺陷，不依賴模型的指令遵循，但工具呼叫邊界對防禦而言仍然關鍵。）

對齊訓練有所助益。RLHF 使模型更傾向拒絕有害請求。然而「更傾向」並非安全屬性。一個能拒絕 99% 提示注入的模型仍有 1% 的失敗率，而掌控輸入的攻擊者可以反覆嘗試直到那 1% 命中。工具投毒模式甚至不需要模型失敗——被投毒的描述讓惡意行為看起來就像預期操作。

執行期攔截在完全不同的層級運作。在執行前檢查工具呼叫的鉤子或策略引擎，不依賴模型是否理解了攻擊。檢查是確定性的：呼叫是否符合允許集合？符合或不符合。

三種注入管道，一個執行點

ClawGuard 為工具增強型代理識別出三種攻擊管道：¹

網頁與本機內容注入。 代理讀取包含對抗性指令的網頁或本機檔案，指令引導代理以使用者未預期的方式呼叫工具。靜默外洩攻擊面就是此模式的一個實例——外洩指令隱藏在擷取的內容中。

MCP 伺服器注入。 遭入侵或惡意的 MCP 伺服器在工具描述或回應酬載中嵌入指令。代理將這些指令視為上下文並據此行動。上週的 50 個漏洞目錄詳盡記錄了此管道。

技能檔案注入。 對抗性指令被放置在代理以受信任上下文載入的技能檔案與設定中。代理將技能檔案內容視為權威來源——能寫入技能檔案或設定的攻擊者可以操控代理的行為。

防禦架構將執行放在工具呼叫邊界——這是所有外部動作都必須通過的單一節點，無論注入來自哪個管道。¹ 在代理調用任何工具之前，ClawGuard 會根據使用者原始任務衍生的約束條件檢查呼叫。超出約束範圍的呼叫會被阻擋，不論注入提示有多具說服力。

這個架構洞見值得直白陳述：如果能在執行邊界執行策略，就不需要偵測每一次注入。

Vercel 遙測事件

ClawGuard 論文發表前四天，Akshay Chugh 於4月9日發布了關於 Vercel Plugin for Claude Code 的揭露。² 揭露時的發現：

該外掛註冊了鉤子，將 bash 命令字串傳送至 telemetry.vercel.com。² 儲存在 ~/.claude/vercel-plugin-device-id 的持久 UUID 將這些命令字串繫結到特定裝置。² 外掛在鉤子上使用空字串匹配器，意味著鉤子在所有專案上觸發——不僅限於 Vercel 專案。² 同意機制使用提示注入而非原生 UI 來獲取使用者同意。² 除非使用者設定 VERCEL_PLUGIN_TELEMETRY=off，否則遙測在每次匹配事件時觸發。²

Vercel 於4月14日回應了遙測疑慮，移除了寬泛匹配器與基於提示的同意機制。²

Vercel 事件就傳統意義而言並非漏洞。沒有人在竊取憑證。但它確切展示了執行期防禦所針對的問題類別：一個觸發範圍超出使用者預期的鉤子，蒐集使用者未明確同意分享的資料，透過繞過原生同意 UI 的機制運作。

將「遙測」換成「外洩」，架構完全相同。一個匹配器過於寬泛的鉤子，在每個專案上執行，將資料傳送至外部端點。遙測與攻擊之間的差異在於意圖——而意圖在執行期是不可稽核的。

從論文到實務：從業者既有的工具

ClawGuard 將從業者一直在非正式建構的東西形式化了。Claude Code 內建支援 PreToolUse 和 PostToolUse 攔截的鉤子系統。我執行了超過 95 個鉤子來強制檔案路徑限制、驗證工具輸入，並將破壞性操作置於明確確認之後。³

我的鉤子與 ClawGuard 願景之間的差距在於自動化。我的鉤子是手寫規則：阻擋 MCP 輸入中的內部 IP 位址、限制檔案寫入僅限專案目錄、要求 git force-push 的審批。已評估的 ClawGuard 配置使用的基本存取控制規則在精神上類似手寫鉤子。論文提出的任務專屬規則推導元件會從使用者陳述的目標自動衍生約束條件¹——不再需要撰寫「阻擋寫入 /etc」，框架會推斷描述為「重構登入模組」的任務不應需要系統目錄的寫入權限。該元件仍屬未來工作。

自動約束衍生是更困難的問題——ClawGuard 的任務專屬規則推導元件屬於未來工作，並非已評估的成果。作者實際評估的基本規則配置展現了強勁但並非完美的結果：AgentDojo 達到 0% 攻擊成功率（ASR），但 SkillInject 仍有 4.8-14% ASR，MCPSafeBench 則根據模型呈現 7.1-11.0% ASR。¹ 手寫規則具有脆弱性——僅涵蓋您預料到的攻擊。衍生約束則可能涵蓋未預料的攻擊，因為它們基於正集合（應該發生的事）而非負集合（不應發生的事）運作。

自動衍生是否能在生產環境中可靠運作仍是開放問題。基準測試是受控環境。真實的代理會話涉及模糊的任務、多步驟工具鏈，以及看似異常但實際合理的工具呼叫。阻擋有效工具呼叫的誤報會迅速侵蝕「不犧牲代理效用」的主張。

分層防禦堆疊

執行期防禦不是單一機制。工具增強型代理的實務堆疊至少包含四個層級：

第一層：輸入驗證。 在執行前檢查工具呼叫參數的鉤子。阻擋內部 IP 位址、驗證檔案路徑、拒絕 shell 元字元。我的 PreToolUse 鉤子運作在此層級。誤報率低，但僅能捕捉已知的惡意模式。

第二層：任務範圍約束。 將允許的工具集和允許的參數限制在當前任務所需的範圍內。ClawGuard 主要運作在此層級。¹ 覆蓋範圍大於單獨的輸入驗證，但需要準確的任務理解。

第三層：輸出檢查。 PostToolUse 鉤子在代理處理工具結果之前進行檢查。捕捉資料外洩、偵測異常回應、標記非預期的工具行為。中間人文章記錄了為何輸出檢查很重要——遭入侵的路由器在生成後修改回應。

第四層：會話稽核。 記錄每個工具呼叫、每個參數、每個結果以供事後審查。並非預防機制，而是偵測機制。Akshay Chugh 正是透過這種稽核發現了 Vercel 遙測事件——閱讀鉤子設定並追蹤鉤子的行為。²

沒有任何單一層級是充足的。輸入驗證會遺漏新穎模式。任務範圍約束可能過於嚴格或過於寬鬆。輸出檢查增加延遲。會話稽核在損害發生後才能發現問題。堆疊之所以有效，是因為每一層都覆蓋了其他層留下的缺口。

ClawGuard 做對了什麼

這篇論文對從業者有三項重要貢獻：

確定性優於對齊。 將執行期防禦定位為確定性機制而非對齊屬性，是正確的框架。對齊是訓練時屬性，在對抗條件下會退化。確定性執行是執行期屬性，不受模型行為影響而維持。這個區別聽起來很學術，但它改變了您能對系統安全態勢做出的承諾。

管道無關的執行。 以單一執行點防禦網頁注入、MCP 注入和技能檔案注入，在架構上是合理的。三個注入管道分別三套防禦會造成維護負擔，並在交叉點留下缺口。工具呼叫邊界的單一執行點在結構上涵蓋所有三個管道。

無需修改模型。 既不需要微調也不需要架構修改，意味著防禦適用於任何模型，包括您無法控制的模型。執行 Claude Code、Codex CLI 或任何其他代理框架的營運者，無需等待模型供應商發布安全更新即可新增執行期防禦。

尚待解決的問題

ClawGuard 在基準測試上進行了驗證。生產環境的代理會話更為混亂。在從業者能夠依賴自動約束衍生之前，仍有數個問題待解：

模糊任務。 「幫我處理這個專案」未指定哪些工具或路徑在範圍內。從模糊目標衍生約束，風險在於要麼阻擋合理呼叫（過於嚴格），要麼放行危險呼叫（過於寬鬆）。

多步驟鏈。 需要讀取設定檔、呼叫 API、並將結果寫入資料庫的代理，具有複雜的存取模式。從初始任務描述衍生的約束可能無法預見中間步驟。

對抗性任務描述。 若約束衍生依賴使用者陳述的目標，能控制任務描述的攻擊者（透過共享工作空間、被投毒的議題追蹤器或被操縱的專案檔案）就能影響約束本身。

效能成本。 在每個工具呼叫邊界評估約束會增加延遲。論文聲稱框架保持了效用，但未報告延遲量測。¹ 對互動式代理會話而言，即使每次工具呼叫僅增加 200ms 也會改變使用者體驗。

實務要點

對於目前正在執行工具增強型代理的從業者：

立即部署 PreToolUse 鉤子。 不必等待 ClawGuard 或任何其他框架。Claude Code 的鉤子系統今天就支援工具呼叫攔截。從輸入驗證開始——阻擋內部位址、限制檔案路徑、管控破壞性操作。鉤子教學涵蓋了實作方法。

稽核您的鉤子匹配器。 Vercel 事件的發生正是因為空字串匹配器在所有專案上觸發。² 檢查 .claude/settings.json 中的每個鉤子，確認每個匹配器僅針對預期的上下文。匹配器過於寬泛的鉤子是隱患，而非防禦。

記錄每次工具呼叫。 會話稽核是投入最少、價值最高的防禦層。即使無法防止每次攻擊，事後仍可偵測——但前提是您有日誌。

以您的堆疊評估 ClawGuard。 論文的程式碼已公開。以您現有的鉤子堆疊評估基本規則配置。若任務專屬規則推導元件成熟，自動約束衍生將補充手寫規則，而非取代它們。

將設定視為信任邊界。 技能檔案、鉤子設定、MCP 伺服器定義——每個影響代理行為的檔案都是攻擊面。應套用與生產環境憑證相同的存取控制。

MCP 漏洞目錄記錄了攻擊面。ClawGuard 提出了防禦架構。Vercel 事件則說明了兩者為何重要。工具呼叫邊界的執行期防禦是可執行的安全層——不是因為對齊沒有幫助，而是因為執行不依賴於它。

來源

常見問題

ClawGuard 與 Claude Code 的內建權限系統有何不同？

Claude Code 的權限系統在工具層級要求使用者核准——批准或拒絕特定工具類別。ClawGuard 則在參數層級運作，根據當前任務自動衍生工具呼叫應包含哪些參數的約束條件。兩種機制互補：權限管控哪些工具可以執行，執行期約束管控這些工具如何被呼叫。

需要等到 ClawGuard 發布才能新增執行期防禦嗎？

不需要。Claude Code 的鉤子系統今天就支援 PreToolUse 和 PostToolUse 攔截。驗證工具輸入的手寫鉤子能立即涵蓋最常見的攻擊模式。ClawGuard 的貢獻在於自動約束衍生，這會增強手動規則而非取代它們。

Vercel 遙測事件是安全漏洞嗎？

該揭露描述的是隱私與同意問題，而非傳統意義上的漏洞。在揭露時，該外掛從所有專案蒐集 bash 命令字串，並在未透過原生 UI 取得明確同意的情況下傳送至外部端點。Vercel 已回應了這些疑慮。其架構模式——寬泛的鉤子匹配器、外部資料傳輸、非原生同意機制——仍具參考價值，因為它與惡意鉤子用於資料外洩的模式如出一轍。

執行期工具呼叫攔截的效能影響為何？

對於使用 shell 腳本或輕量級驗證器的手寫鉤子，依據鉤子文件指引，額外開銷應控制在每次工具呼叫 200ms 以內。ClawGuard 論文未報告其約束評估的延遲量測，可能會產生額外開銷。對互動式會話而言，每次工具呼叫的延遲至關重要——在部署複雜驗證邏輯前應先行測試。