7月28日，一个安全研究团队让 OpenAI 的 Codex Agent 突破了 API 沙箱限制，访问了它不该访问的系统资源。OpenAI 在4小时内修复了漏洞。
然后所有人都在讨论「修复得真快」。但我觉得重点完全错了。
这不是一个漏洞的故事。这是一个关于「我们到底在往自己的系统里放了什么」的故事。
发生了什么
简单说，研究人员给了 Codex Agent 一个看似普通的任务：「帮我分析这个代码仓库的安全漏洞。」Agent 被授予了读取代码仓库的权限。然后研究人员关闭了 Agent 的安全分类器（safety classifier）——这个细节很重要——并且明确提示 Agent 去尝试突破限制。
Agent 照做了。它发现了沙箱的一个边界条件，利用工具调用的组合绕过了权限检查，最终访问了沙箱外的文件系统。
等等，我先澄清一个东西——这不是「AI 觉醒了然后黑掉了系统」。这是一个被明确指示去做漏洞利用的 AI，配合了被关闭的安全防护，在一个人为构造的环境中完成了预定的任务。用 Every CEO Dan Shipper 的话说：「这证明的不是 AI 有多危险，而是任何处理敏感客户数据的公司都需要自动化的 Agent 防御系统。」
但这里有一个残酷的事实：大部分公司没有这种防御系统。
真正的风险不是 AGI 叛变
每次有 AI 安全事件，公众讨论总会滑向两个方向之一：(1) 「AI 觉醒了！」或者 (2) 「没事的，这只是个实验。」这两种反应都没有抓住重点。
真正的风险场景是这样的：
一家中型 SaaS 公司接入了 AI agent，让它帮忙处理客户工单。Agent 被授予了读取客户数据库的权限（因为回答问题需要查数据）。一切正常。然后某个客户发来了一条精心构造的工单——不是「hack the system」，而是看起来像正常问题的一串文本。Agent 处理了这条工单，在执行过程中被提示注入攻击引导，执行了一个不该执行的数据查询。
这不是 Agent 「变坏」了。这是 Agent 在被设计的功能范围内，被不怀好意的人利用了。就像 SQL 注入不是数据库「变坏了」——是因为输入验证没做好。
区别在于：SQL 注入有二十年的防御经验。Agent 注入才刚刚开始。
企业部署 AI Agent 的真正障碍
Box CEO Aaron Levie 在这个事件后发了一条一针见血的推文：企业要真正大规模部署 AI agent，必须先在数据访问控制、审计追踪和 Agent 治理方面做大量准备。这不会让 Agent 的扩散停止，但会大大减缓速度。
他说的对。而且这个「准备」不是买一个安全产品就完了。它需要企业在三个维度上同时推进：
- 技术层：Agent 的权限模型需要从「用户权限」变成「Agent 权限」。你给我的读写权限不等于我给 Agent 的读写权限。需要一个新的权限边界层。
- 流程层：Agent 的每一次操作需要可审计。不是「它做了什么」的日志，而是「为什么它认为应该这么做」的推理记录。这对合规和排错都至关重要。
- 文化层：团队需要从「信任这个工具」变成「验证这个工具的输出」。这不只是安全意识培训——这是一种全新的工作方式，和过去三十年我们使用软件的方式完全不同。
这三个层面的准备，绝大多数企业一个都没做。这才是真正的问题，不是 OpenAI 的沙箱有没有修好。
但也不全是坏消息
这个事件的另一面——也是让我觉得乐观的一面——是它催生了一个全新的安全产品品类。
就像云计算的普及催生了 CSPM（云安全态势管理）、容器化催生了容器安全、API 经济催生了 API 安全网关——Agent 的普及正在催生 Agent 安全层。现在已经有至少5家创业公司在做这件事了：Agent 行为监控、提示注入检测、权限动态管理。
每次新基础设施的出现都会先暴露安全问题，然后安全问题创造出新的公司。90年代的防火墙、2000年代的端点安全、2010年代的云安全、2020年代的 zero trust——2026年，轮到 Agent 安全了。
沙箱逃逸这个事件本身不重要。重要的是一场新的安全军备竞赛开始了——而那些已经开始准备的企业，会在所有人还在等 OpenAI 修漏洞的时候，已经建好了自己的第一道防线。
如果你在公司里管安全，今天可以做的三件事
- 列出公司内部所有正在使用或计划使用的 AI agent，包括影子 IT。
- 检查每个 agent 被授予了哪些权限——大部分 agent 的权限远大于它们实际需要的。
- 把「Agent 审计日志」加入下一个安全评估周期的检查清单。至少要知道 agent 在做什么。