AI智能体安全落地：OpenAI治理经验

智能体安全落地：OpenAI 内部实践

解析 OpenAI 如何管控可自主编程的智能体

随着 AI 系统能力不断增强，编程智能体不再只负责生成代码，还会开始自主完成审查仓库、执行命令以及使用开发工具等高风险操作。由此，原有的安全边界已难以完全覆盖风险场景。对企业而言，如何在持续释放生产力的同时守住可控性底线，正成为部署落地的核心难题。

OpenAI 最新发布的《Running Codex safely at OpenAI》系统性说明了其在内部治理 Codex 智能体时采用的技术框架。通过沙盒隔离、分层审批、网络策略以及智能体原生遥测，OpenAI 形成了一套“多层防护”的闭环方案，可为 AI 智能体的安全落地提供借鉴路径。

01

沙盒隔离与自动审批机制

OpenAI 推进 Codex 的关键思路是“在受限环境里仍保证效率”：低风险动作做到尽可能顺畅，高风险动作则必须触发人工审核。该思路依靠沙盒边界与审批策略的联动来落地——沙盒主要限定代码写入、网络访问等硬性技术条件，审批策略则负责界定何时需要人工介入。

为降低对开发者的频繁打断，OpenAI 还引入了“Auto-review（自动审核）”。该能力由专门的子智能体承担：开启后会结合上下文自动判断并放行低风险操作；一旦发现高风险行为或可能导致非预期后果，系统就会停下并要求人工确认。这样既能保证日常流程顺畅，也能坚守安全底线。

在具体落地方式上，OpenAI 通过 `config.toml` 指定允许写入的根目录，并在 `requirements.toml` 中把沙盒限制为只读或仅限工作区写入，从而避免智能体越界执行。

"Approval policy determines when Codex must ask to perform an action, such as when it needs to do something outside of the sandbox."

—— OpenAI

02

网络访问控制与身份凭证管理

在网络访问方面，OpenAI 采取了高度严格的托管策略，拒绝无约束的出站访问。其网络代理仅允许对已知的目标地址进行连接，拦截非预期域名，并要求对陌生域名执行审批流程。该白名单式机制能显著降低数据泄露风险。

从配置内容可见，OpenAI 将网页搜索限制在“cached（缓存）”模式，并对代码托管平台 Pastebin 进行屏蔽；同时只允许访问 Microsoft 登录页以及 OpenAI 自有域名。通过这种细粒度的网络控制，智能体被约束只能在预先定义的安全通道中运行。

在身份认证层面，所有 CLI 与 MCP OAuth 凭证会被存放到操作系统的安全密钥环中，并要求使用 ChatGPT 完成登录，同时把凭证绑定到特定的企业工作区。如此一来，Codex 的每次活动都能够被纳入企业合规日志体系进行监测，实现身份与行为之间的强关联。

03

指令级精细治理与规则配置

为了在安全与效率之间取得更好的平衡，OpenAI 没有采用“一刀切”的阻断策略，而是对 Shell 命令建立了更细的规则体系。借助 `default.rules` 配置，系统把日常开发中常见的低风险命令直接设为免审批，同时对特定危险命令实施拦截。

举例来看，针对 `gh pr view/list` 与 `kubectl get/describe/logs` 这类偏只读或调试性质的指令，系统会自动判定为“允许”，并给出明确说明：其用途属于只读检查或调试活动。差异化处理让 Codex 能更快完成常规工程任务，而不是对每一条看似无害的命令都反复等待人工放行，从而显著提升人机协作效率。

04

智能体原生遥测与审计追踪

安全控制只是整体体系的一部分，仍需要足够的可见性来支撑排查与追责。传统日志通常只能呈现“发生了什么”（例如进程启动、文件变更），却难以解释“为何会发生”。OpenAI 通过引入智能体原生遥测补足这一环节。Codex 支持输出 OpenTelemetry 风格的日志，覆盖用户提示、工具审批决策、执行结果以及网络策略拦截等全链路细节。

在 OpenAI 内部，Codex 日志会与 AI 驱动的安全分诊智能体（Security Triage Agent）联用。当端点监测工具触发异常告警时，安全分诊智能体会基于 Codex 日志还原原始请求、梳理工具调用链，并结合策略判定结果，进而区分正常业务行为、良性错误以及真正的安全威胁，再把分析结论提交给安全团队。

该机制不仅面向安全审计，也服务于运营监控。团队可利用日志数据评估工具使用率、MCP 服务器调用频率以及网络沙盒拦截率，并用这些指标为策略优化提供依据。

参考