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

一週前，我發表了一篇關於 50 個 MCP 漏洞的文章，涵蓋 SSRF、工具投毒與信任繞過等攻擊模式。隱含的結論令人憂心：攻擊面的擴張速度遠超稽核能量所能追趕。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 會將該呼叫與規則集進行比對。在受評估的配置中，這些規則是基本的存取控制約束（檔案路徑限制、網路呼叫白名單、憑證存取封鎖）。任何超出約束範圍的呼叫，無論注入提示多麼逼真，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。¹ 手寫規則本質上脆弱——它們只涵蓋您預見的攻擊。衍生約束有潛力涵蓋未預見的攻擊，因為它們基於正向集合（應該發生什麼）而非負向集合（不應發生什麼）運作。

自動衍生在生產環境中是否能穩定運作，仍是懸而未決的問題。基準測試是受控環境，真實的代理工作階段涉及模糊的任務、多步驟工具鏈，以及看似異常但實際合法的工具呼叫。如果誤判（false positive）封鎖了有效的工具呼叫，「不損害代理實用性」的主張將迅速瓦解。

分層防禦堆疊

執行期防禦並非單一機制。工具增強型代理的實用防禦堆疊至少包含四層：

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

第二層：基本規則執行。 基於存取控制規則（路徑限制、網路白名單、憑證防護）限制允許的工具與引數集合。ClawGuard 受評估的配置運作在這一層。¹ 論文也提議任務範圍的約束衍生，其定位介於本層與下一層之間，但該元件仍屬未來工作。涵蓋範圍優於單純的輸入驗證，但規則必須隨環境變化持續維護。

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

第四層：工作階段稽核。 記錄每次工具呼叫、每個引數、每個結果，供事後審查。這不是預防機制，而是偵測機制。Akshay Chugh 正是透過這類稽核揭露了 Vercel 遙測事件：閱讀鉤子設定並追蹤鉤子的實際行為。²

沒有任何單一層能獨當一面。輸入驗證遺漏新型模式，任務範圍約束可能過嚴或過鬆，輸出檢查增加延遲，工作階段稽核在損害發生後才發現問題。堆疊之所以有效，正因為每一層都彌補了其他層的缺口。

ClawGuard 做對了什麼

這篇論文為實務工作者帶來三項有意義的貢獻：

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

管道無關的執行。 以單一執行點同時防禦網頁注入、MCP 注入和技能檔案注入，在架構上穩健合理。為三個注入管道分別建構三套防禦，會造成維護負擔，且在交叉處留下缺口。工具呼叫邊界上的單一執行點，從結構上就涵蓋了全部三個管道。

無需修改模型。 既不需微調也不需架構修改，意味著此防禦適用於任何模型，包括您無法控制的模型。無論是運行 Claude Code、Codex CLI 還是其他代理框架的操作者，都可以在無需等待模型供應商發布安全更新的情況下，加入執行期防禦。

懸而未決的問題

ClawGuard 在基準測試上進行了驗證。生產環境中的代理工作階段要複雜得多。在實務工作者能依賴自動約束衍生之前，幾個問題有待釐清：

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

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

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

效能成本。 在每個工具呼叫邊界評估約束會增加延遲。論文聲稱框架保留了實用性，但未報告延遲測量結果。¹ 對於互動式代理工作階段，即使每次工具呼叫增加 200 毫秒，也會改變使用者體驗。

實務要點

對於目前正在運行工具增強型代理的實務工作者：

立即部署 PreToolUse 鉤子。 不必等待 ClawGuard 或其他框架。Claude Code 的鉤子系統今天就支援工具呼叫攔截。從輸入驗證開始：封鎖內部位址、限制檔案路徑、為破壞性操作設置關卡。鉤子教學涵蓋了實作細節。

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

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

針對您的堆疊評估 ClawGuard。 論文附有程式碼庫連結，但作者在撰寫時尚未發布程式碼。待其可用時，將基本規則配置與您現有的鉤子堆疊進行對比評估。若任務特定規則歸納元件成熟，自動約束衍生將補強手寫規則，而非取而代之。

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

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

來源

常見問題

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

Claude Code 的權限系統同時支援工具層級的核准（核准或拒絕工具類別）與引數層級的指定器（例如 Bash(git diff *) 僅允許匹配的命令）。ClawGuard 受評估的配置在引數層級強制執行基本存取控制規則。其所提議的任務特定規則歸納元件能自動從當前任務衍生引數約束，但作者未對該元件進行評估。兩套系統相輔相成：Claude Code 權限管控哪些工具和引數模式可以執行，而 ClawGuard 風格的執行期約束則增添第二道執行層。

是否需要等 ClawGuard 發布才能加入執行期防禦？

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

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

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

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

就使用 shell 腳本或輕量級驗證器的手寫鉤子而言，根據我的實務經驗，每次工具呼叫的額外開銷應可控制在 200 毫秒以內。ClawGuard 論文未報告其約束評估的延遲測量結果，可能會產生額外開銷。對於互動式工作階段，每次工具呼叫的延遲至關重要，因此在部署複雜驗證邏輯前務必進行測試。