在 OpenAI 安全运行 Codex

随着 AI 系统能力增强，它们越来越多地代表用户执行操作。Coding agent 可以自主审查 repositories、运行 commands，并与开发工具交互。这些任务过去都需要人类直接执行。

在 Codex 中，我们在设计这些能力的同时，也设计了组织安全部署所需的控制机制。安全团队需要治理 agent 运行方式的方法：它们可以访问什么、何时需要人工 approval、可以与哪些系统交互，以及有哪些 telemetry 可用于解释其行为。

在 OpenAI，我们部署 Codex 时有几个明确目标：让 agent 始终处在清晰的技术边界内，让开发者能快速完成低风险操作，并使更高风险的操作显式化。我们还保留 agent-native telemetry，以便理解和审计 agent 做了什么。实际做法包括 managed configuration、受限执行、network policies，以及 agent-native logs。

控制 Codex 的运行方式

我们部署 Codex 时遵循一个简单原则：它应当在有边界的环境中保持生产力，低风险的日常操作应当无阻力，而更高风险的操作应当停下来等待 review。

Approvals 和 sandboxing 协同工作。sandbox 定义技术执行边界，包括 Codex 可以在哪里写入、是否可以访问 network，以及哪些 paths 仍受保护。Approval policy 决定 Codex 何时必须请求执行某个操作，例如当它需要在 sandbox 之外做某件事时。用户可以只 approve 一次该操作，也可以 approve 该 session 中同类型的操作。

对于常规 approval 请求，我们正在使用 Auto-review mode。开启后，该功能会自动 approve 某些类型的请求，以减少用户停下来 approve Codex 操作的频率。Codex 会将计划执行的操作和近期上下文发送给 auto-approval subagent，后者可以自动 approve 低风险操作，而不是打断用户。这让 Codex 能持续推进常规工作，同时仍会在更高风险或可能产生非预期后果的操作上停下来。

我们不会让 Codex 拥有开放式的 outbound access。我们的 managed network policy 允许预期的 destinations，阻止我们不希望 Codex 访问的 destinations，并要求对陌生 domains 进行 approval。这样，Codex 可以完成常见且已知安全的 workflows，而无需获得宽泛的 network access。

我们还管理 Codex 的认证方式。CLI 和 MCP OAuth credentials 存储在安全的 OS keyring 中，login 强制通过 ChatGPT 完成，并且 access 绑定到我们的 ChatGPT enterprise workspace。这使 Codex 使用与我们的 workspace-level controls 绑定，并让 Codex activity 可在我们 enterprise workspace 的 ChatGPT Compliance Logs Platform 中查看。

我们使用 rules，避免 Codex 将每个 shell command 都视为同等安全。工程师在日常开发中使用的常见良性 commands 可以在 sandbox 之外无需 approval 即可运行，而特定危险 commands 可以被 blocked 或要求 approval。这样，Codex 能快速完成普通工程任务，同时仍强制 review 或阻止我们不希望在 sandbox 之外运行的 patterns。

我们通过 cloud-managed requirements、macOS managed preferences 和 local requirements files 的组合来实施这一姿态。Requirements 是由 admin 强制执行、用户无法 override 的 controls。macOS managed preferences 和 local requirements files 让我们能够保持一致的 baseline，同时仍可按 team、user group 或 environment 测试不同 configurations。这些 configurations 适用于本地 Codex surfaces，包括 desktop app、CLI 和 IDE extension。

Agent-native telemetry 和 audit trails

控制只是工作的一半。agent 部署后，安全团队需要了解这些 agent 正在做什么以及为什么这么做。查看 Codex 执行的 actions 时，传统 security logs 仍然有用，但它们主要回答发生了什么：某个 process 启动了、某个 file 变更了、某个 network connection 被尝试建立。防御人员仍需要弄清楚 Codex 为什么这样做，或者用户的意图是什么。

Codex 可以为安全团队提供更具 agent-aware 的视角。Codex 支持通过 OpenTelemetry 导出各种 Codex events 的 logs，例如 user prompts、tool approval decisions、tool execution results、MCP server usage，以及 network proxy allow 或 deny events。对于 Enterprise 和 Edu 客户，Codex activity logs 也可通过 OpenAI Compliance Platform 获取。

在 OpenAI，我们将 Codex logs 与我们的 AI-powered security triage agent 结合使用。当 endpoint alert 表明 Codex 做了异常操作时，endpoint security tool 会告诉我们发生了 suspicious event。随后，Codex logs 帮助解释用户和 agent 周围的 intent。我们的 AI security triage agent 使用 Codex logs 来检查原始 request、tool activity、approval decisions、tool results，以及任何相关的 network policy decision 或 block。AI security triage agent 会将其分析呈现给安全团队 review，以区分预期的 agent behavior、良性错误，以及确实需要 escalation 的 activity。

我们也在运营层面使用同样的 telemetry。我们使用这些 logs 了解内部 adoption 如何变化、哪些 tools 和 MCP servers 正在被使用、network sandbox 阻止或提示的频率，以及 rollout 仍需调优的地方。这些 OpenTelemetry logs 可以集中到 SIEM 和 compliance logging systems 中。

展望

随着 Codex 这类 coding agent 集成到开发 workflows 中，安全团队需要专门为管理这一转变而设计的工具。Codex 提供了 control surfaces、configuration management、sandboxing，以及安全采用所需的详细 agent-aware telemetry。具备这些能力后，安全团队可以更有信心地启用 Codex，在 developer productivity 与 enterprise security 所需的 visibility 和 control 之间取得平衡。有关配置 Codex 的更多信息可见此处⁠（在新窗口中打开），Compliance API 可见此处⁠（在新窗口中打开）。