文章总结： AI编程Agent通过写入可被宿主机信任的配置文件、脚本或钩子文件，间接触发外部高权限进程执行，实现沙箱逃逸，而非直接攻破隔离机制。关键风险在于Agent能修改项目上下文并影响后续构建或测试流程，导致供应链攻击。建议企业将AI工具视为终端组件管理，限制陌生仓库操作，隔离开发环境，关闭自动命令执行，并明确沙箱边界与日志审计。 综合评分： 92 文章分类： AI安全,安全建设,应用安全,终端安全,供应链安全

---

AI 编程 Agent 沙箱为何失守？

NowSec NowSec

NowSec

2026年7月28日 10:32 陕西

在小说阅读器读本章

去阅读

过去聊 AI Agent 安全，很多人第一反应是“越狱”。

让模型突破系统提示词，绕过安全策略，回答原本不该回答的内容。

但对编程 Agent 来说，真正危险的地方不只是它会不会“说错话”。

而是它能不能动你的文件，能不能改你的项目，能不能运行命令，能不能影响宿主机上的开发工具。

Cursor、OpenAI Codex CLI、Google Gemini CLI、Antigravity 这几类 AI 编程工具最近被研究人员集中拿出来分析，问题指向同一个方向：Agent 不一定要正面打破沙箱，只要它能写入一些宿主机会信任的文件，沙箱边界就可能被绕过去。

Pillar Security 在 2026 年 7 月 20 日发布的研究中提到，他们在数月时间里复现了 Cursor、Codex、Gemini CLI 和 Antigravity 中的沙箱逃逸或边界绕过问题。多数情况下，Agent 并没有直接攻破沙箱，而是写入了某些文件，之后由沙箱外的可信组件加载、执行、扫描或当作安全配置处理。Pillar 给出的结论很直接：Agent 的影响范围不是 Agent 进程本身，而是包括它能写入、并且宿主机后来会信任的一切内容。(pillar.security)

这句话才是重点。

如果 Agent 能写入未来会被宿主机信任的输入，它就不是真的被关在沙箱里。

---

一、这次问题不是“沙箱被正面打穿”

很多人看到“沙箱逃逸”，会想到传统漏洞：

容器逃逸
内核漏洞
权限绕过
系统调用缺陷
虚拟机逃逸

这类逃逸是直接攻击隔离机制。

但这次 AI 编程 Agent 暴露的问题更绕，也更贴近真实开发环境。

研究人员描述的典型模式是：

Agent 在沙箱内运行
  ↓
Agent 被允许修改项目文件
  ↓
项目文件被宿主机上的 IDE、Git、构建工具、本地服务或插件读取
  ↓
这些宿主机组件在沙箱外运行
  ↓
攻击者影响的内容以宿主机权限执行或生效

也就是说，攻击者不一定要把 Agent 从沙箱里“挖出来”。

他只需要让 Agent 写下一些东西。

逃逸发生在后面。

当宿主机上的可信组件处理这些东西时，原本属于沙箱内的影响就被带到了沙箱外。

BleepingComputer 对这次事件的描述也强调，研究人员不是正面攻击沙箱机制，而是利用了 Agent 写入文件后，外部可信工具继续读取和执行这些文件的路径。(bleepingcomputer.com)

这就是 AI 编程 Agent 和普通聊天机器人的区别。

聊天机器人最多给你一段错建议。

编程 Agent 会改仓库。

仓库里的某些文件，恰好会被宿主机当成配置、脚本、插件入口、构建规则或开发环境指令。

---

二、为什么“能写文件”本身就是高危能力？

对开发者来说，让 Agent 写文件很正常。

不用它写文件，它就只能给你贴代码，你还得自己复制。

所以现在的 AI 编程工具通常会让 Agent 做这些事：

读取项目结构
修改源码
新增测试
更新依赖
编辑配置
运行命令
修复报错
提交补丁
生成脚本

OpenAI Codex CLI 官方文档也把它定位为可以在终端里检查代码、修改文件、运行命令、自动化重复工作的工具，并说明它可以在本地仓库里检查文件、编辑代码、运行本机已有工具。(learn.chatgpt.com)

Gemini CLI 官方配置文档也提到，它可以在沙箱中执行潜在不安全的操作，例如 shell 命令和文件修改；其沙箱默认可通过参数或环境变量启用，并默认使用 Docker 镜像。(github.com)

这些能力本身不是问题。

问题在于：项目目录不是一个普通文件夹。

在开发环境里，很多文件不是“静态文本”，而是会触发行为。

例如：

IDE 配置
编辑器插件配置
构建脚本
测试脚本
Git 配置
Git Hooks
包管理器脚本
Docker 配置
CI/CD 配置
本地任务配置
Agent 自己的规则文件

一个普通 Markdown 文件，也许只是说明文档。

但一个项目配置文件，可能会影响 IDE 怎么加载扩展、终端怎么启动任务、包管理器怎么执行生命周期脚本、Git 怎么处理提交钩子。

如果 Agent 可以写这些文件，而宿主机上的工具会自动信任它们，那沙箱边界就开始变得很模糊。

所以这次问题的核心不是：

Agent 会不会写恶意代码？

而是：

Agent 写的东西，会不会被另一个更高权限、更可信的宿主机进程执行？

---

三、以前的沙箱模型，可能不适合 Agent

传统沙箱大多关心三件事：

进程能不能访问哪些文件
进程能不能访问网络
进程能不能执行哪些系统调用

这对普通程序比较有效。

比如你把一个命令放进容器里，限制它只能读写某个目录，不能访问网络，不能访问宿主机敏感路径。这样它就算出问题，影响也被限制在容器内。

但 Agent 不一样。

Agent 是一个“持续影响环境”的执行者。

它会根据提示词、仓库内容、报错信息、README、Issue、测试结果做决定。它不是一次性运行一个命令，而是不断读、写、改、试。

Pillar 把这次问题归纳成几个重复出现的失败模式，包括：基于 denylist 的沙箱跟不上操作系统复杂度、工作区配置本身就是可执行代码、命令 allowlist 只信任命令名而不看完整调用、特权本地 daemon 位于沙箱之外等。(pillar.security)

这里有一个很现实的问题：

沙箱限制的是 Agent 当前正在做什么，但没有限制 Agent 写下来的东西以后会被谁信任。

这和传统 Web 安全有点像。

你过滤了当前请求，不代表后面读取数据库时就安全。

如果攻击者把恶意内容写进数据库，等管理员后台打开时触发，这叫存储型攻击。

Agent 沙箱也类似。

当前看，Agent 只是写了一个文件。

后面看，这个文件变成了宿主机执行路径的一部分。

---

四、配置文件为什么会变成逃逸入口？

配置文件最容易被低估。

因为它看起来不像代码。

但在开发环境里，很多配置本身就是“延迟执行的代码”。

Cymulate 在 2026 年 4 月提出过一类问题，称为 Configuration-Based Sandbox Escape，基于配置的沙箱逃逸。他们的研究指出，多种 AI CLI 工具都存在类似风险：攻击者不需要攻击容器或操作系统，而是利用 Agent 的配置、启动行为和信任边界，让沙箱内写入的配置在下一次宿主机启动工具时被加载，从而以宿主机用户权限执行。(cymulate.com)

这类问题很符合开发环境的实际情况。

开发者每天都在运行各种工具：

npm install
npm test
pnpm build
git commit
docker compose up
make
pytest
pre-commit
IDE 自动任务
扩展自动扫描

这些工具会读取项目里的配置文件。

很多时候，开发者甚至不会意识到某个文件被读取了。

如果 Agent 在处理一个不可信仓库时，按照 README 或恶意提示修改了这些配置，那么后续只要开发者在宿主机上执行正常操作，就可能把沙箱内影响带出来。

注意，这里不需要开发者故意运行一个明显可疑的命令。

他可能只是打开 IDE。

也可能只是启动项目。

也可能只是跑测试。

也可能只是提交代码。

这就是这类问题难防的地方。

它不像传统恶意软件那样弹出一个明显的可执行文件。

它藏在开发工作流里。

---

五、为什么 Docker socket 也是高危边界？

这次 Pillar 的系列文章里，有一篇专门讨论 Docker socket 问题，标题是 “One Docker socket to rule them all”。文章指出，相关逃逸发生在 Docker VM 内部，而这个位置已经不在原本沙箱的管辖范围里。(pillar.security)

Docker 对开发者很正常。

但从安全角度看，Docker socket 一直是敏感资源。

因为能控制 Docker daemon，往往就能影响宿主机上的容器、镜像、挂载、网络和运行参数。

很多开发机上会有这样的习惯：

把项目目录挂进容器
把 Docker socket 暴露给工具
让构建工具自动调用 Docker
让本地 agent 直接操作容器

这对效率很友好。

对隔离很不友好。

如果 Agent 的沙箱只是限制了某个进程，但它能间接影响 Docker daemon，或者写入 Docker 后续会处理的配置，那真正的边界就不是沙箱了。

边界变成了 Docker daemon。

而 Docker daemon 往往比 Agent 权限更高。

这就是 Agent 安全里经常被忽略的一点：

你看到的是 Agent 在沙箱里，实际执行权可能落在沙箱外的本地服务上。

---

六、命令 allowlist 为什么不够？

很多工具会提供 allowlist。

比如只允许 Agent 自动执行：

ls
cat
grep
npm test
go test
pytest

看起来很安全。

但问题是，命令名安全，不代表完整调用安全。

同一个命令，在不同参数、不同环境变量、不同工作目录、不同配置文件下，行为可能完全不同。

比如：

npm test

它看起来只是测试。

但实际运行什么，要看 package.json 里怎么写。

再比如：

git

它看起来只是版本控制工具。

但 Git 会读取配置、hooks、属性文件，也可能触发外部工具。

再比如：

make

它本身只是构建入口。

真正执行什么，要看 Makefile。

所以，只看命令名是不够的。

Pillar 在总结中也提到，“安全命令 allowlist 信任命令名，而不是完整调用”是这类失败模式之一。(pillar.security)

对 Agent 来说，更麻烦的是：

Agent 不只是运行命令，它还能修改这个命令后续会读取的配置。

你今天允许它运行 npm test。

它上午修改了 package.json。

下午再运行 npm test。

这时，命令名没变，实际行为可能已经变了。

---

七、这不是某一个工具的问题

这次之所以值得写，不是因为某个厂商踩坑。

而是因为 Cursor、Codex、Gemini CLI、Antigravity 这些工具都在不同程度上碰到了相近边界问题。

Pillar 的汇总显示，这批问题并不是由单一漏洞构成，厂商处置也不完全相同：Cursor 的工作区 Hook 问题被跟踪为 CVE-2026-48124，并在 3.0.0 中修复；Codex CLI 的 Git allowlist 问题在 0.95.0 中修复。对于 Docker socket 这条近似攻击链，Cursor 选择修复，Codex 将报告定为 informational，Gemini CLI 则认为相关风险已在文档中披露。Antigravity 的相关问题被 Google 确认为有效安全发现，但因利用条件等因素降低了严重性。(pillar.security)

这说明问题不是“谁写得差”。

而是 AI 编程 Agent 这种产品形态本身改变了终端威胁模型。

过去开发者打开一个陌生仓库，风险主要来自：

恶意依赖
恶意构建脚本
恶意 Git Hook
恶意 IDE 配置
恶意文档诱导

现在又多了一层：

恶意仓库内容诱导 Agent 修改更多文件
Agent 自动运行命令
Agent 自动接受项目上下文
Agent 自动信任仓库里的说明
Agent 把攻击者意图扩展成真实改动

这就是新风险。

以前攻击者要骗开发者执行命令。

现在攻击者可以先骗 Agent。

而 Agent 比人更愿意“帮你把事情做完”。

---

八、为什么恶意仓库会更危险？

很多开发者已经习惯这样用 Agent：

clone 一个项目
打开 Cursor
让 Agent 看 README
让 Agent 帮忙跑起来
让 Agent 修复报错
让 Agent 安装依赖
让 Agent 改配置
让 Agent 跑测试

这个流程很自然。

但如果项目本身不可信，就很危险。

攻击者可以在仓库里布置内容：

README
Issue 模板
贡献指南
Agent 指令文件
包管理器配置
构建脚本
测试脚本
IDE 配置
Docker 配置

这些东西不一定马上执行。

它们可以先影响 Agent 的判断。

Agent 看到“为了修复测试，请更新某个配置”。

它可能照做。

然后宿主机上的工具再读取这个配置。

整个攻击链看起来像正常开发：

开发者打开项目
Agent 阅读项目说明
Agent 修改配置
开发者运行测试
宿主机执行被污染的配置

没有明显的“黑客行为”。

没有明显的恶意二进制。

也没有显眼的网络连接。

所以这类风险很适合供应链攻击。

攻击者不一定盯你的生产服务器。

他可以盯你的开发机。

开发机上有：

Git 凭据
SSH Key
云平台凭据
npm / PyPI / Docker Token
内部仓库访问权限
生产配置样例
VPN 会话
浏览器登录态

一旦开发机被控制，后面的供应链风险就不小。

---

九、企业使用 AI 编程助手，不能只靠员工自觉

很多企业现在对 AI 编程工具的管理比较粗：

能不能用？
能用哪些？
不能上传代码？
不要泄露密钥？

这还不够。

因为问题已经不是“代码会不会被发给模型”。

而是 Agent 会不会影响本地环境。

安全团队需要把 AI 编程工具当成新的终端执行组件来管理。

至少要问清楚：

哪些人能用？
能在哪些项目用？
能不能处理外部仓库？
能不能自动写文件？
能不能自动运行命令？
沙箱默认是否开启？
沙箱能写哪些目录？
能不能访问 Docker？
能不能访问 SSH Key？
能不能访问云凭据？
能不能修改 Git 配置和 hooks？
操作日志在哪里？
升级版本由谁负责？

Pillar 在总结里也说，CISO 和安全采购方不能只听产品说“有沙箱”，而要看沙箱边界在哪里、Agent 能写什么、哪些宿主机组件会信任这些写入、本地 daemon 能不能被接触、哪些命令会跳过审批、可信 helper 执行受 Agent 影响的内容时有没有遥测。(pillar.security)

这已经不是“开发效率工具”的采购问题。

这是终端安全问题。

---

十、怎么降低风险？

这类问题没有一个万能开关。

但可以按几个原则压风险。

1. 不要在高权限开发环境里处理陌生仓库

陌生仓库、外包交付代码、开源样例、网上下载的 PoC 项目，不要直接放进主力开发机环境里让 Agent 自动操作。

更合适的方式是：

单独虚拟机
一次性容器
无敏感凭据环境
无内网访问环境
只读挂载敏感目录
关闭自动命令执行

不要让 Agent 在同时拥有外部输入和内部权限的环境里工作。

---

2. 把“写文件”和“执行命令”分开审批

很多工具把“修改代码”和“运行命令”都交给 Agent。

建议至少区分：

读文件
改普通源码
改配置文件
改构建脚本
改 Git 配置
运行测试
安装依赖
访问网络
调用 Docker
修改权限
提交代码

这些动作风险不一样。

改一个页面文案，和改一个构建脚本，不应当是同一级别审批。

---

3. 对敏感文件做保护

Agent 不应该随便改这些东西：

.git/config
.git/hooks/
.ssh/
.env
.env.*
package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
Makefile
Dockerfile
docker-compose.yml
.vscode/
.idea/
.github/workflows/
.gitlab-ci.yml
AGENTS.md
各类 agent 配置文件

不是说这些文件永远不能改。

而是修改时必须让人明确看见差异。

尤其是 Git hooks、包管理器脚本、CI 配置、本地 IDE 配置、Agent 自身规则文件。

这些地方经常决定“下一步会执行什么”。

---

4. 不要把 Docker socket 暴露给 Agent

除非非常明确，否则不要让 Agent 直接或间接操作 Docker daemon。

如果必须使用容器，也要控制：

禁止挂载 Docker socket
限制特权容器
限制宿主机目录挂载
限制网络访问
限制容器逃逸面
限制持久化卷

Docker 不是天然沙箱。

很多时候，它是开发效率工具，不是安全边界。

---

5. 对外部仓库默认关闭自动执行

从外部 clone 下来的项目，默认不要让 Agent 自动跑命令。

先让它只读分析。

需要执行时，人工确认命令和上下文。

确认时不要只看命令名。

要看：

当前目录
完整参数
环境变量
会读取哪些配置
会触发哪些脚本
是否访问网络
是否写入敏感目录

一句“运行测试”不够。

要知道测试实际会跑什么。

---

6. 给开发机做凭据隔离

开发机上不要长期堆满高权限凭据。

尤其是：

云平台 AK/SK
生产 kubeconfig
npm 发布 Token
Docker Registry Token
GitHub PAT
SSH 私钥
VPN 配置
数据库连接串
内部制品库账号

Agent 风险一旦变成开发机失陷，这些东西就是攻击者真正想要的目标。

---

7. 记录 Agent 操作日志

企业使用 Agent，不能只看最终代码。

要能回溯：

Agent 读了哪些文件
改了哪些文件
运行了哪些命令
哪些命令被人工批准
哪些文件触发了宿主机工具
是否访问网络
是否调用 Docker
是否修改 Git 或 CI 配置

没有日志，就很难判断一次异常构建、异常提交、异常凭据访问是不是和 Agent 有关。

---

十一、对安全团队来说，新的检查项是什么？

过去做终端安全，重点可能是：

EDR 是否在线
杀毒是否更新
补丁是否完成
弱口令是否存在
高危软件是否安装

以后要加上 AI 编程工具检查项：

是否安装 Cursor / Codex CLI / Gemini CLI / Antigravity 等工具
版本是否为修复版本
沙箱是否默认启用
自动执行模式是否开启
是否允许 Agent 访问外部仓库
是否允许 Agent 调用 Docker
是否允许 Agent 修改配置和 hooks
是否允许 Agent 访问企业内部代码
是否有操作审计
是否有团队统一策略

这类工具已经不是普通编辑器插件。

它们能读代码，改文件，跑命令，访问工具链。

在终端安全模型里，它们更像一种新的本地自动化执行器。

只要能执行，就要治理。

---

十二、这件事真正说明了什么？

这次 Cursor、Codex、Gemini CLI、Antigravity 的沙箱逃逸问题，不应该被简单理解成“几个产品有漏洞”。

它说明的是更基础的变化：

开发环境的攻击面被 Agent 放大了。

以前，恶意仓库要影响开发者，需要开发者自己执行命令。

现在，恶意仓库可以先影响 Agent。

Agent 会帮它读说明、修错误、写配置、跑脚本、连工具。

这不是模型“太聪明”的问题。

这是权限边界没跟上。

Agent 的能力越接近真实开发者，它就越需要接受真实开发者级别的安全约束。

不能因为它叫“助手”，就把它当成普通聊天窗口。

它已经会动手了。

会动手，就会闯祸。

---

十三、最后

AI Agent 的风险，不只是越狱。

越狱只是让模型说出不该说的话。

编程 Agent 的沙箱逃逸，是让工具做出不该做的事。

这两者的后果不在一个层级。

一个影响回答。

一个影响宿主机。

一个是内容安全问题。

一个是终端安全、供应链安全、开发环境安全问题。

这次事件最值得记住的一句话是：

沙箱限制了 Agent 当前能做什么，但如果宿主机未来会信任 Agent 写下来的东西，这个沙箱就没有你想象中那么完整。

所以，企业使用 AI 编程工具时，不要只问：

它代码写得准不准？
它效率高不高？
它有没有沙箱？

还要问：

沙箱外面，谁会相信它写过的文件？

这个问题答不清楚，Agent 就不是被关起来的助手。

而是一个坐在开发机里的自动化执行入口。

---

参考资料

1. Pillar Security：The Week of Sandbox Escapes
2. Pillar Security：One Docker socket to rule them all: escaping Codex, Cursor, and Gemini CLI’s sandboxes
3. BleepingComputer：Cursor, Codex, Gemini CLI, Antigravity hit by sandbox escapes
4. Cymulate：Configuration-Based Sandbox Escape in AI Coding Tools
5. OpenAI：Codex CLI 官方文档
6. Google Gemini CLI：Configuration / Sandboxing 文档
7. Cursor：Implementing a secure sandbox for local agents

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：NowSec NowSec NowSec《AI 编程 Agent 沙箱为何失守？》