AI 編碼代理人（AI Coding Agents）正迅速改變開發流程，它們能自動讀取程式碼、執行測試甚至直接操作終端機來完成任務。然而，近期由 Adversa AI 提出的 GuardFall 研究揭露了一個嚴重的安全漏洞：大多數開源 AI 代理人雖然設有安全檢查機制，但卻能被一種存在數十年的傳統 Shell 注入技巧輕易繞過。
這項研究測試了 11 款主流的開源編碼代理人，結果發現其中 10 款都存在此漏洞，僅有 Continue 展現出較強的防禦能力。對於工程師而言，這意味著如果你將 AI 代理人對接至一個受污染的儲存庫，攻擊者可能在不經意間奪取你的系統權限。
為什麼安全檢查會失效
大多數 AI 代理人為了防止執行危險指令（例如 rm -rf /），會採取一種名為 Blocklist（黑名單）的過濾機制。簡單來說，代理人在將指令送往 Shell 執行前，會先將其視為純文字（Plain Text），檢查其中是否包含危險的關鍵字。
然而，問題在於 AI 代理人的過濾器與實際執行指令的 Bash Shell 對於文字的解析方式完全不同。Bash 在執行指令前會進行一系列的預處理，包括去除不必要的引號、展開快捷方式或處理特殊字元。
以簡單的例子來說，如果過濾器在尋找 rm 這個字串，攻擊者可以使用 r''m 這種寫法。對於文字過濾器而言，r''m 與 rm 是不同的字串，因此會判定為安全並允許通過；但當這個指令到達 Bash 時，Bash 會自動移除空引號，將其還原為 rm 並執行。
除了引號技巧，攻擊者還可以使用 Base64 編碼將指令隱藏，或利用 find 與 dd 等看似正常的工具搭配特定參數來達成破壞性目的。這並非單一的程式 Bug，而是一種設計上的缺陷：過濾器在檢查的是文字，而系統執行的是經過解析後的指令。
攻擊發生的前提條件
要成功實施 GuardFall 攻擊，通常需要滿足兩個條件：
第一，AI 必須產出惡意指令。雖然直接要求 AI 執行刪除指令通常會被拒絕，但如果惡意指令被偽裝在正常的建構檔案（Build File）或工具說明文件中，AI 在執行例行任務時可能會不自覺地將其輸出。
第二，代理人必須處於自動執行模式。這包括開啟了 auto-execute 旗標，或是關閉了容器沙箱（Container Sandbox）。在許多自動化流水線（CI/CD Pipeline）中，為了追求效率，開發者經常會開啟這些高風險設定。
一旦這兩個條件成立，攻擊者就能利用 AI 代理人的權限，竊取 SSH 金鑰、雲端憑證或刪除家目錄下的所有檔案。
如何有效防禦
研究指出，單純增加黑名單的關鍵字數量無法解決問題。真正的解決方案是讓過濾器以 Shell 的視角來解析指令。
Continue 之所以能防禦此攻擊，是因為它在決定是否執行前，會先將指令拆解成與 Bash 相同的片段，確認最終實際執行的內容是什麼，再比對破壞性指令清單。這種方法將檢查對象從純文字轉移到了執行邏輯上。
對於目前使用 AI 代理人的工程師，建議採取以下實務防護措施：
環境隔離。將代理人的 HOME 環境變數指向一個臨時資料夾，確保 ~/.ssh 或 ~/.aws 等敏感憑證不在 AI 的存取路徑內。
禁用自動執行。除非任務絕對無法暫停，否則請關閉 --auto-exec、--auto-run 等自動執行旗標，確保每條指令在執行前都經過人類審核。
限制來源。不要讓 AI 代理人在來自 Fork 分支的 Pull Request 上運行，避免攻擊者透過提交惡意檔案來觸發指令。
審查設定檔。將儲存庫內附的設定檔（如 .aider.conf.yml）視為不可信的程式碼，因為惡意設定可能在 AI 接受編輯的第一時間就觸發攻擊。
總結
GuardFall 提醒我們，AI 代理人的權限過高且缺乏深層的語意檢查，使其成為傳統漏洞的新載體。當我們將 AI 整合進開發流程時，不能僅依賴 AI 自身的安全對話機制，必須從系統層級建立零信任（Zero Trust）的防禦體系。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。