我们习惯于从一个角度阅读网络安全中的 AI：攻击者利用智能体更快地行动。第二个角度对您的组织更重要，却很少受到关注。您在自己开发机器上运行的智能体，本身就是一个新的攻击面。在两个月内，三个独立研究团队发布的发现都指向同一个方向。

这些案例的共同点不是模型的缺陷，也不是糟糕的回答。智能体从未逃出它的沙箱，也从未违反任何规则。实际发生的是：智能体读取或写入了项目中的一个文件，然后一个在沙箱外运行的受信任工具执行了该文件的内容。沙箱守住了。入侵绕过了它。

机制：一个存在多年的 Git 性能设置

最清晰的例子由 Manifold Security 于 2026 年 9 月 2 日以 GitSpawn 之名发布。它利用的是一个名为 core.fsmonitor 的项目级 Git 设置，这是一个合法且有文档记录的性能选项，其值是 Git 为快速识别已更改文件而运行的一条命令，从而无需扫描整个目录。

现在把两半放在一起：

  • AI 编程智能体在开始处理一个项目时，会自动运行 git status 和 git diff 等 Git 命令来了解仓库状态。这是正常且必要的行为。
  • 如果仓库带有恶意的 core.fsmonitor 值，只要运行这些命令就会运行攻击者的命令。

结果是，打开一个代码仓库不再是一次读取事件，而变成了一次执行事件。没有点击，没有批准，也没有向开发者显示任何提示。根据报告，八款命令行智能体受到影响，其中几款随后发布了补丁：goose 的 1.44.0，Claude Code 针对 core.fsmonitor 路径的 2.1.196，Codex CLI 的 0.131.0，以及 Cursor。报告指出发布时仍有四条路径未修补。这类问题以包括 CVE-2026-72718、CVE-2026-19592 和 CVE-2026-55607 在内的编号进行跟踪。

不是单一事件，而是一整类问题

在 GitSpawn 之前六周，Pillar Security 的研究人员于 2026 年 7 月 20 日发布了一个系列，他们称之为沙箱逃逸周，记录了来自三家供应商的四款编程智能体中的七个漏洞：Cursor、Codex、Gemini CLI 和 Antigravity。他们对机制的描述值得读两遍。智能体待在盒子里，遵守每一条规则。它只是写了一个文件，而盒子外的受信任工具随后会运行、加载或扫描这个文件。

  • 在 Cursor 中，一个由工作区控制的钩子配置文件使沙箱外执行成为可能，编号为 CVE-2026-48124，已在 3.0.0 版本中修复。
  • 在 Codex CLI 中，命令允许列表仅凭名称就信任 git show，尽管传给它的参数可以使它不再只是只读操作。已在 0.95.0 版本中修复。
  • 一个 Docker 套接字问题同时影响了 Codex、Cursor 和 Gemini CLI。
  • 在 Antigravity 中，存在一个 macOS Seatbelt 拒绝列表绕过问题和一个编辑器任务配置问题，Google 将两者都归类为难以利用。

随后在 2026 年 9 月 10 日，Upstarts Media 报道了第三次披露，来自一家名为 Accomplish 的初创公司，涉及 Claude Code、Codex 和 Cursor 中存在泄漏的沙箱。其中有意思的数字不是漏洞本身，而是修复时间：Cursor 的问题大约一周就解决了，OpenAI 的两个问题在八月解决，而 Anthropic 的问题历经数十个版本，耗时约五十天。三个研究团队，三份报告，两个月，一种模式。

为什么即使您从不写代码，这也很重要

因为风险并不落在智能体身上。它落在运行智能体的机器以及这台机器所在的网络上。开发者工作站是任何公司中权限最高的设备之一：它保存着服务器访问密钥、部署令牌，而且往往有一条通往生产数据库的开放连接。在它上面执行一条命令绝非小事。

在沙特市场，这一场景并非纸上谈兵。请对照您自己的公司检查以下情况：

  • 外部承包商或开发机构交付代码，您的团队随后在您网络内的机器上用 AI 智能体打开这些代码。
  • 开源项目，开发者下载它来试用某个库或某个快速修复。
  • 通过电子邮件或 WhatsApp 发送的文件，来自供应商，解压后直接在编辑器中打开。
  • 求职候选人提交的示例项目，由技术评审人员打开。
  • 旧分支或转交的仓库，在收购或项目交接期间移交。

在上述每种情况中，未言明的假设都是：打开文件来阅读是安全的行为。恰恰是这个假设被打破了。

本周该做什么

五个步骤，第一步不需要任何预算：

  1. 今天就在整个团队中更新智能体工具。这些工具大多已有补丁，价值在于每个人都使用已修补的版本，而不是只有一个人。先弄清楚谁在运行什么、是哪个版本，因为这份清单本身通常就不存在。
  2. 将传入的代码视为不受信任的内容。来自承包商或开放来源的代码不是供您阅读的文档，而是会被执行的东西。第一次打开时，请在与工作网络隔离的机器或容器中进行。
  3. 将开发机器与生产密钥分开。不要在打开外部来源项目的机器上保存线上服务器令牌。这样损失就只限于那台设备。
  4. 通过中央流水线而不是个人笔记本电脑进行部署。当部署经过一条权限受限的构建流水线时，攻破单台机器就不再是通往生产环境的途径。
  5. 在外包开发合同中加入一项条款。您有权规定代码如何交付、从哪个仓库交付，并要求供应商保持其工具更新。这是合同条款，而不是技术争论。

在本地层面，这些都不是可有可无的良好实践。国家网络安全局（NCA）发布的基本网络安全控制措施包含终端安全、变更与开发管理安全以及第三方安全等明确领域，而根据《个人数据保护法》（PDPL），个人数据保护的责任仍由组织承担。如果大门是通过一台打开了供应商项目的开发者机器被打开的，这并不会减轻责任。

Origami 的观点

我们将这三份报告解读为对一种迅速流行的观点的纠正：只要智能体被锁在沙箱里，沙箱就足够了。这些漏洞并没有打破隔离。它们利用了一座合法的桥梁，把盒子里写下的东西带给在盒子外运行的工具。这意味着正确的问题不是智能体是否在沙箱中，而是哪些工具会读取智能体产生的内容，以及这些工具以什么权限运行。

根据我们在客户那里看到的情况，有一个实际观察：开发团队对 AI 工具的采用比任何管理它的政策都要领先好几个月。开发者试用了一个工具，觉得好用，它就在没有决策、没有审查、没有登记的情况下成为日常工作流程的一部分。问题不在工具本身。问题在于它是从一扇无人看守的门进来的。我们审查客户环境时恰恰从这里开始：团队机器上实际运行着哪些工具，具有什么权限，以及如果今晚其中一台机器上执行了一条命令会发生什么。如果您希望从这个角度进行审查，可以在联系页面找到我们。

结论

两个月内三次独立披露说明了同一件事：AI 编程智能体把打开项目从读取变成了执行，而外部人员只需在配置文件中放入一行内容即可。大多数工具已发布补丁，部分路径仍然敞开，但这一教训比任何版本都更长久。您在高权限机器上运行的任何工具都是您攻击面的一部分，无论您的政策是否列出了它。从一个问题开始：您的团队中此刻谁在运行 AI 智能体，在哪台机器上，是哪个版本？

来源