OpenAI 详解 Codex 安全部署边界

OpenAI 在官方文章中披露 Codex 安全部署的控制体系，重点包括沙箱、审批、网络策略、身份绑定、规则管理与 agent-native telemetry。OpenAI 的目标是让 Codex 在低风险开发任务中保持效率，同时让高风险动作进入显式审批。对企业安全团队而言，这提供了一套可复用的 coding agent 治理样板。

Codex 安全部署依赖沙箱与审批

核心边界是沙箱加审批。OpenAI 表示，Codex 的沙箱定义技术执行范围，包括可写路径、网络可达性与受保护目录。审批策略决定 Codex 何时必须请求用户确认，例如尝试执行沙箱外动作时。用户可以只批准单次动作，也可以在当前会话中批准同类动作。OpenAI 还使用 Auto-review mode，让自动审批子 agent 查看计划动作与近期上下文，并自动放行低风险请求。这个设计反映了一个工程取舍：日常开发命令不应频繁打断开发者，但越界动作必须留下人工确认点。

网络策略限制 Codex 的外联范围

网络访问默认不放开。OpenAI 不让 Codex 拥有开放式出站访问，而是使用托管网络策略控制可访问目标。已知的正常目的地会被允许，不希望 Codex 触达的域名会被阻断，陌生域名需要审批。原文示例中，web fetch 被限制为 OpenAI cache，网络代理可允许 localhost 绑定，并可阻断 pastebin.com，同时自动允许 login.microsoftonline.com 与 *.openai.com。这类策略的价值在于把 coding agent 的外部交互显性化，降低凭据外传、代码粘贴站泄露与供应链风险。

身份与规则把 Codex 绑定到企业控制面

身份绑定到企业工作区。OpenAI 将 CLI 与 MCP OAuth 凭据存入安全的操作系统 keyring，并强制通过 ChatGPT 登录。Codex 访问还会固定到指定 ChatGPT enterprise workspace。这样做可以把 Codex 使用纳入工作区级别控制，并让相关活动进入 ChatGPT Compliance Logs Platform。OpenAI 还使用规则区分命令风险，而不是把所有 shell 命令视为同一等级。示例规则允许 gh pr view、gh pr list 这类只读 GitHub PR 检查，也允许 kubectl get、kubectl describe 与 kubectl logs 这类 Kubernetes 调试读取命令。危险命令则可以被阻断或要求审批。

OpenTelemetry 日志补足 agent 审计链路

遥测解释了 Codex 为什么行动。OpenAI 指出，传统安全日志能说明进程启动、文件变化或网络连接尝试，却很难解释 Codex 的上下文与意图。Codex 支持通过 OpenTelemetry 导出多类日志事件，包括用户 prompt、工具审批决策、工具执行结果、MCP server 使用情况，以及网络代理允许或拒绝事件。Enterprise 与 Edu 客户还可通过 OpenAI Compliance Platform 获取 Codex 活动日志。OpenAI 内部会把 Codex 日志与 AI-powered security triage agent 结合使用：端点告警先指出异常事件，Codex 日志再帮助安全团队查看原始请求、工具活动、审批结果与网络策略命中情况。OpenAI 在Codex 安全部署官方文章中称，这些 OpenTelemetry 日志也可集中到 SIEM 与合规日志系统。

托管配置让 Codex 在多入口保持一致

配置需要管理员强制执行。OpenAI 通过 cloud-managed requirements、macOS managed preferences 与本地 requirements 文件组合落地策略。requirements 属于管理员强制控制，用户不能覆盖。macOS 托管偏好与本地 requirements 文件则用于保持统一基线，同时按团队、用户组或环境测试不同配置。这些配置覆盖本地 Codex 入口，包括 desktop app、CLI 与 IDE extension。对大型工程组织来说，重要点不是单个开关，而是让同一套边界在多入口上保持一致。 Codex 安全部署的核心结论是，coding agent 不能只靠模型能力上线。它还需要沙箱、审批、身份、网络策略、命令规则与 agent 原生日志共同组成控制面。这个案例说明，企业采用 coding agent 的关键竞争点正在从能否生成代码，转向能否解释、限制并审计 agent 在真实工作流中的每一次行动。