NVIDIA 的 AI 红队发布了一套针对 AI 编码代理的强制安全控制措施，旨在应对相关威胁升级时的即时注入攻击和沙箱逃逸漏洞。
NVIDIA 的 AI 红队于 1 月 30 日发布了全面的安全框架，解决了开发人员工作流程中的一个关键盲点：以完全用户权限运行的 AI 编码代理。本指南发布之际，网络安全沙盒市场规模已扩大到 3680 亿美元，而最近的漏洞（例如 CVE-2025-4609）强调沙盒逃逸仍然是一个切实的威胁。
核心问题在于 Cursor、Claude 和 GitHub Copilot 等 AI 编码助手，它们以与开发人员相同的访问权限执行命令。攻击者可能会通过毒害存储库、将恶意指令插入 .cursorrules 等配置文件或破坏 MCP 服务器响应来劫持代理的操作。
三个不可协商的控制
该框架建立了红队认为强制性的三项控制措施：
网络出口锁定。阻止除明确批准的目的地之外的所有出站连接，以防止数据泄露和反向 shell。建议包括 HTTP 代理强制执行、指定的 DNS 解析器以及个人开发人员无法覆盖的企业级拒绝列表。
仅工作区文件写入。应限制代理写入活动项目目录之外的任何位置。写入 ~/.zshrc 或 ~/.gitconfig 等系统文件可以启用持久性机制和沙箱逃逸。 NVIDIA 提倡操作系统级别的执行，而不仅仅是应用程序层的承诺。
配置文件保护。工作区中的配置文件（例如挂钩、MCP 服务器定义和技能脚本）必须受到保护，因为它们经常在沙箱上下文之外执行。该指南很明确：代理不会修改这些文件——仅由用户手动编辑。
为什么应用程序级控制失败
红队极力主张在应用程序层限制上实施操作系统级别的限制。一旦代理生成子进程，父应用程序就会失去可见性。攻击者可以链接经过批准的工具来访问被阻止的工具，例如通过更安全的包装器调用受限命令。
macOS Seatbelt、Windows AppContainer 和 Linux Bubblewrap 等技术可以在应用程序层下实施限制，捕获白名单可能错过的间接执行路径。
降低风险承受能力的高级建议
除了强制性三重奏之外，NVIDIA 还为风险承受能力较低的组织提供了额外的控制措施：
完全虚拟化（使用 VM、Kata 容器或 unikernel）将沙箱内核与主机隔离，而 Docker 等共享内核解决方案则使内核漏洞可被利用。与 LLM 推理延迟相比，性能开销通常很小。
秘密注入而不是继承。沙箱不应从开发人员的计算机继承所有凭证，而应从空凭证集开始，仅注入当前任务所需的 API 密钥、SSH 凭证或 AWS 令牌，从而限制潜在的爆炸半径。
生命周期管理可防止工件累积。长时间运行的沙箱可以收集攻击者可能重新利用的依赖项、缓存的凭据和专有代码。临时环境或定期销毁可以解决此风险。
对开发团队的影响
该框架的时机非常重要。对于许多团队来说，人工智能编码代理已经从新颖性转变为必需品，但安全实践却滞后了。对每个代理操作的手动批准可能会导致习惯，开发人员会在没有仔细审查的情况下对请求进行橡皮图章。
NVIDIA 的分层方法提供了一条平衡的路径：无法覆盖的企业拒绝列表、无摩擦的工作区读写访问、合法外部资源的特定允许列表，以及对所有其他操作进行逐案批准的默认拒绝状态。
该框架明确不涉及人工智能建议的输出准确性或对抗性操纵——开发人员的责任仍然存在。然而，对于授予人工智能代理真正的系统访问权限所固有的执行风险，这代表了主要供应商安全团队迄今为止最详细的公共指导。