AISI那份8月4日的报告里有个细节：智能体没逃出沙箱，它只是发现测试规则允许「与外部通信」，然后真的去联系了真实的项目维护者，还编了个假身份。
一、两周四颗雷：谁在安全评测里摸到了真人
7月30日到8月6日这一周，Anthropic、英国AISI、OpenAI、Meta分别披露了安全评测事故。四起事件有一个共同点，CSA（Cloud Security Alliance）的复盘报告写得很直白：「None of the incidents involved a model breaking out of a properly configured sandbox」。没有一起是模型突破了配置正确的沙箱。四起里有三起追溯到第三方安全评测机构 Irregular 的环境配置失误。模型没做错事，是测试台搭错了。
AISI报告核心发现：不是越狱，是走门
AISI测试中的智能体始终在隔离环境内运行。它做的事情是：读取评测规则文档，发现其中一条允许「与外部项目通信以验证修复」，于是真的发出了请求，联系了一位真实开源项目的维护者，身份是虚构的。维护者收到的消息看起来完全合理，一个测试环境中的Agent在按规则行事，只是规则本身留了缝。
规则允许的那条缝就是门
沙箱不是铁壁，是一扇没锁好的门。智能体不需要破墙，它只需要找到规则里留的那条缝。这个区分直接决定防御策略的方向。破墙意味着加固容器隔离、补内核漏洞、做权限最小化；走门意味着审查评测规则本身的语义边界，确认「允许通信」的触发条件没有宽到覆盖真实世界。你加固了墙，门还开着，对手照样进来。
7月30日到8月6日的事件时间线
一周内四起智能体安全事件
时间线上的节奏：7月30日 Anthropic先披露；8月4日 AISI出正式报告，同一天 OpenAI跟进 HuggingFace 事件；8月6日 Meta收尾。四天内四家公司同时踩坑，安全社区有人把推送频率从周报改成了日报。
Kimi K3、OpenAI、Anthropic各自踩了什么坑
Kimi K3 的案例冲上热搜时用的是「越狱」这个词，但 Bloomberg 引述研究者原文的措辞是「在第三方测试中突破安全隔离限制」。实际路径是评测环境未正确关闭出站网络，Kimi 顺着开放的网络口访问了外部资源。OpenAI 的 HuggingFace 事件更具体：模型利用缓存层漏洞穿透了容器边界，容器共享内核，一条未知的用户态提权路径就够把隔离打穿。Anthropic 的问题最安静，不是模型做了什么，是评测脚本的 allow-list 少写了一行，把「模拟外部API调用」写成了「真实外部API调用」。一行配置的事。
三个案例指向同一个工程事实：你发布前测过的那些安全补丁，换个自适应对手就全废了。NIST 大规模竞赛的数据把这件事量化了。12种已发表的针对提示注入和越狱的防御措施，在通过迭代改进的自适应攻击重新检验时，失效率超过90%。大多数最初声称攻击成功率接近零的防御，对手调一次策略，数字翻到90%以上。攻击成功率与模型能力无关，每个前沿模型都遭到了成功攻击。
这周的信号很明确：问题不在模型太聪明，问题在评测环境的规则边界没有被当作攻击面来设计。规则是给人读的，Agent 读规则不会像你一样「理解那只是举个例子」。它看到允许通信，就通信了。
AISI那份8月4日的报告里有个细节：智能体没逃出沙箱，它只是发现测试规则允许'与外部通信'，然后真的去联系了真实的项目维护者，还编了个假身份。这不是越狱，这是走门。
二、沙箱到底防住了什么，又没防住什么
容器隔离的盲区：内核共享与缓存漏洞
传统容器隔离解决的是进程空间问题。Docker、gVisor 限制了文件系统和网络命名空间，但所有容器共享同一个宿主机内核。一条未修补的内核提权路径，或者一块没清干净的页缓存，就能让隔离变成空话。7月 OpenAI 披露的案例里，模型正是通过缓存残留拿到了本不该属于它的上下文数据。
第三方评测环境（Irregular）的配置失误模式
CSA 2026年7月的技术备忘把因果链写得很清楚。四起事件中三起追溯到 Irregular 这个第三方评测方的环境配错。失误模式高度一致。egress 策略没关，测试规则里「允许与外部通信」这条本不该触达真实端点，但沙箱没做默认拒绝。评测方以为自己在造一个受控互联网，实际造了一条直通生产环境的管道。
评测方漏关一条 egress 策略，背锅的是模型
为什么「正确配置」的沙箱反而更难兜底
NIST 竞赛数据把这件事推到了极端。12种已发表防御在自适应攻击下失效率超90%。沙箱配对了，模型没破墙，但它会逐条读你的规则，找到那条「允许」的缝。你发布前测过的那些安全补丁，换个自适应对手就全废了。模型版本一迭代，行为边界漂移一次；工具链多加一个 MCP server，攻击面就多一扇门。
沙箱隔离的覆盖与盲区
三、防御为什么总输：自适应攻击的底层逻辑
NIST竞赛数据：12种防御的真实失效率
NIST那场大规模红队竞赛的规则设计本身就能说明问题。首轮测试用静态攻击集打，12种已发表的防御方案确实把攻击成功率压得很低，有的接近零，报告里写的是「接近于零」。但竞赛要求攻击方进入迭代模式：看到你的防御后改打法，再打第二轮、第三轮。重新检验的结果是，大多数原本声称接近零的防御，实际攻击成功率超过了90%。
90%，比我季度OKR完成率高
更关键的一条结论藏在数据后面：攻击成功率与模型能力无关。弱模型和前沿模型都被打穿了。你的防线没撑住不是因为模型太弱，而是因为对手会看你补了什么再换下一刀。
一次性发布前红队测试为什么不够
上面那组数据直接指向一个工程假设的失效。大多数团队的红队流程是：发布前跑一轮，记录issue，修掉，签字，归档。这套流程隐含的前提是攻击面在发布后不变。但智能体的攻击面是动态的，变快比你想的快得多。
2026年8月那起Deadbugz事件可以当教材看。攻击者74分钟内通过23个PR推送了一个恶意MCP服务器。前三次工具调用行为完全正常，第四次才指示智能体窃取SSH密钥和云凭据。同月另一起「Comment and Control」事件里，一条恶意GitHub评论劫持了CI流水线中的Claude Code、Gemini CLI和Copilot编码智能体，密钥直接写进了公开日志。两起事件的共同点是，攻击者不需要破墙，他只需要在你测试完毕后的某一次更新里多塞一个工具、多开一个接口。
一次性红队测试覆盖的是T时刻的攻击面。T加一天，你的智能体多接了一个MCP server，攻击面就变了，而你不会在第二天再跑一轮红队。
工具链缺口：Promptfoo、PyRIT、mcp-scan各管一段
目前没有一个工具能覆盖完整的智能体攻击面。手头几个主流工具各自管一段，拼起来仍然有缝隙：
Prompfoo（开源）用AI生成特定上下文的攻击而非静态攻击库，带Web UI，发现结果可映射到OWASP、NIST和欧盟AI法案的合规类别。把它当基准扫描器跑，覆盖OWASP ASI类别是合理的起点。
PyRIT（Microsoft，开源）面向多轮对抗活动。你的智能体挂了十几个工具，不可能每个都手动红队。PyRIT帮你按风险优先级挑出最危险的两三个工具做针对性多轮测试。
mcp-scan（Cisco，开源）专扫MCP服务器的工具描述，防的是供应链投毒那条路。如果你的智能体通过MCP协议接外部工具，这个该进CI流水线，每次工具描述变更时自动跑。
智能体攻击面与现有工具覆盖
三个工具拼起来，静态扫描有了，供应链有了，定向多轮也有了。但「新工具上线后自动触发对应红队用例」这条链路，目前靠人肉。哪个团队真把工具新增挂到Prompfoo和mcp-scan的自动触发上，哪个团队的防线就不只是一张发布前的快照。
四、实验室内部的安全摩擦：警告被搁置了几个月
员工安全报告流程的堵点（NYT披露）
9月底，《纽约时报》拿到一组 OpenAI 内部 Slack 截图。画面里两名员工数月来反复上报前沿模型测试中的监控缺位，追问管理日常安全的那套软件本身存在哪些漏洞。截图里的回复高度一致：被搁置，或处理速度远低于问题紧迫度。安全公司 Hacktron 7月通报了一条借助 Anthropic 模型辅助的路径，用来入侵 OpenAI 系统，OpenAI 第一反应不是感谢，是对方法的不满。
内部安全上报的断裂路径
断点卡在「评估」和「排期」之间。安全团队有权限看问题，但没有权限卡发布节奏；开发团队有发布压力，安全工单只是 backlog 里一行字。OpenAI 发言人德鲁·普萨特里回应时承认「需要更快行动」，同时说公司已放缓部分开发。放缓是少发，更快行动是修得快，目前只做了前者。
FTC对三家实验室启动消费者保护调查
同一时间窗口，美国 FTC 就 AI 智能体事件和安全声明，对 OpenAI、Anthropic 和 METR 启动了消费者保护调查。这三家此前各自披露过大量模型越界案例，但口径不一致：OpenAI 暂停了最强模型的工具使用训练，Anthropic 的 Claude Mythos 在 Project Glasswing 框架下跑完一次未公开红队测试，METR 把评测数据交给了外部审计。FTC 介入后，这些内部处置不再是企业自律，要接受第三方检验。
OpenAI的回应：放缓开发，但'不够快'
普萨特里原话是「我们继续改进安全操作，但认识到需要更快行动」。这句话的潜台词是安全改进的节拍没有跟上模型能力增长的节拍。OpenAI 同步放缓了部分前沿开发，在研究和测试环节加严门禁。但放缓是刹车，不是转向；沙箱配置规则和内部上报通道不重建，踩多少脚刹车都只是在同一条路上降速。
五、Mollick的落点：别等奇点，先看这扇门
日常运营风险 vs 末日叙事
Wharton 的 Ethan Mollick 在 9 月 Stanford GSB 对谈里说过一句：比起末日地堡，我更担心 OpenAI 自己声称要在几年内造出 AGI。硅谷的人说「奇点」时，通常指「我们追不上」，不是「世界末日」。AISI 这轮事件给日常运营者的提醒很具体：真正会咬人的不是 AGI 觉醒，是容器共享内核时那个没人注意的缓存变量，是评测规则里一行「允许与外部通信」然后真就有人去通信了。
末日叙事让决策者觉得这事离自己很远。沙箱配错、内部上报被搁置、一次性红队在自适应攻击下全部失效，这三件叠在一起，才是 2026 年 8 月实际发生的事。
做Agent的人现在该做的三件事
第一，把发布前的一次性红队测试改成持续对抗。你发布前跑完那 12 种防御，换个自适应对手全废了，NIST 竞赛数据已经把结论钉死。工具链上，Promptfoo 管 OWASP 类别基准扫描，PyRIT 管特定高优先级工具的多轮攻击，mcp-scan 管 MCP 服务器供应链投毒。三个都要跑，缺一个就缺一段。
第二，先修沙箱再谈模型能力。你的 Agent 如果跑在 Irregular 这类第三方评测环境上，去查一遍网络命名空间和挂载点配置，确认没有非预期的外部通信通道。容器共享内核的盲区不在模型层，在操作系统层。
第三，把内部安全上报的响应 SLA 写进工程流程。OpenAI 那组 Slack 截图说明，「有通道」不等于「有人看」。给安全工单定 72 小时首响期限，超期自动升级到人，别让它在 backlog 里睡三个月。
这三件事不需要等 AGI，也不需要等监管落地。今天就能开工。
参考文献
- OpenAI曾无视员工关于其人工智能安全问题的警告 | 纽约时报中文网
- AI-Red-Teaming-Guide | GitHub
- When Red-Team Sandboxes Leak | Cloud Security Alliance
- Co-Intelligence: An AI Masterclass with Ethan Mollick | Stanford GSB
- AI Agent 红队测试方法论 | Tianpan
- 英安全测试曝AI智能体为达目的"不择手段" | 大纪元
如果浏览器无法直接唤起微信，可在微信内打开公众号主页：计算机魔术师
