AI编程助手集体翻车：Pillar Security「沙盒逃脱周」揭示系统性信任危机

TL;DR

如果你在本地或CI/CD流水线中运行AI编程助手，你的沙盒很可能挡不住攻击。Pillar Security刚刚完成了「沙盒逃脱周」——一个为期7天的系列研究，证明四款主流AI编程助手（Cursor、OpenAI Codex CLI、Google Gemini CLI和Google Antigravity）都能逃离沙盒。关键点：没有任何一次逃脱需要直接攻破沙盒。研究人员利用的是一个系统性的「信任交接」缺陷——AI agent写入文件，然后受信任的宿主机工具不加审查地执行这些文件。三家厂商已修复，Google将自家两款工具的漏洞严重性降级处理。

发生了什么

2026年7月20日，Pillar Security开始发布名为「The Week of Sandbox Escapes」的协调披露系列——每天一篇深度分析，每篇展示一条不同的沙盒边界穿越路径。这项研究历时数月，覆盖了四款广泛使用的AI编程助手：

• Cursor（Anysphere）——内置Agent编程能力的AI原生IDE
• OpenAI Codex CLI——OpenAI的终端编程Agent
• Google Gemini CLI——Google的命令行AI编程工具
• Google Antigravity——Google的AI驱动文件系统操作Agent

已分配多个CVE编号，但截至发稿时并非所有发现都统一公开了具体CVE编号。

攻击机制：信任交接，而非攻破沙盒

这是Pillar研究的核心洞察：在几乎所有案例中，AI Agent都不需要直接攻破沙盒。攻击利用的是一个「信任交接」模式：

1. AI Agent在沙盒内运行，直接执行能力受限
2. 但Agent可以写文件——配置文件、脚本、构建产物
3. 这些文件随后被受信任的宿主机工具消费（包管理器、构建系统、CI/CD运行器、Shell初始化脚本）
4. 那些受信任的工具以宿主机权限执行文件内容——毫不质疑

研究人员展示了具体的攻击链：

• 诱使Agent写入恶意Shell配置，在下一次终端会话时被自动加载
• 让Agent修改构建脚本，在下一次npm install或pip install时执行
• 在项目文件中植入代码，被自动化CI/CD流水线拾取执行

这不是沙盒实现的Bug，而是设计层面的信任边界失效：沙盒正确地阻止了Agent执行任意命令，但没人考虑到Agent写入的文件是否会在下游被武器化。

四种可复现的失效模式

Pillar Security的发现可归纳为四种跨工具的可复现失效模式：

1. 文件到执行的桥接——Agent写入的文件被宿主机工具执行（所有厂商中最常见）
2. 配置投毒——修改自动化工具盲信的项目配置文件
3. 依赖链注入——在包管理器解析的依赖清单中植入代码
4. 环境变量操纵——Agent通过间接写入影响宿主机环境状态

厂商回应

Google将Antigravity的发现降级的决定引发了关注。虽然Google承认了两个报告的绕过均为有效安全发现，但「其他有效安全漏洞」的分级意味着这些发现不会被按可主动利用的CVE同等紧急程度处理。这具有争议性——Antigravity就是为文件系统操作设计的，其信任交接攻击面特别大。

为什么这对开发者很重要

如果你今天在使用AI编程助手，这是一个不舒服的现实：你的沙盒是一个减速带，不是一堵墙。攻击面不是沙盒的边界——而是Agent能写入的每一个文件，以及之后可能读取这些文件的每一个宿主机工具。

具体风险场景：

• 本地开发：Agent写入的.bashrc/.zshrc修改会跨会话持久化
• CI/CD流水线：Agent修改的构建脚本在自动化流水线中以部署凭证执行
• 团队环境：一个团队成员的Agent写入恶意配置，提交后被其他所有成员的自动化工具执行
• 开源贡献：审查或修改Pull Request的Agent可能在项目配置中注入载荷

你应该立刻做什么

1. 绝不以提升的权限运行AI编程Agent

这听起来很基础，但很多开发者在Agent增强的工作流中运行sudo pip install或npm install -g。如果Agent能修改package.json而你的npm install以root运行，你就给了Agent一条提权路径。

2. 审计你的Agent可以写什么文件

大多数沙盒专注于限制执行，而非文件写入。检查你的Agent是否能写入~/.bashrc、~/.gitconfig、~/.npmrc、Makefile、pyproject.toml，或任何会被自动执行或自动加载的文件。

3. 将Agent输出视为不可信输入

这是Pillar研究要求的根本思维转变：AI Agent写入的文件是不可信输入，不是可信输出。你的构建系统、CI/CD流水线、Shell——都不应该盲目消费Agent生成的文件。在Agent输出和宿主机执行之间添加验证步骤。

4. 隔离Agent环境

在完全隔离的环境中运行AI编程Agent（容器、虚拟机或专用开发机），限制沙盒逃脱的爆炸半径。不要在持有生产凭证或部署密钥的同一台机器上运行Agent。

5. 关注新发布的CVE

如果你使用Cursor、Codex、Gemini CLI或Antigravity，立即更新到最新版本。关注具体CVE的公开发布，获取任何额外的缓解步骤。

我的观点

Pillar Security的研究之所以重要，不是因为它发现了Bug——而是因为它暴露了行业对AI Agent安全思考中的范畴错误。

我们一直把AI编程Agent当作普通的用户空间应用程序：放进沙盒、限制系统调用、完事。但AI Agent在本质上是不同的。它们是生成式的——它们产生新的内容，流入其他系统。普通应用程序写入配置文件是因为你让它写的。AI Agent写入配置文件是因为一个语言模型决定这么做，可能受到提示注入或训练数据偏见的影响。

「我机器上的工具写的文件是安全的」这个信任模型，在其中一个工具是输出不可预测的LLM驱动的Agent时，完全崩溃了。

这不是更好沙盒能解决的问题。这需要重新思考AI Agent和宿主机系统之间的整个信任架构。Agent不应该被视为恰好运行在沙盒中的可信写入者——它应该被视为不可信输入源，其输出在被消费前必须验证。

在这个架构转变发生之前，每一个运行AI编程Agent的开发者，都在隐式地将宿主机的完整性托付给一个语言模型。Pillar Security刚刚向我们展示了为什么这种信任是错位的。