OpenAI通过沙盒与审计实现Codex安全部署

背景
随着大型语言模型在软件开发中的应用日趋成熟,Codex 作为 OpenAI 的代码生成代理,已经能够在 IDE、CLI 甚至完整的 CI/CD 流程中自主执行命令。为了让企业安全团队能够在不牺牲开发效率的前提下管控此类高危操作,OpenAI 在内部推出了一套围绕 沙盒、审批、网络访问和遥测 的完整安全框架。
关键控制措施
- 沙盒执行环境:通过
sandbox_workspace_write.writable_roots限定 Codex 可写入的目录,仅允许~/development等受信路径。 - 分层审批:在沙盒之外的操作触发审批子代理,低风险动作可通过 Auto‑review 自动批准,减少人工干预。
- 网络访问策略:默认禁用任意外部访问,仅允许
login.microsoftonline.com、*.openai.com等白名单域名;对未知域名强制审批。 - 身份凭证管理:所有 CLI 与 MCP OAuth 凭证存放于系统钥匙串,强制通过 ChatGPT 登录并绑定企业工作空间,确保操作可追溯。
- 规则引擎:基于前缀规则区分安全与高危命令,例如
gh pr view、kubectl get被标记为 allow,而潜在破坏性命令则需要人工审查。
沙盒与审批的协同工作
沙盒定义了 Codex 能够读写的文件系统边界和网络可达性。若任务超出这些边界,系统会将计划动作和最近上下文发送给 auto_review 子代理。该子代理依据预设的风险模型自动批准低风险请求,否则返回给用户进行手动批准。这样,日常的代码格式化、依赖安装等常规任务无需频繁弹窗,而关键的生产环境部署或密钥写入仍保持严格把关。
网络策略细节
[experimental_network]
enabled = true
allow_local_binding = true
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]
denied_domains = ["pastebin.com"]
- 缓存搜索:仅允许通过 OpenAI 缓存的网页检索,防止模型直接访问未知外部站点。
- 本地绑定:支持与本机服务(如本地数据库)交互,满足开发调试需求。
- 域名白名单:通过显式列出可信域名,阻断潜在的数据泄露通道。
身份与凭证的统一管理
cli_auth_credentials_store = "keyring"
mcp_oauth_credentials_store = "keyring"
forced_login_method = "chatgpt"
forced_chatgpt_workspace_id = "enterprise-xyz"
所有身份验证均依赖系统钥匙串,避免明文凭证泄露。登录过程强制走 ChatGPT 企业工作空间,使得每一次 Codex 调用都能在 ChatGPT 合规日志平台 中留下完整审计记录。
规则与配置的集中治理
OpenAI 采用云端托管的 requirements.toml 与 macOS 管理偏好相结合的方式,实现 不可覆盖的管理员强制 配置。无论是桌面客户端、CLI 还是 IDE 插件,均遵循同一套安全基线,确保跨平台一致性。
代理原生遥测与审计
Codex 支持 OpenTelemetry 导出以下事件:
- 用户提示 (
log_user_prompt) - 工具审批决定 (
tool_approval) - 工具执行结果 (
tool_execution) - 网络代理的放行或阻断 (
network_proxy)
这些日志可通过 OpenAI 合规平台统一聚合到企业 SIEM,供安全团队进行 意图分析 与 异常检测。配合内部的 AI 安全分流代理,系统能够在端点触发警报时,快速定位是用户误操作、模型误判还是真正的安全威胁。
展望
随着代码生成代理在开发流水线中的渗透,安全治理的需求将进一步细化。OpenAI 已在 Codex 中实现了从 技术边界 到 可审计日志 的全链路控制,未来计划开放更细粒度的策略 API,支持企业自行定义风险模型,并将遥测数据与第三方威胁情报平台深度融合,助力安全团队在保持开发效率的同时,实现对 AI 代理的全方位可视化监管。