Pillar Security 研究员：AI 编程代理的隔离保护宿主机，却不保护沙箱自身

本地 AI 编程代理在用户机器上执行代码时，通常拥有用户级权限：文件系统访问、网络能力和 shell 执行。Pillar Security 研究员 Eilon Cohen 与 Ariel Fogel 在 2026 年 2 月发表的分析中，将这一局面概括为一个核心区分：隔离技术保护宿主机免受沙箱内代码的侵害，但不保护沙箱自身。

这意味着沙箱是遏制手段，不是预防手段。当信任被违反时，沙箱限制爆炸半径，但它不处理底层的信任问题。AI 代理处理的内容来自无法完全验证的来源——模型权重在加载时执行代码、包依赖附带安装脚本、用户提供的仓库——每一个都是注入向量。沙箱是最后一层防线，不是第一层。

作者分析了十四种面向编程代理的沙箱方案，将其归为四个隔离层级。容器共享内核，内核漏洞即可突破边界；gVisor 拦截系统调用，缩小攻击面但其正确性本身成为安全关键；硬件虚拟化 microVM 为每个沙箱提供独立内核，隔离最强但受会话限制和启动延迟约束；内核能力（如 Landlock、Seatbelt）无逃逸路径，但仅限本地，无法部署到多租户平台。

然而，无论选择哪一层级，一个被忽视的事实是：沙箱只隔离你放进去的东西。挂载 SSH 密钥，沙箱内就能访问；授予完整文件系统读取权限，凭据文件就可被读取；标准输出回传给大语言模型，任何打印的内容都可被外泄。Cursor 在 2025 年 11 月就因完整文件系统读取权限导致凭据暴露，即使写入被限制在 workspace 内，代理仍可通过 cat 命令读取凭据文件并将内容输出到 stdout。

2026 年 1 月的 CVE-2026-22708 进一步暴露了静态白名单的结构性缺陷。Cursor 的白名单机制逐条验证命令是否安全，但 shell 内置命令可以在不经确认的情况下修改环境变量，使后续被允许的命令在污染后的上下文中变成攻击向量。一个单独看安全的命令，在周围环境已被操纵后，就不再安全。

作者由此提出一个选择框架：正确的隔离层级取决于两个问题——你在隔离什么，以及你用什么来隔离。如果威胁是用户提供的不可信代码，microVM 加违规检测是合理选择；如果威胁是带安装脚本的第三方包，纵深防御更合适；如果威胁是通过外部内容的提示注入，网络隔离加受限文件系统读取是关键。反过来，如果生产凭据存在于环境变量中，它们就在沙箱内部；如果授予了完整文件系统读取，凭据文件就是可读的；如果 stdout 回传给模型，任何打印的内容都是可外泄的。

一个挂载了 AWS 凭据的 microVM，并不比挂载了相同凭据的容器更安全。隔离层级的选择是架构决策，不是采购决策。它的重要性低于它所针对的威胁模型和它实际执行的信任边界。

需要指出的是，Pillar Security 是一家 AI 安全产品公司，该分析同时服务于其 SAIL 2.0 框架和 Agentic Endpoint 平台的推广。文中对 Claude Code 截至分析日期无已知沙箱漏洞的判断，是特定时间点的快照，不代表永久状态。

对开发者而言，实际可操作的检查项是：你的开发环境中存在哪些凭据？代理是否拥有完整文件系统读取权限？执行环境默认挂载了什么？对安全团队而言：沙箱是否限制读取权限，还是只限制写入？是否存在沙箱边界违规的检测机制？沙箱配置由谁控制——厂商、平台团队还是终端用户？