在回顾网络安全评估的对话记录时，我们发现了三起事件：Claude 模型在第三方评估环境内部或与之交互的过程中接入了互联网，进而未经授权访问了三个不同组织的真实系统。
下文将说明事件经过、发生原因以及我们将做出的改变。我们鼓励其他 AI 实验室也开展类似的回顾。本文反映的是我们目前的认识；如有细节变化，我们会更新。
7 月 21 日，OpenAI 披露其多个模型利用一个此前未知的（“零日”）漏洞，突破了隔离的测试环境，随后访问了 Hugging Face 的生产基础设施。Hugging Face 是一个面向开源机器学习模型和 AI 数据集的平台。
针对这一事件，我们对自己的网络安全评估启动了大规模回溯审查。具体来说，我们查找的是这样的证据：Claude 是否像访问了 Hugging Face 的那些 OpenAI 模型一样，能够从本应完全隔离的测试环境内部接入互联网。
在审查了 Claude 有可能获得互联网访问权限的 141,006 次评估运行后，我们发现了三起事件：模型在我们的第三方评估合作伙伴 Irregular 的评估环境内部或与之交互时接入了互联网，随后未经授权访问了三个不同组织的生产基础设施。
这三起事件中，Claude 执行的都是夺旗（capture-the-flag）挑战，这是我们评估模型网络能力的方式之一。模型会得到一个虚构的场景，并被告知一条秘密信息（即“旗帜”，flag）被藏在网络中的另一台机器上，它的目标是入侵并取回这条信息。挑战是开放式的，并不规定具体方法。
在所有这些案例中，Anthropic 的评估提示词都向 Claude 明确说明其环境是模拟的，且没有互联网访问权限。由于我们与评估合作伙伴之间的误解，事实并非如此，环境是可以访问互联网的。因此，当 Claude 的搜索把它引向开放互联网上的真实系统时，它把这些系统当作了演练的一部分。（网络安全评估靶场通常包含逼真的细节，以便准确评估模型在真实环境中的能力；一个看起来逼真的目标，本身并不足以向模型表明该目标不属于模拟。）
Claude 误以为所有可访问的对象都在演练范围之内，于是利用弱口令和未经身份验证的端点等基本手段，攻破了受影响组织的基础设施。它没有发现或利用任何复杂的漏洞，并且在每一起事件中，Claude 都只是继续完成其评估所指派的那项具体的夺旗任务。不过，在某些情况下，我们较早的模型即使在获得了自己运行于开放互联网的证据之后仍继续攻击；而我们最新的模型一旦意识到自己身处互联网，就停了下来。在这些情形中，Claude 都没有把自己外传，也没有刻意尝试逃出测试环境。
这些事件涉及三个不同的 Claude 模型：Opus 4.7、Mythos 5，以及一个内部研究测试模型。1最早的事件发生在 4 月。这些评估中的模型都是在没有我们正式向公众提供模型时所部署的标准防护措施的情况下运行的（也就是说，没有我们通常用来防止滥用的分类器和监控）。不过，这些模型确实带有针对该模型的安全训练（也就是说，它们不是我们有时在测试中使用的“仅有用性”（helpful-only）版本）。这里描述的所有评估都运行在专用基础设施上，该基础设施与 Anthropic 的敏感内部系统和客户数据相互隔离，也无法访问它们。
我们于 7 月 23 日星期四开始审查对话记录，并在发现 Claude 可能接入了互联网的记录后，当天就停止了所有网络评估。次日，我们确认了全部三起事件。7 月 27 日星期一，我们通知了评估合作伙伴 Irregular 以及三个受影响的组织。我们联系上的两个组织此前并未发现这些活动，也没有联系过我们，我们正与它们合作进行补救。我们仍在尝试联系第三个组织。
我们是与 Irregular 合作完成这次审查的。感谢他们与我们密切合作，共同弄清并解决这些事件；他们也在进行自己的调查。我们认为，这类合作对于确保模型评估安全、严谨而言正变得越来越关键。我们期待在安全方面的联合工作。
下文将进一步介绍每起事件的详情，以及我们接下来的应对措施。
网络评估的背景
我们定期开展网络安全评估，其中包括模拟真实的攻击性网络安全挑战。这些评估是模型研发和发布过程中的关键一步：对模型能力有细致入微的了解，才能让我们设计出恰当的防护措施，并最终安全地发布模型。
我们于 2025 年 2 月开始进行网络安全评估，当时用 Claude Sonnet 3.7 运行了 Cybench，该基准包含 40 个不同的夺旗挑战。随着新基准的发布和模型能力的演进，我们使用的基准数量不断增加。例如，在 Mythos 5 系统卡中，我们纳入了 CyberGym 和 ExploitBench，这两个基准用于评估语言模型发现新型漏洞的能力。2在这些评估的大多数中，环境并未连接互联网，并且模型也被如实告知了这一点。
我们经常与外部合作伙伴合作，由他们创建并协助运行其中一些网络安全评估。外部合作伙伴提供的环境和场景比我们自己能搭建的更为多样，也能对我们的模型做出独立的第三方评估。
发生了什么
在我们审查的 141,006 次评估运行中，我们发现了三起各自独立的事件（共涉及 6 次运行，其中 4 次影响的是同一个组织；另外两起事件则各自发生在独立的评估运行中）。每起事件对应的虚构夺旗场景各不相同。例如，其中一个场景里，Claude 扮演一家虚构公司的员工，在私有测试环境中攻击该公司的内部系统。
在所有案例中，我们的评估提示词都明确说明 Claude 没有互联网访问权限，但没有对 Claude 寻找旗帜的范围设置任何限制。然而，一处配置错误使得 Claude 在评估中访问的那些机器可以实际接入互联网。直到上周我们通过额外的评估监控发现之前，我们和评估合作伙伴都不知道存在这一配置错误。
我们和合作伙伴双方的若干纵深防御措施，本可以防止这些事件，或至少降低其发生的可能性。评估开始前仔细核验所有互联网访问路径，以及对评估日志做实时监控，本可以帮助更早发现问题。我们和合作伙伴也本可以更彻底地审查评估对话记录或网络日志。此外，如果提示词告诉 Claude 它确实可以访问互联网，也有可能改变 Claude 在接触真实系统时的行为。
Claude 做的正是夺旗演练训练网络安全专家去做的事：寻找抵达旗帜的途径。这种搜索使它发现自己的机器可以访问互联网，但由于系统提示词告诉它没有互联网访问权限，Claude 认为自己最初遇到的一切都属于模拟的一部分，并把它发现的真实系统当成了演练的组成部分。这三起事件涉及三个不同的模型，当出现目标是真实的迹象后，它们各自的反应不同，详见下文。
事件一
在一次评估中，评估合作伙伴选定的虚构目标公司，与一个正在运营的网站域名同名。由于上文所述的误解，这个评估容器意外地拥有直接访问互联网的能力。
在该评估的四次运行中，Claude 在评估环境内抵达其模拟目标时遇到了困难，随后发现这家真实的公司可以通过互联网访问。Claude 以为这就是夺旗任务中的预期目标，便在认定它属于演练的前提下，寻找、识别并利用了该公司基础设施中的漏洞。这四次运行提取了应用和基础设施的凭据等信息，并获得了对一个数据库的访问权限，其中包含数百行生产数据。这是我们发现的影响最严重的一次。
这起事件涉及 Claude Opus 4.7，也是唯一一例模型在得知自己很可能身处真实环境后仍继续攻击系统的案例。在全部四次运行中，模型最终都意识到（从其口头化的推理中可以看出）该系统是真实的；其中两次，模型自我说服，认为这家真实的公司一定是演练的一部分。然而，没有一次因此停止攻击。
事件二
在另一次评估中，Claude 在虚构环境里发现了一份文档，看起来是另一家虚构公司给新开发者的入职配置说明。该说明要求员工从 PyPI（发布 Python 软件的公共软件包仓库）安装一个 Python 包，而这个包实际上并不存在。
Claude 注意到这是一个潜在的突破口：如果它以同样的名字发布自己的包，这家虚构公司的系统就会自动下载并安装它。于是，Claude 构建并发布了一个同名的恶意（本质上是设了陷阱的）Python 包，试图借此赢得夺旗挑战。
Claude 为实施这次攻击不惜大费周章，而这种程度的举动，很可能会让人类参与者意识到这已不再只是一次评估，自己实际上是在上传一个真实的 PyPI 包。例如，在其中一次里，为了创建 PyPI 账号，Claude 需要一个电子邮箱；而为了创建邮箱，它需要一个手机号。在没能找到免费的手机号服务后，它尝试通过几种不同的方式筹款来购买手机号，但都失败了。最后它退回一步，找到了一个免费且没有被封锁的邮箱服务商，用它注册了 PyPI 账号，然后用这个账号向 PyPI 上传了恶意软件。
Claude 认为自己使用的软件包仓库是模拟的一部分，但实际上，这个包在网上公开可用了大约一个小时。在这段时间里，该包被下载并在 15 个真实系统上运行。其中一个系统是一家真实安全公司的扫描器（与场景中虚构的公司无关），该扫描器会例行安装 Python 包并扫描其中的恶意软件。当该公司的扫描器安装这个包时，Claude 的隐藏代码被执行了。我们认为，这家公司的安全扫描器把 PyPI 上的包视为可安全安装的，结果 Claude 得以把该公司的凭据外传到它事先设置的收集点。随后 Claude 又用这些凭据访问了该公司的更多基础设施。
Claude 并没有直接以这家公司为目标，上传软件包时它甚至不知道这家公司的存在。但由于代码发布到了开放互联网，任何运行它的系统都受到了影响。（Claude 上传的软件包已被 PyPI 自身的安全系统自动从 PyPI 移除。我们已将此事件通知 PyPI 团队，并向他们提供了相关的威胁指标。）
这次攻击由 Claude Mythos 5 实施。在运行早期，Claude 自己的推理曾正确指出其行为的后果。它注意到，如果这是真实的互联网，发布这个软件包就是一次真实世界的攻击，“绝对不行，而且肯定不是预期的解法”。然而，它又说服自己仍然身处模拟之中，理由是它不认识那些保护其连接的（实际上完全真实的）证书颁发机构。此外，按 Claude 的说法，系统上显示的 2026 年这个日历日期也证明了环境是人为搭建的。Claude 此后再没有重新审视这个结论；例如，当自动化扫描器开始安装这个包时，Claude 把它们当成了评估中按脚本行动的角色。
我们认为，无论 Claude 对其所处环境抱有怎样的信念，它为发布这个 PyPI 包所做的种种努力都远非理想行为，这是我们将加强训练的一个方面。
事件三
在这次评估中，Claude 无法抵达其预定的虚构目标，便上网寻找替代目标，扫描了大约 9,000 个目标。它最终找到并攻破了一家公司面向互联网的应用，用的是基本且广为人知的网络攻击手段，例如从暴露的调试页面读取凭据和 SQL 注入。
这次攻击由一个内部研究测试模型实施。在运行的大部分时间里，Claude 把它所接触到的（真实）主机仅仅当作演练的一部分，认为它们是模拟的，因而认为自己的行为无害。然而，在运行后期，Claude 意识到被攻破的主机位于一个与夺旗挑战毫无关联的云账号中。它自行得出结论，认为该目标实际上是真实的，并停止了攻击。
我们对 Claude 行为的分析
在上述每个案例中，我们的提示词都明确告诉 Claude 它没有互联网访问权限。在每次运行的大部分时间里，当遇到真实世界的系统时，Claude 都假定它们是演练的一部分（尽管它有时也认出了它们是真实的生产系统）。而且，由于夺旗场景在设计上本来就是要求攻击外部系统，这样做与 Claude 所接到的任务是一致的。
在这一共同背景下，一旦出现目标是真实的迹象，三个模型的表现各不相同。我们最早的模型 Opus 4.7 认识到自己已触及生产系统，却继续攻击。Mythos 5 正确地直觉到自己在访问开放互联网，但经过一番推理，又回到了自己仍处于模拟之中的结论。我们最新的模型，即一个内部研究测试模型，同样考虑过其目标是否真是真实的。当证据显示它们确实是真实的时，它就停止了演练。
这是三起孤立的事件，并不属于受控的实验对比。因此，我们必须谨慎对待由此得出的结论。尽管如此，我们最希望看到的行为，即认识到目标是真实的并在无人提示的情况下主动停止，只出现在这三个模型中最新的那一个身上（而且即便是这个模型，停下之前也比我们希望的走得更远）。这一规律与更先进的模型反应更为恰当相吻合，但要对这一结论有把握，还需要做更多测试。
我们还在与独立 AI 评估机构 METR 沟通，以开展第三方审查，包括让其访问全部对话记录，以及对相关模型的采样访问。与此同时，我们将在一周内发布一份经过轻度删节的对话记录，其中记录了 Claude 构建恶意 PyPI 包的过程。为保护受影响的组织，我们目前无法发布更多对话记录，但一旦条件允许，我们会设法公开。
我们如何应对
我们从这些事件中得到了几点教训。
第一，涉及强大自主能力的评估环境同样需要严格的管控。安全测试之所以要在模型发布前进行，正是因为我们尚不清楚它能做什么。评估环境越来越需要遵循与我们的模型所运行的任何其他系统相同的安全标准。
只包含虚构场景的网络评估靶场，看起来可能风险很低，毕竟里面没有任何真实的东西。然而，随着 AI 能力的进步，我们需要改变对这类威胁的建模方式。即便是在无法接触敏感信息的环境中，先进的智能体本身也构成了相当大的威胁。我们需要更好地协同设计评估环境，并更好地监控评估结果，以应对这一威胁。其中一些解决办法甚至可能很简单；例如，如果提示词清楚说明了评估中哪些系统在范围之内、哪些在范围之外，Claude 很可能一开始就不会去访问互联网。
这不仅适用于内部环境，也适用于第三方供应商：评估供应商搭建的基础设施同样需要加强监控和加固。我们鼓励其他实验室开展类似的审查。此外，对于如何既安全又真实地评估日益强大的 AI 智能体，包括如何在部署前测试中权衡互联网访问所带来的真实性与它引入的风险，整个领域都将受益于一场更广泛的讨论。
第二，对齐的行为与有害的行为之间的界线，取决于模型对自身处境的理解。在这里描述的任何一次运行中，我们都没有看到模型追求其自身目标的证据。相反，模型做的是评估要求它们做的事，只是在大多数情况下，它们是在对环境是否真实抱有错误信念的情况下这么做的。在模型认出系统是真实的却仍继续的那些运行中，它之所以继续，是因为它认定这是挑战的一部分。情境感知是让模型做出对齐决策的一个因素，但在这次的案例中，Claude 的判断是错的。
最后，这些事件表明了纵深防御方法的重要性。我们在没有正式向公众提供的模型所配备的防护措施的情况下运行这类能力评估，是因为我们的目标是衡量底层模型能做什么。只有评估被恰当地隔离，这样做才是安全的。不过，如果启用了我们正式提供的模型上部署的那些防护措施，本可以阻止所发现的这些行为。
归根结底，这些事件是多种因素共同造成的，但秉持无责复盘（blameless postmortem）的文化，我们在着手改进时，把责任视为全在我们自己。首先要确保评估流程的每个环节都是安全的，包括我们与外部合作伙伴对接的方式。今后，这还包括扩大对评估对话记录中意外行为的持续监控，改进我们的调查工具，并对我们所依赖的供应商开展更严格的保障工作。
我们是在 OpenAI 披露其模型逃出了隔离测试环境之后开始这次审查的，我们称赞他们发布了他们的报告。虽然我们同样发现了模型触及了本不该触及的系统的证据，但除此之外，这些事件相当不同：
- 我们是在主动审查网络安全评估对话记录之后发现这些事件的；受影响的组织并未察觉这些活动，我们随后已联系了这三个组织。
- OpenAI 的模型是利用一个新型漏洞逃出隔离的，而这里评估的 Claude 模型是通过一条开放的路径接入互联网的。
- 虽然两者之间并没有完全清晰的界线，但我们认为这些事件更接近测试框架（harness）和运营方面的失误，而非模型对齐方面的失败。我们的模型被告知没有互联网访问权限，并被要求夺取旗帜，而实际上由于配置错误它们是可以访问互联网的。这使它们认为（可以说合乎情理）自己遇到的真实环境是模拟的。
- 值得注意的是，我们最新的模型在意识到自己身处真实环境后，就停止了对评估目标的追求。
这些事实让我们抱有谨慎的乐观：只要对评估基础设施加强监控和管控，并持续投入对齐研究，这类风险是可以克服的。
8 月 3 日更新：更正了 OpenAI/Hugging Face 事件所涉评估的名称。