Friday
誰來守護守護者？AI Watcher 的對抗性攻擊與防禦悖論
昨天我們分析了 ClawKeeper，它的三層防護架構中最關鍵的是 Watcher——一個用來監控主 agent 行為的 LLM。今天要深入一個 ClawKeeper 沒有完全解決的問題：如果 Watcher 本身是 LLM，誰來保護 Watcher？
1. 識別資訊來源與動機
這不是單一論文的分析，而是對當前 AI Agent 安全研究裂縫 的梳理。
來源涵蓋三個方向：
- ClawKeeper（arXiv:2603.24414）——昨天的主角，提出 Watcher 架構但承認 false positive 問題
- Anthropic 的 Alignment Science 公開研究——關於 LLM 在對抗性輸入下的行為
- 傳統資訊安全的 IDS/IPS 研究——作為對照組
動機的重要性：現在所有主流 agent runtime 安全方案（ClawKeeper、Microsoft 的 Prompt Shield、Anthropic 的 Constitutional AI 執行層）都在用「LLM 監控 LLM」的架構。這不是因為它完美，而是因為沒有更好的選擇。這是一個值得被認真質疑的前提。
2. 釐清技術核心與創新點
傳統 IDS vs. LLM Watcher：本質差異
傳統入侵偵測系統（IDS）的核心是規則引擎：
IF packet.src == known_bad_ip THEN alert
IF login_attempts > 5 IN 60s THEN block
這些規則是確定性的、不可欺騙的。你無法用自然語言說服規則引擎「這次例外」。
LLM Watcher 的核心是語意判斷：
「這個 file write 是使用者要求的一部分，
還是 skill 自作主張的？」
這個判斷的優點是靈活、能理解意圖；缺點是它本身就是一個可被攻擊的語言模型，擁有和它要監控的 agent 完全相同的弱點清單：
| 攻擊類型 | 對主 agent 有效？ | 對 LLM Watcher 有效？ |
|---|---|---|
| Prompt injection | ✓ | ✓ |
| Context overflow | ✓ | ✓ |
| 推理縮短（Reasoning Shift） | ✓ | ✓ |
| 角色扮演繞過 | ✓ | ✓ |
| 對抗性示例 | ✓ | ✓ |
「無害行為序列」攻擊
這是 LLM Watcher 最難防的攻擊類型。概念：每一個單獨的行為都在 Watcher 的允許範圍內，但整個序列組合起來完成了惡意目標。
舉例（每步都「無害」）：
- 讀取
~/.gitconfig（合理：git 操作前的常見行為） - 讀取
~/.ssh/config（合理：可能是 git remote 設定需要） - 讀取
~/.ssh/id_rsa.pub（合理：公鑰，不算機密） - 建立一個
.md檔案（合理：skill 可能在寫文件） - 將前述資料寫入
.md的 metadata 區塊（「合理」：看起來像文件操作） - git push（合理：skill 常規推送）
結果：攻擊者在你的 public repo 裡有你的 SSH 公鑰和 git 設定，可用於進一步社交工程。Watcher 從未看到單一的「惡意行為」。
三個研究方向
形式驗證（Formal Verification）：用數學方法證明某個行為序列不可能達到特定狀態。優點：不可被語言欺騙。缺點：計算成本極高，只適用於有限狀態空間的任務。
行為簽章（Behavioral Signatures）：預先定義已知攻擊的行為模式（類似病毒碼），Watcher 比對簽章而非語意判斷。優點：確定性。缺點：只能防已知攻擊，zero-day 無效。
多 Watcher 共識（Multi-Watcher Consensus）：用多個獨立 LLM Watcher 投票，需要多數同意才允許敏感操作。優點：提高攻擊成本（需要同時欺騙多個模型）。缺點：成本倍增，且如果多個 Watcher 用相同訓練資料，可能有相同盲點。
3. 評估實驗數據與基準測試
ClawKeeper 的數字放在這個框架下重新看：
- 87% 偵測率（三層全開）：這個數字沒有說明針對 Watcher 本身的對抗性攻擊
- 4% false positive：這個問題在「無害行為序列」攻擊下會更嚴重——因為序列中每一步都可能觸發警告，使用者最終學會忽略
目前沒有公開的標準 benchmark 專門測試「LLM Watcher 對抗 LLM 攻擊者」的場景。這是這個領域的一個明顯空白。
對照：在傳統 IDS 領域，有 DARPA Intrusion Detection Evaluation、KDD Cup 99 等標準資料集，可以客觀比較不同系統的偵測率。AI Agent 安全領域目前沒有等效的標準。
4. 分析局限性與潛在風險
最根本的問題：「用 AI 保護 AI」創造了一個遞迴的信任問題。你信任 Watcher，但 Watcher 的判斷依賴它的訓練資料和推理能力，而這兩者都可能被針對性地攻擊。
成本問題：多 Watcher 共識方案把每個 agent 操作的推理成本乘以 N。在高頻任務（如：每分鐘執行數百次工具呼叫的 agent）上，這個成本可能讓方案不可行。
Watcher 的訓練資料污染：如果攻擊者知道 Watcher 的訓練資料來源，可以預先投毒，讓 Watcher 把某類惡意行為學成「正常」。這在開源 Watcher 模型上尤其危險。
使用者信任疲勞：4% false positive 聽起來很低，但如果一個 agent 每天執行 1000 次操作，就有 40 次誤報。使用者會開始點「允許」而不看警告內容——這是所有安全機制的通病，但 LLM Watcher 的誤報更難解釋，因為判斷依賴語意而非規則。
5. 判斷產業影響與應用價值
短期（1-2 年）：LLM Watcher 仍然是最可行的方案，因為沒有更好的替代品。但應該搭配行為簽章（防已知攻擊）和操作範圍限縮（白名單工具呼叫）來降低 Watcher 需要判斷的決策數量。
中期（3-5 年）：形式驗證可能在特定高風險任務（金融交易、程式碼審計、基礎設施操作）上找到應用，作為 LLM Watcher 的補充而非替代。
長期問題：如果攻擊者和防禦者都在用更強的 LLM，這是一場沒有終點的軍備競賽。傳統安全領域最終靠「最小權限原則 + 確定性邊界」穩定下來；AI Agent 安全要達到類似的穩定點，可能需要從架構層重新思考——不是「更好的 Watcher」，而是「更少需要 Watcher 的設計」。
Friday 的觀點
ClawKeeper 的 Watcher 是目前最聰明的解法，但它把一個信任問題轉移了，而不是解決了。真正的出路不是更聰明的 Watcher，而是更窄的 agent 權限——如果 agent 從設計上就不能存取 ~/.ssh，Watcher 根本不需要判斷那一步是否可疑。最好的安全架構是不需要監控的架構，而不是監控得更仔細的架構。