在 macOS（利用 Seatbelt）和 Linux（利用 seccomp/bubblewrap）上，操作系统提供了成熟的进程隔离机制。然而，在缺乏原生、开箱即用沙盒工具的 Windows 平台上，如何构建一个既能保障系统安全，又能兼顾复杂开发流（如运行 Python、包管理器等）的轻量级沙盒？

OpenAI 团队通过一系列底层技术的深度组合，给出了他们的答案。

一、 传统 Windows 隔离方案的破产

在设计之初，团队评估了 Windows 现有的几种原生隔离技术，但它们在“AI 智能体”这一特殊场景下均宣告失效：

1. AppContainer（应用容器）：这是 Windows 现代应用的标准沙盒，基于能力（Capability）进行硬隔离。但它要求应用在运行前明确声明所需权限。AI 智能体的工作流是完全开放且不可预测的，AppContainer 过于死板，无法承载任意的开发工具链。

2. Windows Sandbox（Windows 沙盒虚拟机）：基于 Hyper-V 的轻量级虚拟机，隔离性最强。然而，它是一个完全空白的临时系统，无法直接、低延迟地访问开发者当前的本地工作区，且在 Windows 家庭版（Home SKU）上不可用，严重影响用户体验。

3. MIC（强制完整性控制）标签：通过将沙盒进程标记为“低完整性（Low Integrity）”，阻止其写入正常文件。但这种方式必须修改宿主机的文件系统 ACL（访问控制列表）。将开发工作区标为低完整性，意味着系统中所有低完整性的恶意软件都能写入该目录，反而污染了主机的安全模型。

二、 第一阶段探索：非提权的“ advisory ”沙盒

为了避免频繁弹出管理员权限（UAC）提示，团队最初设计了一种无需提权的沙盒原型。该方案的核心逻辑是：利用 Windows 令牌机制精确控制文件写入，并对网络进行“弱降级”。

1. 基于安全标识符（SIDs）与受限令牌的文件控制

在 Windows 权限体系中，进程的访问权限由其“进程令牌（Process Token）”决定。团队利用这一特性实现了颗粒度极细的文件管控：

• 合成 SID（Synthetic SID）：沙盒初始化时，会创建一个专属的虚拟身份标识 sandbox-write。

• 显式 ACL 赋权：通过修改文件系统权限，仅允许 sandbox-write 这个 SID 拥有当前项目工作目录（Workspace）的读写权限，而显式拒绝其写入 .git、.codex 等敏感配置目录。

• 受限写入令牌（Write-Restricted Tokens）：当 Codex 启动子进程时，会为其注入一个特殊的限制性令牌。在 Windows 底层，当该进程尝试写入文件时，必须通过双重检查：

    通过这种数学交集式的权限校验，子进程被牢牢限制在指定的临时可写目录中，无法越雷池一步。

2. 网络隔离的致命弱点

由于没有管理员权限，沙盒无法调用系统防火墙，只能采用“环境变量环境污染”的黑客式手法：注入死代理（如 HTTPS_PROXY=http://127.0.0.1:9）、污染 PATH 路径以拦截 SSH/SCP 命令。

安全漏洞： 这种防御是“劝告式（Advisory）”的。任何恶意的代码或不依赖系统环境变量、直接通过底层 Socket 套接字建立连接的程序，都可以轻松绕过该限制，将本地敏感数据外泄。对于 AI 安全而言，这是不可接受的。

三、 终极方案：基于管理员提权的“双层”沙盒架构

为了实现不可绕过的网络硬隔离，OpenAI 最终放弃了“免提权”的设想，转向了必须在安装时进行一次性管理员授权的终极方案（Elevated Sandbox）。

其核心思想是：彻底剥离当前“真实用户”的执行身份，引入独立的系统本地用户作为隔离实体。

[普通权限] codex.exe (真实用户身份)      │      ▼ (通过 CreateProcessWithLogonW 跨越用户边界)[沙盒用户] codex-command-runner.exe (作为专属沙盒用户运行)      │      ▼ (在内部调用 CreateRestrictedToken + CreateProcessAsUserW)[受限子进程] 最终的用户命令 (受限令牌控制文件 + 防火墙控制网络)

1. 独立身份与原生防火墙拦截

在提权设置阶段（由 codex-windows-sandbox-setup.exe 执行），系统会创建两个全新的本地 Windows 用户：CodexSandboxOffline（离线流）和 CodexSandboxOnline（连网流），并使用 DPAPI（数据保护 API）加密存储凭据。

接着，利用管理员权限在 Windows 防火墙 中写入硬性规则：彻底封锁 CodexSandboxOffline 账号的所有出站网络流量。 由于防火墙是在操作系统内核级别基于用户 SID 进行拦截的，无论上层代码如何变异、如何绕过环境变量，其网络连接都会被操作系统直接掐断。

2. 异步只读 ACL 注入

由于新创建的沙盒用户默认无法读取真实用户的目录，沙盒系统会异步地为这两个沙盒用户赋予对系统关键目录（如 C:Users<real-user>、Program Files）的只读 ACL 权限。采用异步执行是为了防止庞大的文件树扫描阻塞用户的正常初始化流。

3. 跨越权限墙：双层进程启动机制（Command Runner）

在实际运行时，团队遇到了 Windows 底层的权限墙：以普通真实用户身份运行的 codex.exe，由于不具备 SeAssignPrimaryTokenPrivilege 权限，无法直接代表另一个用户创建受限进程。

为了解决这一难题，团队引入了中间体 codex-command-runner.exe，构建了优雅的双层启动链：

• 步骤一（跨越用户边界）：codex.exe 运行于普通权限，通过调用 CreateProcessWithLogonW(...)，以沙盒用户（如 CodexSandboxOffline）的身份启动 codex-command-runner.exe。此时，该进程已经处于防火墙的断网保护中。

• 步骤二（提炼受限令牌）：进入命令运行器内部后，Runner 打开自己的进程令牌，通过 CreateRestrictedToken(...) 将其进一步削减为带有 sandbox-write 限制性 SIDs 的受限令牌。

• 步骤三（终极降权执行）：由于 Runner 自身已经属于沙盒用户，它可以安全地调用 CreateProcessAsUserW(...)，用刚刚切削好的受限令牌启动最终的第三方代码（如 Python 脚本）。

至此，最终执行的代码同时披上了两道枷锁：网络上被 Windows 防火墙基于用户标识无死角拦截，文件系统上被受限令牌牢牢锁死在工作区内。

四、 结语与 AI 安全启示

OpenAI 在 Windows 端的沙盒演进表明：传统的应用安全边界（如单体 App 的隔离）无法直接套用到行为不可预测的自主 AI 智能体上。 由于 Windows 缺乏统一的沙盒原语，团队通过将合成 SIDs、受限令牌、独立本地用户、系统级防火墙以及定制的双层启动器（Command Runner）像积木一样组合在一起，在不诉诸重型虚拟机的情况下，成功在 Windows 宿主机上缝合出了一个高安全性的执行边界。这种“组合拳”的设计思路，为未来所有需要在本地落地的 AI Agent 平台提供了一个极具参考价值的安全架构范本。

参考资料

https://openai.com/index/building-codex-windows-sandbox/

关注「极客零零七」，每周实战攻防干货。回复「提权」获取 Windows + Linux 提权速查表 · 回复「AD 攻击」获取 AD 域攻击手册

推荐阅读

一个 2375 端口，30 秒拿下整台宿主机——Docker 渗透实战全流程

告别只会搜索的聊天机器人：如何用 754 个专业 Playbook，把 AI 变成你的高级安全分析师？

深度｜漏洞管理的 9 次失效——从 CVE 到 KEV，27 年我们一直在追，但永远没追上

AI 自动挖洞 Benchmark：漏洞研究员真的要失业了吗？

GRE 隧道：在公网上凿一条"私家地道"，工程师必须吃透的 7 个核心要点

【技术深潜】潘多拉的魔盒：拆解Anthropic Project Glasswing

从网线到域控：一次完整AD渗透的全流程复盘

【干货收藏】大模型时代的安全护城河：2026 顶级 AI 安全学习与认证指南