安全研究人员已经证明，保护四种广泛使用的人工智能编码代理（Cursor、OpenAI 的 Codex、谷歌的 Gemini CLI 和 Antigravity）的沙箱可以在不正面攻击沙箱的情况下逃脱。该研究结果由 Pillar Security 的研究团队于 2026 年 7 月 20 日发布，并由 BleepingComputer 报道，揭示了 AI 编码工具如何将其代理生成的代码与其运行的开发机器隔离的结构性弱点。
对于任何追踪智能体安全性的突发人工智能新闻的人来说，这项研究都是一个重要的数据点，因为它表明，即使是一个完全合规的智能体——遵守其沙箱内的每一条规则——仍然可能会爆发。该缺陷不在于代理的行为，而在于沙箱假设的信任边界。
逃脱是如何进行的
关键的见解看似简单。现代人工智能编码代理在沙箱内运行，并划出一条线：代理在项目工作区内部受到信任，而外部主机受到保护。假设工作空间内的文件是惰性的——数据，而不是命令。
但它们并不是惰性的。在沙箱外部运行的工具不断读取这些文件并对其进行操作。集成开发环境解析 Python 解释器，Git 集成扫描存储库，VS Code 运行任务文件，hook 引擎触发命令，Docker Desktop 公开本地套接字。沙盒代理可以遵守给定的每条规则，并且仍然编写一个文件，供这些外部工具之一稍后执行、加载或扫描。
根据 BleepingComputer 的报告，越狱“自行发生”：代理留在盒子内，遵循每条规则，只写入一个文件，盒子外的可信工具随后运行。特工永远不会爆发；突破是由开发人员已经信任的软件代表其完成的。
触发器：立即注射
启动这些逃逸的机制是即时注入——同样的漏洞困扰着跨领域的人工智能代理。一旦代理处理了 README 文件、GitHub 问题、项目依赖项或代码差异中的恶意指令，就会成为开发人员计算机上的本地操作。
这将沙箱研究与更广泛的人工智能安全模式联系起来。代理不需要受到损害或越狱。它只需要在正常工作过程中遇到中毒输入（读取文件、审查拉取请求、安装包），然后通过在正确的位置写入正确的文件来执行嵌入的指令。沙箱允许写入，因为写入文件正是编码代理应该做的事情。
“沙盒逃脱周”
Pillar Security 的研究团队——Eilon Cohen、Dan Lisichkin 和 Ariel Fogel——在几个月内重现了这些绕过方法，并将其作为一个系列发布，他们称之为“沙箱逃逸周”，每天发布一篇文章。研究人员将他们的七项发现分为四种不同的故障模式。
一类是他们所描述的拒绝名单沙箱——试图阻止特定危险行为而不是只允许安全行为的沙箱。拒绝者是出了名的脆弱，因为他们依赖于预测每一次可能的攻击，而逃脱事件表明，特工如何通过使用最初从未出现在拒绝名单上的外部工具来绕过被阻止的操作。
四个受影响的工具——Cursor、OpenAI 的 Codex、谷歌的 Gemini CLI 和 Antigravity——代表了人工智能编码代理市场的广泛领域，从消费者 IDE 插件到企业命令行工具。这种广度表明问题不是任何单个产品中的错误，而是研究无效的共享架构假设。
为什么这对代理经济很重要
其影响超出了个体开发人员的范围。随着编码代理嵌入到自动化管道、持续集成系统和自主工作流程中，沙箱逃逸成为供应链攻击的潜在立足点。可以通过依赖项、克隆存储库或受损贡献者将中毒文件放入存储库的攻击者可以想象将受信任的编码代理转变为开发人员计算机上的执行向量。
这与 2026 年早些时候出现的风险属于同一类，当时研究人员发现在 Cursor 中打开恶意存储库可以在 Windows 上静默执行代码。沙箱逃逸概括了这种威胁：它不是一种工具或一个平台，而是沙箱代理与周围可信工具之间的交互模型。
可信文件的难题
根本困难在于，编码代理的沙箱无法将所有工作区文件视为不受信任，而不削弱代理的有用性。代理需要编写代码、配置和脚本，并且开发人员的工具需要读取这些文件并对其进行操作。剥夺了这种信任，代理人就无法发挥作用；保留它并且逃逸向量仍然存在。
皮勒的研究并没有提供单一的临时解决方案，这就是研究结果重要的部分原因。他们提出了行业必须共同解决的设计问题——通过代理工作区和主机执行表面之间更强的隔离，通过对代理编写的文件进行签名或证明，或者通过重新考虑允许哪些工具自动执行工作区内容。
对于今天使用 Cursor、Codex、Gemini CLI 或 Antigravity 的开发人员来说，实际的收获是要谨慎对待不受信任的输入：克隆存储库、第三方依赖项和贡献的代码应被视为可能携带提示注入，该注入不仅针对模型，还针对其周围的文件系统。
保持人工智能领先地位
有关人工智能安全、编码代理及其引入的基础设施风险的持续报道，请关注我们的人工智能行业报道。
阅读更多人工智能新闻
