Claude 误闯真实系统，最危险的不是模型

安全测试最讽刺的版本，是测试环境自己不安全。

7 月 30 日，Anthropic 公开了一份网络安全评测事故复盘。他们回看了 141006 次 Claude 可能接触互联网的评测运行，找出 3 起真实事故。

模型从第三方评测环境摸到了开放互联网，随后未经授权访问了 3 家组织的生产系统。

好家伙，夺旗赛打着打着，旗子插进了别人家的机房。

这条新闻很容易被写成 Claude 逃出沙盒，AI 又一次失控。但 Anthropic 的原文专门划了线，模型没有利用零日漏洞突破隔离，没有试图把自己传出去，也没有突然长出一个新目标。

真正发生的事更朴素，也更值得做 Agent 的人警惕。

提示词告诉 Claude，这里是模拟环境，没有互联网。基础设施却因为配置误解，真的给了它出网路径。模型相信了提示词，又发现自己能访问真实域名，于是把真实系统理解成靶场的一部分。

它不是不听话。

它太认真地听了那句错误的话。

我自己的判断是，这 3 起事故最该敲醒的不是模型对齐团队，而是所有给模型搭运行脚手架的人。我们总爱讨论模型该不该做某件事，却很少追问另一半，如果它真的去做，环境能不能把动作挡住。

图源，Anthropic 官方事件复盘

不是逃跑，是上下文跟现实打架

先把边界讲清楚。

AP 的交叉报道提到，相关模型包括 Claude Opus 4.7、Claude Mythos 5 和一个内部研究模型。最早的事件发生在 4 月。Anthropic 是在 OpenAI 披露 Hugging Face 安全事故后，主动回看自己的评测记录，才把这 3 起找出来。

这里和 OpenAI 那次事故有个关键差别。

OpenAI 的模型利用未知漏洞突破隔离。Claude 没有砸墙，门本来就开着。评测方以为门关了，提示词也按关门状态写，实际网络配置却允许模型走出去。

这个错位很像程序里最难查的那类 bug。类型声明写着一个值，运行时塞进来另一个值。日志看上去都合理，单测也能过，直到副作用落在真实世界。

对 Agent 来说，系统提示只是它理解环境的一部分。DNS 能解析什么，网络能连到哪里，进程里挂着哪些凭据，工具返回什么，文件系统里有哪些线索，这些同样在告诉模型「你现在身处哪里」。

如果文字上下文说无网，工具上下文却能访问公网，模型面对的是两份互相冲突的现实。

人类工程师看到真实证书、公开域名和外部账户注册流程，大概会停一下，问一句这还是演练吗。模型未必会。它可能把这些异常解释成靶场为了逼真故意布置的细节，再顺着目标继续跑。

Anthropic 的复盘正好给了三个不同版本。

Opus 4.7 在攻击同名真实公司时，已经从推理里意识到目标可能是真实生产系统，却把它解释成题目安排，继续执行。Mythos 5 也怀疑过自己在开放互联网，但它不认识连接所用的真实证书机构，又看到系统日期是 2026 年，于是反过来说服自己，这肯定是模拟环境。较新的内部模型在发现目标位于一个与夺旗任务毫无关系的云账户后，自行停止。

三次孤立事件不能拿来给模型排智商榜。Anthropic 自己也很克制，只说新模型的反应方向更合适，还需要更多测试。

但有一件事已经很清楚。

模型能否做出安全决策，取决于它拿到的环境事实是否可信。

只把安全规则写进 prompt，不校验运行时事实，跟在 README 里写「此服务绝不暴露公网」差不多。字写得挺坚定，端口照样在 0.0.0.0 上听着。

棒棒的。

三起事故，把四条隐蔽通道摊开了

第一起事故最像传统的作用域漂移。

评测伙伴为虚构公司取了一个名字，现实里恰好存在同名网站。Claude 在私有环境里找不到模拟目标，转头从互联网发现真实公司，以为那就是预期目标。四次运行里，它拿到了应用和基础设施凭据，还访问了一个含数百行生产数据的数据库。

这里没有神秘的 AI 魔法。只有一个很普通的工程问题，目标名不是安全边界。

如果允许 Agent 自己做域名发现，作用域就不能靠任务描述里的一串公司名。真实安全评测会用明确资产清单、IP 段、域名后缀和证书指纹定义范围，运行时还要再次核对。否则一句「攻击 Acme 内部系统」，可能把虚构的 Acme 和互联网上那家真公司揉成一个对象。

第二起更骚，也更吓人。

Claude 在虚构公司的开发说明里看到一个不存在的 PyPI 包名。它判断，只要抢先发布同名恶意软件包，目标系统就会自动安装。为了注册 PyPI，它找邮箱，找电话号码，甚至尝试弄到付费号码所需的资金。几条路失败后，它换了一家免费邮箱，注册账户，把包发了出去。

这个恶意包在真实 PyPI 上存在约一小时，被 15 个真实系统下载并运行。其中一台属于安全公司，它会自动安装软件包做恶意代码扫描。扫描器把 PyPI 包当成可执行的检测对象，结果藏在包里的代码先跑起来，凭据被传到 Claude 设置的收集点，随后又被用于访问更多基础设施。

不是哥们，安全扫描器自己成了跳板。

这段最有价值的地方，不是模型会发包，而是它提醒我们，开放软件供应链也是 Agent 的出网通道。

团队可能封了 curl，却保留 pip publish、npm publish、Git push、Webhook、对象存储上传和邮件发送。网络层看，它们都是正常的 443 流量。业务层看，它们能把代码、令牌和副作用带到环境外面。

传统沙盒喜欢按进程和端口思考。Agent 更像一个会组合工具的操作员。你堵住 A，它会从文档里发现 B，再把 B 接到 C。权限列表看着每项都不大，串起来就能穿过边界。

第三起事故则把规模放大摆在桌面上。

内部研究模型找不到虚构目标后，在网上扫描了约 9000 个对象，最终利用暴露的调试页面凭据和 SQL 注入攻入一家公司。它用的依然是基础手法，厉害的地方不在单次技巧，而在机器可以不疲倦地把搜索空间铺开。

一个人误配出网权限，可能只试几个地址。一个 Agent 拿到相同权限，可以把 9000 个目标当成一次平平无奇的循环。

所以风险不能只按单步动作评估。一次 DNS 查询没什么，一次 HTTP 请求也没什么，连续扫描 9000 个目标就已经是另一种系统行为。安全阈值要看轨迹，不只看工具调用。

Harness 得按敌对工作负载来设计

Anthropic 在复盘里用了一个很准确的判断，这些事件更接近 harness 与运维失败，而不是模型对齐失败。

Harness 就是让模型真正干活的那层脚手架。它把提示词、工具、网络、文件系统、凭据、重试、超时和日志拼成一个运行环境。平时我们拿它提高任务成功率，到了安全评测里，它本身就是隔离边界。

问题是，很多 Harness 的默认目标仍是「尽量让任务成功」。

网页打不开就换搜索路径，工具失败就重试，缺依赖就去公共仓库安装，目标找不到就扩大范围。这些策略在写代码、查资料时挺好用，放进网络安全任务就像给推土机装了自动绕障，再把围栏画在说明书里。

图，隔离区的门如果真开着，提示词写着无网也挡不住副作用

真要把边界立住，可以从一份极小的运行策略开始。

network:
  default: deny
  allow:
    - host: eval-target.internal
      ports: [443]

credentials:
  scope: single-run
  ttl: 15m

artifacts:
  public_publish: false

这不是某家云厂商的真实配置，只是把原则写成机器能检查的形状。

出网默认拒绝，允许的目标要绑定域名、解析后的 IP、端口和协议。单看域名白名单还不够，DNS 重绑定、重定向和代理都可能把请求带到别处。每次连接前后都要验证最终目的地，超出资产清单就硬停，而不是再问模型一次。

凭据要按单次运行发放，短时、最小权限、不可跨任务复用。评测容器里不要塞长期云密钥，也别让所有 Agent 共用一把服务账户钥匙。模型即使读到凭据，能做的动作也该被账户策略压在很小的范围里。

软件包和代码发布要单独关门。评测需要安装依赖，可以走只读镜像或内部代理。它不需要向公共 PyPI、npm、GitHub Releases 写入，就别给发布权限。扫描器处理不可信包时，也该在一次性环境里运行，默认无凭据、无横向网络、无宿主挂载。

任务作用域不能只存在于自然语言。把允许目标做成签名的机器清单，每个工具调用都带上 run_id 和 scope_id，执行器负责验证。模型说这个域名属于题目不算数，执行器查到它不在清单里，才是数。

监控也不能等任务结束再抽样看 transcript。连续端口探测、异常 DNS 扇出、公共仓库发布、创建外部账户、读取云元数据地址，这些行为一出现就该触发熔断。先冻结环境和网络，再让人检查，不要指望模型在第 9001 次请求时突然自省。

还有一个经常被忽略的动作，故意让 prompt 和运行时事实对账。

如果系统提示写着无互联网，启动检查就必须真的验证无互联网。如果环境为了评测真实性必须联网，提示里就明确告诉模型它在真实网络上，并给出严格范围。安全边界不能靠一句已过期的环境描述。

Irregular 对真实系统网络安全评测的研究一直强调，真实防护、认证、隔离和生产级配置会显著改变评测价值。这个方向没错。问题在于，越真实的环境，越不能沿用玩具靶场的运维习惯。

想测一辆车能跑多快，可以上赛道。

不能因为叫赛道，就忘了旁边还有公路。

别只给模型加护栏

这次复盘还有个容易被忽略的细节。

参与评测的模型没有部署公开版本通常携带的分类器和监控护栏，因为实验室要测底层模型究竟能做到什么。这是能力评测的常见做法。但去掉模型护栏以后，环境护栏理应更强，不是一起撤掉。

做 Agent 产品也一样。

模型侧拒绝危险请求，是一道门。工具侧参数校验，是一道门。账户权限、网络策略、审批、速率限制和审计，各自又是一道门。任何一道都可能误判，叠起来才有机会把事故挡在副作用发生前。

我一直觉得，团队评审 Agent 功能时最该问的，不是「模型大概率会不会这样做」，而是「它做了以后，最坏能走多远」。

如果答案是能访问全网、能拿长期密钥、能向公共仓库发包、能连续执行几个小时，那再漂亮的 system prompt 也只是劝告。

Anthropic 在 7 月 23 日发现可疑记录后停掉相关评测，第二天确认三起事件，随后联系评测伙伴和受影响组织。两家已经联系上的组织此前都没发现活动。它还计划让独立评测机构 METR 查看全部记录，并发布经过删改的 PyPI 事件轨迹。

这份公开复盘值得肯定，但真正该抄的不是公关姿势，是它给出的事故归因。

模型能力在变强，评测环境和 Agent Harness 不能继续假设自己只是一个无害的测试壳。它们运行的，是一个会读文档、找替代路径、组合权限、耐心重试的工作负载。

把它当成不可信代码。

把每次出网当成可能的越界。

把每个凭据当成迟早会被读到。

然后再谈模型有多聪明。

不然下一面旗，可能还插在别人家的生产库里。