# 在OpenAI安全运行Codex - 来源：OpenAI：官网动态（RSS · 排除企业/客户案例） - 发布时间：2026-05-08 20:30 - AIHOT 分数：63 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmoxbojzc00g1sllhzpt6155s - 原文链接：https://openai.com/index/running-codex-safely ## 精选理由 OpenAI 公开了内部安全运行 Codex 的完整流程，从沙箱隔离到审批策略，企业落地 AI 编码的可以直接拿去抄作业。 ## AI 摘要 OpenAI通过沙盒隔离、人工审批流程、严格网络策略与原生代理遥测四层防护机制，确保Codex代码生成模型的安全运行。沙盒环境完全隔离执行代码，所有生产请求需经人工审核批准，网络策略限制外部依赖访问，实时遥测系统监控代理行为异常。该安全框架使企业能够合规采用AI编程助手，在保障代码安全性的同时维持开发效率。 ## 正文 本文探讨了 OpenAI 用于在实际工作流程中管控编码智能体的控制机制、边界设定与遥测手段。 随着 AI 系统能力日益增强，它们越来越多地代表用户执行操作。编码智能体可以自主审查代码仓库、运行命令并与开发工具交互。这些任务以往都需要人类直接执行。 通过 Codex，我们在设计这些能力的同时，也配备了组织安全部署所需的控制机制。安全团队需要能够管控智能体的运作方式：它们可以访问什么、何时需要人工审批、可以与哪些系统交互，以及存在哪些遥测数据来解释其行为。 在 OpenAI，我们部署 Codex 时遵循几个明确目标：将智能体限制在清晰的技术边界内，让开发者能够快速执行低风险操作，并使高风险操作变得明确可控。同时，我们保留智能体原生的遥测能力，以便理解和审计智能体的行为。在实践中，这体现为托管配置、受限执行、网络策略以及智能体原生日志。 控制 Codex 的运作方式 我们部署 Codex 遵循一个简单原则：它应在受限环境中高效工作，低风险的日常操作应无摩擦执行，而高风险操作则需暂停等待审查。 沙箱与审批机制 审批与沙箱机制协同运作。沙箱定义了技术执行边界，包括 Codex 可以写入的位置、能否访问网络，以及哪些路径受到保护。审批策略则决定了 Codex 在何时必须请求许可才能执行操作，例如当它需要执行沙箱外的操作时。用户可以一次性批准该操作，或批准该会话中同类型的操作。 对于跨越沙箱边界的请求，我们使用自动审核模式。该功能启用后，会自动批准某些类型的请求，从而减少用户需要停下来批准 Codex 操作的频率。Codex 会将计划执行的操作和近期上下文发送给自动批准子智能体，该子智能体可以自动批准低风险操作——或者在用户授权充分的情况下批准高风险操作——而无需中断用户。这使得 Codex 能够在常规工作上持续推进，同时仍会在高风险或可能产生意外后果的操作上停下来。 TOML 1# config.toml23# 开启自动审核4approvals_reviewer = "auto_review" 5# 自动将已知的开发目录添加到沙箱中6sandbox_workspace_write.writable_roots = ["~/development"] 78# requirements.toml910# 要求 Codex 在沙箱内运行11allowed_sandbox_modes = ["read-only", "workspace-write"] 网络访问 我们不会让 Codex 拥有不受限制的出站访问权限。我们的托管网络策略允许访问预期目标，阻止不希望 Codex 访问的目标，并要求对不熟悉的域名进行审批。这使得 Codex 能够完成常见的、已知良好的工作流程，而无需赋予其广泛的网络访问权限。 TOML 1# requirements.toml23# 确保网络抓取仅来自 OpenAI 的缓存4allowed_web_search_modes = ["cached"] 56[experimental_network]7# 开启网络代理8enabled = true9# 允许 Codex 与本地主机交互10allow_local_binding = true 11# 阻止对该域名的所有请求12denied_domains = ["pastebin.com"] 13# 自动允许对这些域名的请求14allowed_domains = ["login.microsoftonline.com", "*.openai.com"] 身份与凭证 我们还管理 Codex 的认证方式。CLI 和 MCP OAuth 凭证存储在安全的操作系统密钥环中，登录必须通过 ChatGPT 进行，并且访问权限固定在我们的 ChatGPT 企业工作区。这使得 Codex 的使用与我们的工作区级控制绑定，并使 Codex 活动可在我们企业工作区的 ChatGPT 合规日志平台中查看。 TOML 1# config.toml 2# 将 CLI 认证凭据存储在操作系统密钥链中 3cli_auth_credentials_store = "keyring" 4# 将 MCP 凭据存储在操作系统密钥链中 5mcp_oauth_credentials_store = "keyring" 6# 要求通过 ChatGPT 进行认证 7forced_login_method = "chatgpt" 8# 要求认证到特定的 ChatGPT 工作区 9forced_chatgpt_workspace_id = "" 规则 我们使用规则，这样 Codex 就不会将所有 shell 命令都视为同样安全。工程师在日常开发中使用的常见良性命令，在沙箱之外无需批准即可执行，而特定的危险命令可以被阻止或需要批准。这使得 Codex 能够快速处理常规工程任务，同时仍然强制审查或阻止我们不想在沙箱外运行的模式。 Starlark 1# default.rules 2prefix_rule( 3 pattern = ["gh", "pr", ["view", "list"]], 4 decision = "allow", 5 justification = "允许通过 gh CLI 进行只读的 GitHub PR 检查。", 6) 7prefix_rule( 8 pattern = ["kubectl", ["get", "describe", "logs"]], 9 decision = "allow", 10 justification = "允许对 Kubernetes 资源进行调试性检查。", 11) 托管配置 我们通过云托管要求、macOS 托管偏好设置和本地要求文件的组合来应用这种策略。要求是管理员强制实施的控制措施，用户无法覆盖。macOS 托管偏好设置和本地要求文件使我们能够保持一致的基线，同时仍可根据团队、用户组或环境测试不同的配置。这些配置适用于本地 Codex 界面，包括桌面应用、CLI 和 IDE 扩展。 智能体原生遥测与审计追踪 控制只是工作的一半。一旦部署了智能体，安全团队需要了解这些智能体在做什么以及为什么这么做。在查看 Codex 执行的操作时，传统的安全日志仍然有用，但它们主要回答发生了什么：一个进程启动了，一个文件被更改了，一次网络连接被尝试了。防御者仍然需要弄清楚 Codex 为什么做了某事，或者用户的意图是什么。 Codex 能够为安全团队提供更具智能体感知能力的视角。Codex 支持针对各类 Codex 事件（例如用户提示词、工具审批决策、工具执行结果、MCP 服务器使用情况以及网络代理允许或拒绝事件）导出 OpenTelemetry 日志。此外，企业和教育版客户还可通过 OpenAI 合规平台获取 Codex 活动日志。 TOML 1# config.toml23[otel]4log_user_prompt = true5environment = "prod"67[otel.exporter.otlp-http]8endpoint = "http://localhost:14318/v1/logs"9protocol = "binary" 在 OpenAI，我们将 Codex 日志与我们基于 AI 的安全分类智能体结合使用。当某个端点告警提示 Codex 出现了异常行为时，端点安全工具会通知我们发生了可疑事件。随后，Codex 日志有助于解释用户和智能体背后的意图。我们的 AI 安全分类智能体利用 Codex 日志来检查原始请求、工具活动、审批决策、工具结果以及任何相关的网络策略决策或拦截。该 AI 安全分类智能体将其分析结果呈现给我们的安全团队进行审查，以区分预期的智能体行为、良性错误以及确实需要升级处理的活动。 我们在运营层面也使用了相同的遥测技术。我们利用这些日志来了解内部采用率的变化情况、哪些工具和 MCP 服务器正在被使用、网络沙箱触发拦截或提示的频率，以及部署过程中哪些环节仍需调整。这些 OpenTelemetry 日志可以集中到 SIEM 和合规日志记录系统中。 展望未来 随着像 Codex 这样的编码智能体逐渐融入开发工作流程，安全团队需要专门为此类转变而设计的工具。Codex 提供了确保安全采用所需的控制面板、配置管理、沙箱机制以及详细的智能体感知遥测能力。有了这些能力，安全团队可以更有信心地启用 Codex，在开发者生产力与企业安全所需的可见性和控制力之间取得平衡。有关配置 Codex 的更多信息，请点击此处⁠，合规 API 的更多信息请点击此处⁠。 2026 Codex