AI助手的審批提示何時成為安全邊界？

一位安全研究人員近日披露了關於開源AI代理項目Hermes Agent（由Nous Research開發）的三個安全發現，這些發現揭示了在AI代理審批提示中存在的潛在安全漏洞。然而，項目方在收到報告後修改了安全策略，將這些發現重新歸類為超出範圍，引發了關於AI代理安全邊界定義的行業討論。

研究人員指出，Hermes Agent的審批系統旨在阻止危險命令的執行，但存在三種繞過方式。首先，在可選的“智能”審批模式下，第二個大語言模型被用於判斷被標記的命令，但輸入的命令被直接插入到評審模型的提示中，沒有語義隔離，使得注入的文本可以誤導模型批准危險操作。其次，代理的啓動鈎子目錄中任何Python文件都會在啓動時自動執行，無需註冊或驗證，這意味着通過提示注入，攻擊者可以在不觸發審批的情況下寫入惡意文件，導致下次啓動時執行任意代碼。最後，審批系統的檢測機制基於原始命令字符串的正則匹配，而非解析後的令牌，因此攻擊者可以使用引號、變量間接引用、替代shell二進制文件等方式輕鬆繞過檢測，執行相同危險操作。

研究人員在提交報告時，項目方的安全政策明確將審批系統稱為“核心安全邊界”，並明確將“導致審批系統實際繞過的提示注入”列入範圍。然而，六天後，政策被重寫，將審批提示重新定義為非邊界的啓發式方法，並移除了相關條款。研究人員的報告隨後被關閉，理由是不再屬於範圍，但項目方未提及政策變更。

這一事件凸顯了行業中的不一致性。例如，Anthropic將Claude Code中類似的命令解析錯誤評為高危漏洞（CVE-2026-24887），併發布了修復，儘管他們同樣推薦使用沙箱作為真正的安全邊界。兩個項目處理同一類漏洞的方式截然相反，表明“沙箱是真正邊界”與“審批繞過是漏洞”這兩種立場並非互斥，但政策決定了實際修復與否。

研究人員強調，這些漏洞在默認的本地後端配置中至關重要，此時沒有沙箱保護，用户依賴審批提示作為唯一安全機制。隨着AI代理越來越多地獲得真實shell訪問權限，人工確認步驟究竟是安全控制還是便利工具，這一問題將直接決定哪些漏洞被修復、獲得CVE或被關閉。