Luisa Crawford
2026年1月30日 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容器或单内核——将沙箱内核与主机隔离。像Docker这样的共享内核解决方案会让内核漏洞可被利用。开销是真实的,但通常被LLM推理延迟所掩盖。
秘密注入而非继承。开发者机器加载了API密钥、SSH凭证和AWS令牌。以空凭证集启动沙箱,并仅注入当前任务所需的内容,可以限制爆炸半径。
生命周期管理可防止工件积累。长期运行的沙箱会收集依赖项、缓存凭证和攻击者可以重新利用的专有代码。临时环境或定期销毁可以解决这个问题。
这对开发团队意味着什么
时机很重要。AI编码代理已经从新奇事物变成许多团队的必需品,但安全实践并未跟上步伐。手动批准每个操作会产生习惯化——开发者不阅读就盖章批准请求。
NVIDIA的分层方法提供了一条中间路径:无法覆盖的企业拒绝列表、无摩擦的工作区读写、合法外部访问的特定允许列表,以及对其他所有内容采用默认拒绝并逐案批准。
该框架明确避免处理输出准确性或AI建议的对抗性操纵——这些仍然是开发者的责任。但对于赋予AI代理真实系统访问权限所带来的执行风险?这是主要供应商安全团队提供的最详细的公开指南。
图片来源: Shutterstock
来源: https://blockchain.news/news/nvidia-ai-agent-security-framework-sandbox-controls
