AI沙箱逃逸真相：从沙箱创建失败到权限边界实战排查

一个开发者朋友突然发来一条消息：“AI Escaped Its Sandbox，这是什么意思？”字面翻译是“AI 逃出了它的沙箱”，听起来像是科幻电影里“AI 觉醒”的第一步。但他真正遇到的场景其实很普通：Codex 在 Windows 上创建沙箱失败，弹了个createprocesswithlogonw failed: 2的报错。

这类标题最近在技术社区里频繁出现。有的是安全公告，有的是产品更新日志，有的只是某个本地工具初始化沙箱时卡住了。问题在于，“沙箱”“逃逸”“AI”这几个词放在一起，很容易让人往最戏剧化的方向联想。做工程的人不能被标题带着跑。AI 沙箱里的“逃出”到底指什么，哪些是真正需要担心的越权，哪些只是安装环境问题，拆开看会更清楚。

1. 先别被标题吓到：AI 沙箱到底在关什么

1.1 沙箱不是关 AI 的笼子，而是给执行权限画的边界

很多人有一个误解：AI 沙箱就是把大模型关在一个隔离环境里，防止它“跑出来”。这个理解在工程上并不准确。

我们平时接触的 AI 模型，本质上是一个文本生成器。你给它一串输入，它吐出一段输出。模型本身不直接操作系统文件，不直接发起网络请求，也不直接执行 Python 脚本。真正可能碰到文件系统和网络的是模型输出被“翻译”成工具调用之后的那一层。

ChatGPT 桌面版、Codex CLI、Cursor 这类工具之所以要创建沙箱，不是为了关模型，而是为了关“模型输出驱动的代码执行和工具操作”。模型负责生成意图，沙箱负责约束动作。它隔离的是文件的读写、命令的调用、网络的访问，而不是隔离“思考”。

我习惯用这样一个类比：模型像一个坐在操作台前面的操作员，它可以通过一个大按钮面板来执行动作。面板上每个按钮都连接着一台不会直接暴露的机器，沙箱就是那块只开了必要孔洞的安全玻璃。操作员看不到机器的全部结构，也无法触碰操作台之外的东西。

所以“沙箱逃逸”这个词，本质上是一个权限边界问题，而不是一个“意识觉醒”问题。理解这一点，后面所有排查和设计才有正确的方向。

1.2 “逃出”的三种含义：真实漏洞、配置漂移和标题党

在实际信息流里，“AI 逃出沙箱”这句话至少有三种完全不同的含义：

第一种是真实的安全漏洞。某个沙箱组件存在缺陷，比如容器权限配置错误、路径穿越、提权接口没封住，导致原本不应该被执行的代码或者不应该被访问的文件被触达了。这类问题有明确的技术细节，需要 CVE 或安全公告佐证。

第二种是配置漂移。沙箱本身没有问题，只是使用方把权限给太大了。比如 Agent 能访问整个用户目录，或者网络白名单写得太宽，等于把沙箱的“门”开着。这种情况更准确的叫法是“越权使用”，而不是“逃逸”。

第三种是标题党。很多新闻为了传播效果，把一个纯粹的本地沙箱初始化失败、或者某个工具版本更新时的调试信息，包装成“AI 逃出去了”。常见的热搜词里，像chatgpt is creating a sandbox needed to run on your computer、codex windows sandbox failed之类的报错，本质都是沙箱环境没建好，跟逃逸没有任何关系。

遇到这类信息，先问一句：它说的是哪一层沙箱？动作发生在什么阶段？有没有日志或错误码支撑？如果没有，最好先当错误信息处理，而不是当成安全事故。

2. 为什么“模型安全”和“执行环境安全”是两件事

2.1 模型只负责生成文本，逃出去的是带权限的工具调用

如果一个 AI Agent 只能回消息，那它再“聪明”，能造成的影响也很有限。它一旦能读文件、能调用 shell、能发送 HTTP 请求，事情就变了。

问题出现在模型输出被解释成“动作”的那一刻。

以 AI 编程工具为例。你向 Codex 或 Cursor 说“帮我检查一下项目里有没有硬编码的密钥”，Agent 会执行类似find . -type f的命令，然后读取匹配到的文件。这个过程由三部分组成：模型生成命令、工具层解析命令、操作系统执行命令。沙箱通常嵌套在第二和第三部分之间。

Model 的安全性高，不等于系统安全性高。模型可以说“我不会执行这个危险命令”，但如果工具层直接把模型生成的字符串拼进系统调用，那模型的行为边界就取决于底层执行的权限边界。很多真实事故里，问题并不在模型有多“坏”，而在于执行链路缺少一层独立的判断。

2.2 真正要防的不是“AI 觉醒”，而是输入污染

Agent 最容易被忽略的风险点是它的“输入”并不只有你敲进去的那句话。

一个典型的多步 Agent 流程大概是：先做网络搜索，再读几篇网页正文，然后把摘要交给写作模型，最后发布到某个平台。也可能是在代码库里检索一段代码，再执行一个重构脚本，最后自动提交。

问题在于：网络网页、代码文件、PDF 文本、环境变量、工具返回结果，这些内容都会进入模型上下文。只要其中一个来源包含恶意指令，就可能影响模型后续生成的动作。这就是所谓的提示注入（Prompt Injection）场景——不是模型“决定”逃跑，而是它被上下文里的隐藏指令引导到了执行层。

这种风险不能用“加强模型意识”来解决，只能在执行环境层做限制。模型可以把网页内容理解为“帮我调用一个外部 API”，但沙箱负责的是：这个调用是否在白名单里，目标地址是否允许访问，响应数据能不能写回本地。

很多聊天工具会做内容审核，拦掉某些敏感输出。这属于输出侧的软边界。执行环境沙箱则不同，它在动作发生之前就拦下来。两者是不同层的事，不能混为一谈。尤其是做 AI 应用开发时，如果只关注模型输出文案是否得体，而忽略工具调用是否受限，等于把门锁装在了栏杆上。

3. 一个 Agent 的沙箱，通常由哪四层一起组成

3.1 进程隔离层：容器、虚拟机、Windows 隔离进程

第一层是进程级隔离。AI 工具真正执行代码时，不会直接跑在你的主用户环境里，而是放进一个受限的进程、容器或虚拟机。

ChatGPT 桌面版会在本地创建一个沙箱环境，用来运行一些需要依赖本地路径的工具。它启动时经常显示“正在创建沙箱，可能需要一点时间”，实际上就是在准备这个隔离层。Codex CLI 在 Windows 上会尝试用受限令牌启动一个进程，如果失败，就会报createprocesswithlogonw failed: 2。这个错误的意思是：用CreateProcessWithLogonW这个 Windows API 去启动一个指定身份/受限会话的进程时，系统返回错误码 2，通常对应“找不到指定文件、路径或依赖模块”。

进程隔离层要解决的问题是：即使 Agent 内部真的发生了不可控行为，它也只能影响这个隔离环境，碰不到宿主系统。

3.2 文件系统与网络访问层：白名单才是真正的边界

容器隔离解决的是“进程能不能逃出去”，文件系统和网络白名单解决的是“进程能不能接触到敏感资源”。

常见做法是给 Agent 一个可见目录范围。比如只允许它读写/workspace/project，其他路径一律拒绝写入；允许访问指定的 API 域名，其余地址直接拦截。这个白名单可以做成一个显式配置，放在调用链路上。

下面是一个示例结构，不是某个产品的官方配置，只是为了表达白名单长什么样：

{ "allowed_tools": ["read_file", "search_code", "run_shell"], "allowed_paths": ["/workspace/project"], "allowed_networks": ["api.github.com"], "deny_write_paths": ["/etc", "/home/user/.ssh"] }

这里最关键的一点是：白名单越短，沙箱越有效。不要为了图方便直接放行整个用户目录或整个内网网段。很多越权问题的根源不是沙箱技术不够强，而是白名单一开始就太宽。

3.3 工具调用层：模型和工具之间最好加一道闸

工具层是模型输出的“翻译器”。模型说“我要读文件”，工具层负责把这句话变成一次真实的文件读取。

在这一层，不仅仅要限制“有哪些工具可以被调用”，还要考虑“哪些参数是合法的”。比如允许模型运行代码解释器，但不允许它使用eval或直接写/tmp之外的文件。比如允许模型发起 HTTP 请求，但要确保 URL 命中https://且不在私有网段。

高级一点的做法是让高风险操作必须经过人工确认。比如“执行 shell 命令”“提交代码”“发送外部请求”这类动作，不直接执行，先返回待确认指令，用户点确认后才真正运行。这会在体验上多一步，但对生产环境的 Agent 来说，这一步非常重要。

3.4 审计日志层：没有记录，就没有“逃逸”的判断依据

最后一层是审计。无论沙箱设计得多严密，如果工具调用没有日志，出问题时根本没法定位。

日志至少要记录：模型生成了什么工具调用、工具层实际执行了什么命令、访问了哪些路径、网络请求目标地址是什么、执行结果如何返回给模型。这些日志应该按任务 ID 串联起来，这样出现越权行为时，可以直接回放整个链路。

现实中有太多团队把精力花在“让 Agent 更聪明”上，却忽略“让 Agent 可追溯”。等到真出了问题，连基本证据都拿不出来。

注意：在部署任何 AI Agent 之前，先确认它的日志能回答三个问题：执行了什么动作、在哪个目录下执行的、访问了哪个目标地址。

4. 别把“装不上沙箱”当成“沙箱被攻破”

4.1 常见报错拆解

最近热搜里出现的几个沙箱相关报错，逐一拆开看都很具体，也都不属于“逃逸”范畴。

第一条是chatgpt is creating a sandbox needed to run on your computer. this can take.这通常是 ChatGPT 桌面版在首次启动或更新后初始化本地沙箱时出现的状态提示。卡在这里的原因，比较常见的是磁盘空间不足、杀毒软件拦截、用户配置文件权限异常，或者安装目录没有写权限。

第二条是codex windows sandbox failed: createprocesswithlogonw failed: 2。这个报错里有一个非常明确的 Windows API 名称。CreateProcessWithLogonW的意思是“使用指定用户的登录凭据创建一个新进程”。在 Codex 的沙箱场景里，通常是用一个受限账号或受限令牌去启动子进程。错误码 2 在 Windows 系统里一般对应ERROR_FILE_NOT_FOUND，也就是找不到要启动的程序或某个依赖文件。结合实践来看，优先排查安装路径是否完整、环境变量是否配置、杀毒软件是否有隔离记录。

第三条是windows elevated sandbox cannot reopen writable descendants。这句话涉及 Windows 沙箱的一个安全机制：高权限进程不能把“可写句柄”直接传给低权限沙箱进程。如果启动方式踩到了这个限制，就会报这个错。它属于 Windows 自身的安全设计，不是 AI 能力超限。

这三种报错有一个共同点：它们都发生在“沙箱还没有建立起来”的阶段，不是沙箱运行中被突破。换句话说，这更像施工队没开门，而不是门被撞坏了。

4.2 排查链路：输入、环境、权限、日志

遇到这些报错，我建议按下面的顺序排查，不要一上来就重装系统：

1. 先确认报错出现的阶段。是安装过程中，还是启动工具时，还是第一次执行代码时？
2. 检查输入。安装包是否完整，命令行参数是否正确，用户目录是否存在中文路径或过深目录。
3. 检查环境。磁盘空间、Windows 版本、杀毒软件是否拦截、是否缺少 VC++ 运行库。
4. 检查权限。当前用户是否为管理员、用户配置文件是否能写入、是否有组策略限制。
5. 查看日志。Windows 事件查看器、工具自身日志、安装日志，按错误码过滤。
6. 最后才是重装或升级。升级前记录好当前版本，避免新版本引入不兼容问题。

严格来讲，沙箱创建失败不是逃逸，但也不能完全无视。它说明执行环境不可用，如果用户为了绕过失败而选择“无沙箱模式”运行，那才是真正的风险开始。所以遇到这类问题，宁可多花时间修复，也不要轻易关掉沙箱。

5. 如果真出现越权行为，怎么判断是事故还是攻击

5.1 先用日志建立证据链

假设某天你发现 Agent 访问了一个本不该访问的路径，或者在没有任何指令的情况下调用了外部 API。这时先不要急着复盘，先确认几件事：

• 这个行为是否在白名单之外？
• 它是不是由某一步工具调用的结果链式触发的？
• 上下文里是否出现了不可信内容，比如网页正文、文件内容？
• 这个行为是偶发一次，还是反复出现？
• Agent 是否试图关闭审计、修改自身权限、读取凭证文件？

这些问题比“AI 是不是有意识了”重要得多。白名单外的单次行为，可能只是参数构造失误；反复出现且伴随凭证读取，才需要考虑是否真的存在可利用漏洞。

5.2 先隔离，再取证，最后复盘

一旦怀疑出现越权行为，处理顺序是固定的：先断，再看，再改。

第一步是隔离。停止 Agent 进程，撤销相关 API Token，必要时断掉调试会话。不要再“通过 Agent 自己查看日志”或者“让 Agent 解释原因”，因为问题出在执行边界上，模型对自身动作的解释不一定准确，而且继续交互还可能触发新的动作。

第二步是取证。整理工具调用日志、系统进程日志、文件访问审计、网络访问记录。重点找“第一步越界动作”发生在哪里，是谁触发的，执行时上下文里有什么内容。

第三步才是复盘。如果确认是权限配置太宽，就收紧白名单；如果是提示注入，就增加高危动作确认机制；如果是工具本身的漏洞，就去更新版本或者换实现方式。修好之后，再用同样的输入在最小权限环境里复现一次，确认问题消失。

注意：不要把“Agent 生成了危险指令”和“Agent 执行了危险指令”混为一谈。前者是模型输出问题，后者是执行层问题。一个负责任的 Agent 架构，应该让后者几乎不可能发生。

6. 让 AI 老实待在边界里：一套最小落地框架

6.1 一个白名单，两条限制，三道闸门

聊完问题，给一套可以直接落地的框架，我叫它“一二三”框架：

一个白名单：把 Agent 能访问的路径、网络、工具、接口全部显式列出来。没有在列表里的，默认拒绝。这里的核心不是“我觉得它可能不需要”，而是“凡是没写的就是不能用”。

两条限制：最小权限和最小影响。Agent 运行账号不要用管理员，容器里不要挂载宿主机的敏感目录，文件系统尽量只读。AI 编程工具不要直接使用你的主 Git 账号，而是用单独的凭证，限制它能推送的仓库范围。

三道闸门：高风险操作需要人工确认；单次任务设置有超时和最大动作次数；整个执行流程有配额控制，比如按credits或 token 预算限制调用量。很多 AI 应用里，credits 是使用量单位，也是天然的熔断器。当预算耗尽，流程自动停止，这样即使出现失控循环，损失也在可控范围内。

6.2 先能跑通，再缩权限，最后看日志

落地时不要一上来就追求权限最小化。正确顺序是：

1. 先在一个独立环境里跑通整个 Agent 流程，确认它能完成目标。
2. 记录这次运行实际访问了哪些路径和网络，把它作为初始白名单。
3. 再逐步收缩：删除没有用到的路径，把可写权限改成只读，给网络请求加域名白名单。
4. 最后开启完整审计日志，持续运行观察一段时间，定期回放。

这个过程不是一步到位的。AI Agent 的需求会变化，白名单也需要跟着更新。每次更新权限时，都应该回到日志里确认新增项是否真的被用到。

这套框架适合本地 AI 编程工具、自建 Agent 服务、Spring AI 这类框架搭出来的应用。它不太适合纯聊天的 API 场景，因为那里根本不执行工具；但只要是涉及工具调用的 AI 应用开发，都可以按照这个思路来设计边界。

下次再看到“AI 逃出沙箱”这类标题，可以先不慌，问三个问题：沙箱关住的是哪些动作？越权行为发生在哪一层？日志里有没有完整证据链？把问题从“AI 有没有意识”翻译回“权限边界有没有被绕过”，你会发现自己能做的事情其实非常具体。工程上真正需要管的，从来都不是 AI 的未来，而是它今天被赋予的权限。