OpenAI 安全部署 Codex：编码代理的治理与控制策略

引言

随着 AI 系统能力不断增强，它们越来越多地代表用户执行任务。编码代理（Coding Agents）能够自主审查代码仓库、运行命令并与开发工具交互——这些工作以往需要人工直接执行。针对 Codex，OpenAI 在设计这些能力的同时，也构建了组织安全部署所需的控制机制。安全团队需要明确代理如何运作：它们可以访问什么、何时需要人工批准、能与哪些系统交互，以及有哪些遥测数据可以解释其行为。

在 OpenAI，我们部署 Codex 时遵循几个清晰的目标：将代理限制在明确的技术边界内，让开发者能在低风险操作上快速推进，同时让高风险操作变得显式可控。我们还保留了代理原生遥测，以便理解和审计代理的行为。在实践中，这意味着托管配置、受限执行、网络策略和代理原生日志。

控制 Codex 如何运作

我们部署 Codex 遵循一个简单原则：它应在受限环境内高效工作，日常低风险操作应无摩擦，而高风险操作则应停下来接受审查。

沙箱与审批

审批与沙箱协同工作。沙箱定义了技术执行边界，包括 Codex 可以写入哪些位置、能否访问网络、哪些路径受到保护。审批策略则决定 Codex 何时必须请求执行某个操作，例如当它需要执行沙箱外的操作时。用户可以选择一次性批准该操作，或在该会话中批准该类型的所有操作。

对于跨越沙箱边界的请求，我们使用了自动审查模式。启用后，该功能会自动批准某些类型的请求，从而减少用户频繁中断并批准 Codex 操作的次数。Codex 会将计划操作及近期上下文发送给自动审批子代理，该子代理可以自动批准低风险操作——或在用户授权充分的情况下批准高风险操作——而无需打扰用户。这样，Codex 可以在例行工作中保持流畅，同时在高风险或可能产生意外后果的操作上停下来。

网络访问

我们不会为 Codex 开放无限制的出站访问。托管网络策略允许访问预期目标，阻止不希望 Codex 访问的域名，并要求对不熟悉的域名进行审批。这使得 Codex 能够完成常见且已知良好的工作流程，同时不赋予其广泛的网络访问权限。

身份与凭证

我们还管理 Codex 的认证方式。CLI 和 MCP OAuth 凭证存储在安全的操作系统密钥链中，登录强制通过 ChatGPT，访问权限绑定到我们的 ChatGPT 企业工作区。这确保了 Codex 的使用与企业工作区级别的控制策略保持一致，并使 Codex 活动可在 ChatGPT 合规日志平台中供企业工作区查看。

规则

我们使用规则来确保 Codex 不会将所有 shell 命令视为同等安全。工程师日常开发中常用的良性命令可以在沙箱外无需审批直接执行，而特定的危险命令可以被阻止或要求审批。这使得 Codex 能够快速完成常规工程任务，同时强制审查或阻止我们不希望在沙箱外运行的模式。

托管配置

我们通过云端托管要求、macOS 托管偏好设置和本地要求文件的组合来应用这一安全策略。要求是管理员强制执行的控件，用户无法覆盖。macOS 托管偏好设置和本地要求文件使我们能够保持一致的基线，同时根据团队、用户组或环境测试不同的配置。这些配置适用于本地 Codex 界面，包括桌面应用、CLI 和 IDE 扩展。

代理原生遥测与审计追踪

控制只是工作的一半。一旦代理部署完成，安全团队需要了解这些代理在做什么以及为什么这样做。传统的安全日志在查看 Codex 执行的操作时仍然有用，但它们主要回答“发生了什么”：进程启动、文件更改、网络连接尝试。安全人员仍需推断 Codex 为什么这样做，或者用户的意图是什么。

Codex 可以为安全团队提供更具备代理意识的视图。Codex 支持 OpenTelemetry 日志导出，用于记录各种 Codex 事件，例如用户提示、工具审批决策等。这使得安全团队能够理解代理的行为和用户的意图，从而更好地进行审计和事件响应。

总结

OpenAI 在部署 Codex 时，通过沙箱、审批、网络策略、身份管理、规则和托管配置等多层控制，确保了编码代理的安全运行。同时，代理原生遥测提供了审计和理解的透明度，帮助组织在享受 AI 带来的效率提升的同时，保持对安全风险的掌控。