← 返回信息流
技术博客OpenAI Blog·27 天前

在 OpenAI 安全运行 Codex

原标题:Running Codex safely at OpenAI

速览

本文介绍了 OpenAI 如何保障 Codex 的安全部署,涵盖沙箱隔离、人工审批流程、严格的网络策略以及专为智能体设计的遥测系统。这些措施共同支持了编码智能体的安全采用与合规运营,为 AI 代码助手的企业级应用提供了关键的安全保障。

AI 深度解读

在 OpenAI 安全运行 Codex:沙箱、审批、网络策略与原生遥测的深度实践

来源:OpenAI Blog 原文标题:Running Codex safely at OpenAI

背景

随着大型语言模型(LLM)能力的迅速演进,AI 编码代理(Coding Agents)正从单纯的代码补全工具演变为能够自主执行复杂软件工程的智能体。OpenAI 的 Codex 模型及其后续迭代,旨在通过自然语言指令生成、修改和调试代码,从而显著提升开发效率。然而,当 AI 代理被赋予对内部代码库、构建系统和部署管道的访问权限时,安全风险也随之呈指数级增长。

在 OpenAI 内部,工程师们广泛使用基于 Codex 的代理来加速开发流程。但与此同时,确保这些代理不会意外泄露敏感数据、执行恶意操作或破坏生产环境,是公司技术战略中的核心优先级。传统的网络安全措施往往难以适应 AI 代理动态、自主且上下文依赖极强的行为模式。因此,OpenAI 必须构建一套专门针对 AI 代理的安全架构,以在“促进创新”与“保障安全”之间取得平衡。

本文深入解读了 OpenAI 如何在其内部环境中安全地运行 Codex 代理,重点介绍了其采用的沙箱隔离、人工审批工作流、细粒度网络策略以及专为 AI 代理设计的遥测系统。

核心内容

OpenAI 的安全架构并非单一的技术堆砌,而是一个多层防御体系,旨在从执行环境、访问控制、网络通信和行为监控四个维度全面管控 AI 代理的风险。

1. 沙箱隔离环境(Sandboxing)

防止 AI 代理对宿主系统或外部网络造成不可逆损害的第一道防线是严格的沙箱隔离。OpenAI 为每个 Codex 代理实例运行在一个隔离的容器中。

  • 资源限制:沙箱严格限制了代理可访问的计算资源(CPU、内存、磁盘 I/O),防止资源耗尽攻击或意外导致的系统崩溃。
  • 文件系统隔离:代理只能访问被明确标记为“只读”的代码库副本或经过预处理的特定数据集。任何写入操作都被重定向到临时空间,且仅在经过验证后才会被合并到主分支。
  • 无持久化状态:除非显式配置,否则代理在会话结束后不会保留任何状态。这防止了代理通过持久化恶意代码或数据来绕过后续的安全检查。

2. 人工审批与工作流集成(Approvals)

尽管自动化能提高效率,但在涉及高风险操作时,OpenAI 坚持“人在回路”(Human-in-the-Loop)的原则。

  • 分级权限:根据操作的敏感程度,代理被赋予不同的权限等级。例如,读取代码库可能无需审批,但修改核心基础设施配置或执行数据库迁移则必须经过人工审批。
  • PR 审查流程:Codex 生成的代码通常以 Pull Request(PR)的形式提交。代理本身不直接合并代码,而是触发标准的代码审查流程。工程师必须审查代理生成的代码逻辑、潜在的安全漏洞以及是否符合团队规范,才能批准合并。
  • 意图确认:对于复杂的重构任务,代理会先提出执行计划,由人类开发者确认计划的合理性后,代理才执行具体的代码修改步骤。

3. 细粒度网络策略(Network Policies)

AI 代理可能需要访问外部 API、依赖包仓库或内部服务,因此网络访问控制至关重要。

  • 出站流量限制:默认情况下,代理的沙箱环境禁止所有出站网络连接。只有经过白名单批准的域名和端口(如特定的包管理器镜像、内部 CI/CD 服务)才被允许访问。
  • 数据泄露防护(DLP):在代理与外部服务通信时,OpenAI 部署了数据泄露防护机制,实时扫描输出内容,防止敏感信息(如 API 密钥、个人身份信息、内部架构细节)被意外发送到外部服务器。
  • 内部服务代理化:对于需要访问内部微服务的场景,代理通过特定的代理网关进行通信,该网关会验证代理的身份令牌,并记录所有请求,确保只有授权的代理才能访问特定的内部端点。

4. 代理原生遥测(Agent-Native Telemetry)

传统的日志系统难以捕捉 AI 代理的复杂决策过程。OpenAI 开发了专为代理设计的遥测系统,以提供可见性和可审计性。

  • 全链路追踪:每个代理操作都生成唯一的追踪 ID,记录从用户指令输入、模型推理、工具调用到最终结果输出的完整生命周期。这使得安全团队能够回溯任何异常行为的根源。
  • 上下文感知日志:遥测数据不仅包含操作结果,还包含决策上下文,例如代理为何选择某个特定的代码片段,或为何调用某个特定的 API。这种细粒度的日志有助于区分是模型幻觉导致的错误,还是恶意利用。
  • 异常检测:基于遥测数据,系统可以实时监测代理行为的偏差。例如,如果代理突然开始大量读取非相关代码文件或尝试访问未授权的网络端点,系统将自动触发警报并可能暂停代理执行。

关键要点

  • 多层防御架构:OpenAI 的安全策略不是依赖单一措施,而是结合了沙箱隔离、人工审批、网络限制和行为监控的多层防御体系。
  • 沙箱是基础:通过严格的容器化隔离和资源限制,确保即使代理被恶意利用,其影响也被限制在最小范围内。
  • 人在回路(Human-in-the-Loop):高风险操作(如代码合并、基础设施变更)必须经过人工审查和批准,AI 仅作为辅助工具而非最终决策者。
  • 最小权限原则:网络和文件系统访问遵循最小权限原则,默认拒绝所有访问,仅开放必要的白名单资源。
  • 专用遥测系统:传统的日志不足以监控 AI 代理,OpenAI 开发了代理原生遥测系统,以记录决策上下文和全链路行为,支持事后审计和实时异常检测。
  • 数据泄露防护:在代理与外部通信时,实时扫描输出内容,防止敏感数据泄露。
  • 可解释性与可追溯性:通过全链路追踪和上下文感知日志,确保代理的每一个行为都可追溯、可解释,便于安全团队进行故障排查和安全分析。

意义与影响

OpenAI 在内部安全运行 Codex 的实践,为整个行业提供了宝贵的参考范式。随着 AI 编码代理在企业环境中的普及,如何平衡效率与安全成为关键挑战。

  1. 确立行业最佳实践:OpenAI 的方案展示了如何将传统的安全工程原则(如沙箱、最小权限、审计日志)适应到 AI 代理的新场景中,为其他采用类似技术的企业提供了可借鉴的架构蓝图。
  2. 推动“安全由设计”(Security by Design):该实践强调安全不应是事后补救,而应嵌入到 AI 代理的生命周期中,从模型训练、部署到运行监控,每个环节都需考虑安全风险。
  3. 增强企业采用 AI 的信心:通过证明 AI 代理可以在严格的安全管控下可靠运行,OpenAI 有助于消除企业对 AI 引入潜在安全风险的顾虑,加速 AI 技术在关键业务场景中的落地。
  4. 促进 AI 治理框架的发展:这种精细化的控制机制(如分级审批、原生遥测)为制定更完善的 AI 治理框架提供了实证基础,有助于推动行业标准的形成。

总之,OpenAI 的经验表明,安全与效率并非零和博弈。通过精心设计的架构和严格的管理流程,企业可以在充分利用 AI 代理生产力的同时,有效管控其带来的安全风险。

查看原文 →openai.com