OpenAI 如何安全运行 Codex：Agent 时代的“AI 安全操作系统”

原文：
《Running Codex safely at OpenAI》
https://openai.com/index/running-codex-safely/

---

前言

随着 Agent 能力越来越强，LLM 已经不只是“生成文本”。

而是开始真正：

• 执行 Shell
• 修改代码
• 操作 GitHub
• 调用 Kubernetes
• 访问网络
• 自动提交 PR

这意味着：

AI 开始从“建议系统”变成“执行系统”

而一旦 AI 能执行动作：

安全问题就会迅速升级。

OpenAI 这篇文章，本质上讲的是：

如何把 Coding Agent 安全地部署到真实企业环境。

它并不是传统 AI Safety 那种：

• Alignment
• Hallucination
• RLHF

而是：

Agent Runtime Security（Agent 运行时安全）

这是未来 Agent Infra 非常关键的方向。 ([OpenAI][1])

---

一、文章核心思想

OpenAI 对 Codex 的设计目标非常明确：

Agent 必须在“受控边界”内高效工作。

核心原则：

低风险操作尽量无感
高风险操作必须审核
所有行为必须可追踪

对应三个关键词：

核心能力	作用
Sandboxing	限制 Agent 权限
Approval System	控制危险动作
Telemetry	审计 Agent 行为

这其实已经非常像：

“AI 版操作系统权限模型” ([OpenAI][1])

---

二、Sandbox：Agent 必须运行在笼子里

文章首先强调：

Codex 默认运行在 Sandbox 中

Sandbox 会限制：

• 文件写入范围
• 网络访问
• 系统命令
• 本地资源

例如：

allowed_sandbox_modes = ["read-only", "workspace-write"]

意思是：

Codex 只能：

• 只读
• 或仅写入工作目录

不能随意操作整个系统。 ([OpenAI][1])

---

三、Approval System：危险动作必须人工批准

这是全文最重要的设计之一。

OpenAI 并不认为：

所有命令都一样危险

而是：

对不同动作做风险分级。

例如：

低风险：

git diff
gh pr view
kubectl logs

允许自动执行。

高风险：

rm -rf
网络访问
修改系统目录
生产环境操作

必须人工批准。 ([OpenAI][1])

---

四、Auto-review：让 Agent 自己审批低风险行为

OpenAI 做了一个非常有意思的机制：

Auto-review Subagent

流程：

Codex 请求执行动作
    ↓
Auto-review Agent 判断风险
    ↓
低风险自动批准
高风险中断等待用户

这样可以减少：

用户频繁点 approve

的问题。

本质上：

用 Agent 管 Agent。 ([OpenAI][1])

---

五、Network Policy：不给 Agent 开放互联网

这是文章里很关键的一点。

OpenAI 明确表示：

Codex 不允许无限制外网访问

他们采用：

• Allow List
• Deny List
• Proxy Network

机制。

例如：

denied_domains = ["pastebin.com"]
allowed_domains = ["*.openai.com"]

这意味着：

Agent：

• 不能随便访问未知网站
• 不能自由 exfiltrate data
• 不能随意下载恶意内容

这本质上是：

企业级 Egress Control（出口控制）。 ([OpenAI][1])

---

六、Credential Management：Agent 不应该直接持有凭据

文章提到：

OAuth 凭据统一保存在 OS Keyring

例如：

cli_auth_credentials_store = "keyring"

并且：

• 强制通过 ChatGPT 登录
• 强制绑定 Enterprise Workspace

这样做的意义：

把 Agent 权限绑定到组织级身份体系。 ([OpenAI][1])

---

七、Rules System：不是所有 Shell Command 都平等

这是一个非常重要的工程思想。

OpenAI 为 Codex 引入了：

Command Rule System

例如：

prefix_rule(
  pattern = ["kubectl", ["get", "logs"]],
  decision = "allow"
)

意思：

只允许 kubectl get/logs
但不允许 kubectl apply/delete

本质上：

Agent Command Firewall

这和传统：

• Linux capability
• sudo policy
• SELinux

已经非常接近。 ([OpenAI][1])

---

八、Telemetry：Agent 必须“可审计”

文章后半部分重点讨论：

Agent Native Telemetry

传统安全日志只能看到：

发生了什么

例如：

• 某进程启动
• 某文件被修改

但：

看不到“为什么”

而 Agent 最大的问题：

恰恰是：

Intent（意图）

---

九、为什么传统日志不够？

例如：

安全系统发现：

Codex 执行了 kubectl

问题：

它为什么执行？
是谁要求的？
是正常修复还是恶意行为？

传统日志无法回答。

所以 OpenAI 引入：

Agent-aware Telemetry

记录：

• 用户 Prompt
• Tool 调用
• Approval Decision
• Tool Result
• Network Policy

本质上：

给 Agent 增加“行为轨迹”。 ([OpenAI][1])

---

十、OpenTelemetry：Agent 世界的标准日志协议

Codex 使用：

OpenTelemetry（OTel）

导出日志。

例如：

[otel]
log_user_prompt = true

然后接入：

• SIEM
• Compliance Platform
• Security Pipeline

这说明：

Agent 正在进入传统企业安全体系。 ([OpenAI][1])

---

十一、AI Security Triage Agent：AI 审计 AI

文章里最有意思的部分之一：

OpenAI 使用：

AI Security Triage Agent

分析 Codex 行为。

流程：

Endpoint Alert
    ↓
读取 Codex Logs
    ↓
分析用户意图
    ↓
判断：
- 正常行为
- 误操作
- 风险行为

这意味着：

安全系统也开始 Agent 化。 ([OpenAI][1])

---

十二、为什么这是 Agent 时代的重要转折点？

以前：

LLM 更像：

高级搜索引擎

现在：

Codex 已经变成：

可执行系统

而：

一旦 AI 开始“执行”

整个安全模型都会变化。

因为：

传统 Chatbot：

只能输出文本

但 Agent：

能真正修改现实系统

包括：

• 改代码
• 操作云资源
• 修改配置
• 访问生产环境

所以：

Agent Security 会成为未来 AI Infra 核心领域。 ([OpenAI][1])

---

十三、文章背后真正的核心思想

我认为这篇文章最重要的，不是某个配置文件。

而是：

OpenAI 正在把 Agent 当成“操作系统进程”管理。

对应关系非常明显：

Agent 世界	操作系统类比
Sandbox	容器/沙箱
Approval	sudo
Network Policy	防火墙
Rules	SELinux
Telemetry	Audit Log
Workspace Identity	IAM
Auto-review	Policy Engine

这意味着：

Agent Runtime 正在逐渐“操作系统化”。

---

十四、与传统 AI Safety 的区别

传统 AI Safety 关注：

• 有害内容
• 对齐
• 幻觉
• 偏见

而这篇文章讨论的是：

Runtime Safety

核心问题变成：

Agent 能执行什么？
能访问什么？
谁批准？
如何追踪？

这是：

真正面向生产环境的 AI 安全。 ([OpenAI][1])

---

十五、对 Agent 工程的启发

这篇文章其实透露了未来 Agent 系统的标准架构：

1. 默认 Sandbox

Agent 不应直接拥有系统权限。

---

2. 权限分级

不是：

允许 / 禁止

而是：

风险分层。

---

3. Agent 必须可审计

否则企业无法落地。

---

4. Agent 要有行为轨迹

仅有系统日志不够。

---

5. 安全系统也会 Agent 化

未来：

AI 审计 AI

会成为常态。

---

结语

OpenAI 这篇文章最大的价值在于：

它展示了：

Agent 正在从“聊天机器人”变成“受控执行系统”。

而未来真正重要的竞争点：

可能已经不是：

模型会不会写代码

而是：

如何安全地让模型执行代码。

这意味着：

未来 Agent Infra 的核心能力，很可能会围绕：

• Sandbox
• Policy Engine
• Telemetry
• Approval Workflow
• Runtime Governance

Agent Engineering 也正在逐渐演化成： “面向 AI 执行系统的软件工程”