📌 One-Sentence Summary

本文详细介绍了在 Windows 上为 Codex 构建自定义沙箱的工程历程，从最初使用 SID 和写入受限令牌的非提权原型，到最终采用专用 Windows 用户和防火墙规则实现强大网络隔离的提权设计方案。

📝 Summary

这篇来自 OpenAI 的工程博客文章描述了为其编程智能体 Codex 在 Windows 操作系统上实现安全有效沙箱的过程。作者指出，Windows 缺乏现成的、适合开放式智能体工作负载的隔离原语，因此他们评估并拒绝了 AppContainer、Windows Sandbox 和强制完整性控制等方案。第一个原型是“非提权沙箱”，它使用合成 SID 和写入受限令牌来控制文件写入，并通过环境变量限制网络访问。虽然功能可用，但其网络抑制仅是建议性的，很容易被绕过。为了实现强大的网络隔离，团队重新设计了沙箱，要求增加一个提权设置步骤。最终的“提权沙箱”创建了专用的 Windows 用户（CodexSandboxOffline/Online），并对其应用 Windows 防火墙规则，同时使用专用的命令运行器二进制文件来生成受限进程。这篇文章强调了安全性与可用性之间的权衡，以及组合多个 Windows 原语为编程智能体构建连贯解决方案的必要性。

💡 Main Points

1. Windows 缺乏一个单一的、适合 Codex 这类开放式智能体工作负载的隔离原语。 AppContainer 等现有工具对任意开发者工作流限制过严，Windows Sandbox 是一个与用户环境隔离的独立虚拟机，而 MIC 标签则会对主机文件系统造成广泛且有风险的语义更改。
2. 第一个“非提权”原型使用 SID 和写入受限令牌进行文件控制，但其网络抑制功能薄弱，仅具有建议性。 该设计在 ACL 中使用合成 SID 和写入受限令牌来精确定义可写入目录。网络访问通过环境变量（如 HTTPS_PROXY）进行限制，但那些不遵守这些变量或使用原始套接字的进程可以轻易忽略这些限制。
3. 最终的“提权”设计通过创建专用 Windows 用户并对其应用防火墙规则，实现了强大的网络隔离。 通过放宽“不提升权限”的限制，团队创建了 CodexSandboxOffline 和 CodexSandboxOnline 用户。Windows 防火墙规则阻止离线用户的所有出站流量，提供了非提权方法无法实现的强大安全边界。
4. 最终系统的复杂性是合理的，因为必须在安全性与编程智能体的可用性需求之间取得平衡。 最终架构包含多个二进制文件（设置程序、命令运行器）、自定义用户、防火墙规则和异步 ACL 应用。添加的每一处复杂性都是为了解决特定问题，同时不损害智能体在真实开发者工作流中有效工作的能力。

💬 Key Quotes

• Codex 不是一个范围严格限定的应用。它驱动着开放的开发者工作流：Shell、Git、Python、包管理器、构建工具，以及智能体决定需要的任何其他二进制文件。
• Windows 并没有直接给我们一个能完美对应“安全的自主编程智能体”的原语。我们组合了多种工具和概念来构建一个连贯的解决方案。
• 这并非一个特别简单的系统，但每一处增加的复杂性都是出于必要，目的是构建一个既安全又尽可能不干扰用户的沙箱。
• 另一个教训是，编程智能体的安全性与更经典的应用安全性是截然不同的挑战。

📊 Article Meta

Read Full Article