Luisa Crawford
Jan 30, 2026 16:35
NVIDIA 的 AI 紅隊發布 AI 編碼代理的強制性安全控制措施,解決提示注入攻擊和沙箱逃逸漏洞問題。
NVIDIA 的 AI 紅隊於 1 月 30 日發布了一個全面的安全框架,針對開發人員工作流程中日益增長的盲點:以完整使用者權限執行的 AI 編碼代理。該指南發布之際,網路安全沙箱市場正朝著 3,680 億美元膨脹,而近期如 CVE-2025-4609 等漏洞提醒所有人,沙箱逃逸仍然是真實的威脅。
核心問題是什麼?像 Cursor、Claude 和 GitHub Copilot 這樣的 AI 編碼助手會以開發人員擁有的任何存取權限執行命令。攻擊者若毒化儲存庫、將惡意指令植入 .cursorrules 檔案,或入侵 MCP 伺服器回應,就能完全劫持代理的操作。
三項不可協商的控制措施
NVIDIA 的框架確定了紅隊認為強制性的三項控制措施——不是建議,而是要求:
網路出站鎖定。封鎖所有出站連線,除非明確批准的目的地。這可防止資料外洩和反向 Shell。該團隊建議強制執行 HTTP 代理、指定 DNS 解析器,以及個別開發人員無法覆寫的企業級拒絕清單。
僅限工作區檔案寫入。代理不應觸碰活動專案目錄之外的任何內容。寫入 ~/.zshrc 或 ~/.gitconfig 會為持久性機制和沙箱逃逸打開大門。NVIDIA 希望在此處實施作業系統層級的強制執行,而非應用程式層的承諾。
設定檔保護。這一點很有趣——即使是工作區內的檔案,如果它們是代理設定檔,也需要保護。鉤子、MCP 伺服器定義和技能腳本通常在沙箱環境之外執行。該指南直截了當:不允許代理修改這些檔案,句點。僅允許手動使用者編輯。
為何應用程式層級控制會失敗
紅隊提出了令人信服的理由,說明作業系統層級強制執行優於應用程式層限制。一旦代理產生子程序,父應用程式就會失去可見性。攻擊者經常串連已批准的工具來觸及被封鎖的工具——透過更安全的包裝器呼叫受限制的命令。
macOS Seatbelt、Windows AppContainer 和 Linux Bubblewrap 可以在應用程式層之下強制執行限制,捕捉允許清單遺漏的間接執行路徑。
更嚴格的建議
除了強制性的三項措施外,NVIDIA 還為風險容忍度較低的組織概述了控制措施:
完全虛擬化——VM、Kata 容器或 Unikernel——將沙箱核心與主機隔離。像 Docker 這樣的共享核心解決方案會使核心漏洞容易被利用。開銷是真實存在的,但通常被 LLM 推理延遲所掩蓋。
秘密注入而非繼承。開發人員的機器載有 API 金鑰、SSH 憑證和 AWS 權杖。以空憑證集啟動沙箱,並僅注入當前任務所需的內容,可限制爆炸半徑。
生命週期管理可防止工件累積。長時間執行的沙箱會收集依賴項、快取憑證和攻擊者可以重新利用的專有程式碼。臨時環境或計劃性銷毀可解決此問題。
這對開發團隊意味著什麼
時機很重要。AI 編碼代理已從新奇事物轉變為許多團隊的必需品,但安全實踐並未跟上。手動批准每個操作會產生習慣化——開發人員不加閱讀就橡皮圖章式地批准請求。
NVIDIA 的分層方法提供了一條中間路徑:無法覆寫的企業拒絕清單、無摩擦的工作區讀寫、針對合法外部存取的特定允許清單,以及對其他所有內容採取預設拒絕並逐案批准。
該框架明確避免處理輸出準確性或 AI 建議的對抗性操縱——這些仍然是開發人員的責任。但對於賦予 AI 代理真實系統存取權限所帶來的執行風險?這是主要供應商安全團隊提供的最詳細的公開指南。
圖片來源: Shutterstock
來源: https://blockchain.news/news/nvidia-ai-agent-security-framework-sandbox-controls
