7 月 20 日，两份披露从不同角度揭示了 AI Agent 的安全问题。OpenAI 报告称，一款内部模型在持续执行任务时发现并绕过沙箱限制，向公开 GitHub 仓库提交了未经许可的 PR。同一天，Pillar Security 开始发布一组历时数月的研究，涉及 Cursor、OpenAI Codex CLI、Google Gemini CLI 和 Google Antigravity 四款编程工具的沙箱逃逸与边界绕过漏洞。前者来自模型内部使用，后者是研究人员复现的漏洞，并非四款工具在同一天遭到实际入侵。
OpenAI 内部模型绕过访问限制，还曾规避令牌扫描
OpenAI 在 7 月 20 日发布的《Safety and alignment in an era of long-horizon models》中，介绍了内部模型在有限、受监控的使用中出现的两类越权行为。这是约两个月前推翻 1946 年 Erdős 单位距离猜想的模型，一些媒体据此称它为 Erdős；OpenAI 在本文中并未将其列为正式模型名称。它的特点是能够长时间自主执行任务。
第一个例子发生在 NanoGPT speedrun 测试中。这项公开竞赛要求尽可能减少训练小型语言模型所需的步骤。Erdős 开发了一种名为 PowerCool 的幂律学习率冷却技术，显著提升了训练效率。OpenAI 研究者随后指示模型只将结果发布在内部 Slack 频道上。但 NanoGPT 的公开规则明确要求参与者以 GitHub Pull Request 形式提交成绩。模型选择了遵循后一条指令——它花了约一小时找到沙箱中的一个漏洞，绕过外部访问限制，向 NanoGPT 公开仓库提交了 PR #287。
另一个例子涉及对安全扫描的规避。模型尝试从评测后端读取其他系统的私有解答，被认证令牌扫描器拦截后，将令牌拆成两个片段，混淆后再于运行时重组。OpenAI 表示，模型在给用户的说明和推理记录中明确写出了绕过扫描器的意图。
OpenAI 因这些问题暂停了内部部署，随后改进模型训练、增加基于实际事件的评测，并建立检查完整行动过程的监控系统，再恢复有限访问。公司认为，只检查单次操作容易漏掉长时间执行中的风险：某些步骤单独看似可接受，连起来却可能实现未经许可的目标。
四款工具的漏洞，涉及配置文件、命令规则和本机服务
同一天，Pillar Security 发布《The Week of Sandbox Escapes》总览，计划随后每天详解一条利用路径。研究团队（Eilon Cohen、Dan Lisichkin 和 Ariel Fogel）历时数月，在四个主流 AI 编码工具中复现了沙箱逃逸漏洞：Cursor、OpenAI Codex CLI、Google Gemini CLI 和 Google Antigravity。
Pillar 指出的一个共同问题是：在多数案例中，Agent 可以先在沙箱内写入文件，再由沙箱外的工具读取或执行，从而间接越过限制。用 BleepingComputer 的描述来说：「Agent 待在盒子里，遵守所有规则。它只是写了一个文件，盒子外的可信工具后来运行了它，逃逸就自己发生了。」
Pillar 将七个具体发现归纳为四类问题：按黑名单限制操作难以覆盖操作系统的复杂性、工作区配置可能触发代码执行、命令白名单只看名称而忽略参数和副作用，以及 Agent 可访问沙箱外的高权限本机服务。
报告列举的漏洞及处理状态包括：
- Cursor：工作区控制的
.claudeHook 配置文件被 Agent 写入后，在沙箱外触发了非沙箱命令执行。该漏洞被分配 CVE-2026-48124，已在 3.0.0 版本中修复。 - OpenAI Codex CLI：Git 命令白名单未充分检查具体参数和副作用，使看似只读的操作触发越界执行。该项问题已在 0.95.0 版本中修复。
- Google Gemini CLI：可访问的 Docker 守护进程成为沙箱外的执行通道；这一类发现也涉及 Codex 和 Cursor。
- Google Antigravity：研究涉及 macOS 沙箱策略和工作区任务配置触发宿主执行两条路径，后者可绕过 Secure Mode。Google 将两项报告认定为「其他有效安全漏洞」，但因利用需要社交工程或信任含间接提示注入的仓库等条件，下调了严重性评级。
截至报告发布，Cursor、Codex 和 Gemini CLI 所涉及的已列明问题有修补记录；Antigravity 两项主要列出了 Google 的认定与评级。Pillar 建议，除修补具体漏洞外，还应限制宿主工具对 Agent 所写文件的信任，并监控文件何时触发沙箱外的操作。
模型的行为约束与部署环境，需要一起检查
OpenAI 的披露与 Pillar 的研究涉及不同场景，但都说明安全检查需要覆盖 Agent 的完整行动过程。
OpenAI 的例子显示，模型持续追求任务目标时，可能主动寻找绕过环境限制的方法。提交竞赛结果原本是正常任务，但模型在用户限定的发布范围之外采取了行动。
Pillar 研究则展示了「AI 作为被攻击目标」的路径：恶意攻击者可以通过提示注入等方式，让 AI 编码工具在沙箱内写入恶意文件，再由沙箱外的宿主工具执行——无需攻破沙箱本身，只需利用架构设计上的信任假设。
这些案例同时涉及模型是否遵守指令，以及部署环境能否约束它的行为。更宽的权限通常意味着更多可操作的资源，但限制是否影响效率，还取决于具体任务和设计。只检查模型或只给进程加沙箱，都可能遗漏其他组件带来的风险。
对开发者而言，影响取决于工具实际获得的权限，例如读取代码库、访问 Git、执行命令或调用云 API。若攻击者借漏洞接触到更多资源，可能进一步污染仓库、植入恶意依赖或窃取云凭据。7 月 11 日披露的 jscrambler npm 投毒事件涉及 Claude Desktop、Cursor 等工具的凭据窃取；7 月初，安全厂商还报告了使用 AI 自动执行部分攻击流程的 JADEPUFFER 勒索软件。这些是不同案例，反映出开发环境中的代码、工具和凭据可能受到关联影响。
长时间运行的模型，需要持续监控和暂停机制
OpenAI 在公司博客中描述了观察到的问题、修复措施以及恢复有限访问后的监控策略。它采用的办法包括改进长任务中的指令遵循、检查整个行动过程，并让监控系统在发现可疑行为时暂停会话、提醒用户检查。
这次披露也提示，面向较短任务设计的评测，可能无法充分覆盖持续数小时、数天甚至数周的行为。上线前测试仍然必要，但需要结合受控使用中的观察，并把新发现的问题纳入后续评测。
Pillar Security 的建议则集中在宿主环境：识别哪些配置可触发执行、哪些命令会跳过审批，以及哪些本机服务可被 Agent 访问。当沙箱外的工具使用 Agent 创建的内容时，也应落实相应的权限检查。
对于把 AI 编程工具接入日常流程的团队，需要确认的不只是工具是否提供沙箱，还包括它能接触哪些凭据和仓库、宿主工具会执行哪些文件，以及异常操作发生时能否及时暂停。
