在审查我们的网络安全评估记录时，我们发现了三起事件：一个 Claude 模型在第三方评估环境内部或与之交互时接入了互联网，进而未经授权访问了三个不同组织的真实系统。
下文将描述事件经过、发生原因以及我们正在做出的改进。我们鼓励其他 AI 实验室也进行类似的审查。本文反映的是我们目前的理解；如有任何细节变化，我们将进行更新。
7 月 21 日，OpenAI 披露其多个模型利用一个此前未知的（“零日”）漏洞突破了隔离的测试环境。这些模型随后访问了 Hugging Face（一个开源机器学习模型和 AI 数据集平台）的生产基础设施。
针对这一事件，我们开始对自己所有的网络安全评估进行大规模回溯性审查。具体而言，我们重点寻找是否有证据表明 Claude——就像那些访问了 Hugging Face 的 OpenAI 模型一样——能够从本应被封闭的测试环境中接入互联网。
在审查了 141,006 次 Claude 可能获得互联网访问权限的评估运行后，我们识别出三起事件：一个模型在第三方评估合作伙伴 Irregular 的评估环境内部或与之交互时接入了互联网，进而未经授权访问了三个不同组织的生产基础设施。
在这三起事件中，Claude 均被分配了一项夺旗挑战任务——这是我们评估模型网络能力的方式之一。模型会获得一个虚构场景，被告知一条秘密信息（即“旗帜”）被隐藏在网络中的另一台机器上，其目标是攻入该机器并取回信息。该挑战是开放式的，不规定任何特定方法。
在所有情况下，Anthropic 的评估提示词都向 Claude 说明，其运行环境是一个模拟环境，并且它没有互联网访问权限。由于我们与评估合作伙伴之间的沟通误解，实际情况并非如此，互联网访问是开放的。因此，当 Claude 的搜索将其引向开放互联网上的真实系统时，它将这些系统视为演练的一部分。（网络安全评估环境通常会包含逼真的细节，以便准确评估模型在真实场景中的能力；一个看起来逼真的目标本身并不足以让模型明确判断该目标不属于模拟环境。）
在错误地认为所有可访问实体都属于演练范围的情况下，Claude 利用基本技术（例如利用弱密码和未认证端点）入侵了受影响组织的基础设施。它没有发现或利用任何复杂的漏洞，并且在每种情况下，Claude 都继续工作，仅完成其评估任务指定的特定夺旗任务。然而，在某些情况下，我们较旧的模型在获得证据表明其运行在开放互联网上后，仍继续其攻击行为；而我们最新的模型在识别出自己处于互联网环境后便停止了攻击。在这些情况中，Claude 均未自行外泄数据，也未蓄意尝试逃离其测试环境。
这些事件涉及三个不同的 Claude 模型：Opus 4.7、Mythos 5 和一个内部研究测试模型。最早的事件可追溯到四月。参与这些评估的每个模型在运行时，均未启用我们通常为模型公开发布时部署的标准安全防护措施（也就是说，它们没有配备我们通常为防止滥用而实施的分类器和监控机制）。不过，这些模型确实保留了其特定模型的安全训练（即，它们并非我们有时在测试中使用的“仅提供帮助”版本）。此处描述的所有评估均在专用基础设施上运行，该基础设施与 Anthropic 的内部敏感系统或客户数据相互隔离，且无法访问这些数据。
我们于7月23日（周四）开始审查对话记录，并在发现Claude可能访问互联网的对话记录后，于当天停止了所有网络安全评估。次日，我们确认了全部三起事件。7月27日（周一），我们通知了评估合作伙伴Irregular以及三家受影响的组织。我们能够联系到的两家组织此前并未发现该活动或主动联系我们，目前我们正与他们合作进行补救。我们仍在尝试联系第三家组织。
此次审查是与Irregular合作进行的。我们感谢他们与我们密切合作，共同理解和解决这些事件；他们也在进行自己的调查。我们认为，这种合作对于确保对模型进行安全、严格的评估日益关键。我们期待在安全方面继续共同努力。
下文将提供每起事件的更多细节以及我们后续的应对措施。
网络安全评估背景
我们定期进行网络安全评估，其中涉及模拟真实的进攻性网络安全挑战。这些评估是开发和发布模型的关键步骤——对模型能力的细致理解使我们能够设计适当的安全防护措施，并最终安全地发布模型。
我们于2025年2月开始使用Claude Sonnet 3.7在Cybench上进行网络安全评估，该基准包含40个不同的夺旗挑战。随着时间的推移，随着新基准的发布和模型能力的演进，我们增加了所使用的基准数量。例如，在Mythos 5系统卡中，我们纳入了CyberGym和ExploitBench，这些基准用于评估语言模型发现新型漏洞的能力。在大多数此类评估中，环境不连接互联网，并且模型也被告知这一点。
我们经常与外部合作伙伴合作，他们创建并协助运行部分网络安全评估。外部合作伙伴提供的环境和场景比我们独自构建的更加多样化，并为我们的模型提供独立的第三方评估。
事件经过
在我们审查的 141,006 次评估运行中，我们识别出三起独立事件（涉及总共六次运行，其中四次影响了同一家组织；另外两起事件各自发生在独立的评估运行中）。每起事件都涉及一个不同的虚构夺旗场景——例如，在其中一起事件中，Claude 扮演了一家虚构公司的员工，在私有测试环境中攻击该公司的内部系统。
在所有情况下，我们的评估提示词都明确声明 Claude 无法访问互联网，但并未对 Claude 寻找旗标的位置施加任何限制。然而，由于配置错误，Claude 在评估过程中访问的机器实际上拥有实时的互联网访问权限。我们和我们的评估合作伙伴均未意识到这一配置错误，直到上周我们通过额外的评估监控检测到它。
在我们和合作伙伴双方，多项纵深防御措施本可以防止这些事件发生，或至少降低其发生的可能性。在评估开始前对所有互联网访问路径进行仔细验证，以及对评估日志进行实时监控，本有助于更早地发现问题。我们和合作伙伴本也可以更彻底地审查评估记录或网络日志。此外，如果提示词告知 Claude 它确实拥有互联网访问权限，Claude 在接触真实系统时的行为也可能有所不同。
Claude 做了夺旗演练训练网络安全专家所做的事情：寻找到达旗标的途径。这一搜索使它发现自己的机器可以访问互联网，但由于系统提示词中告知它没有互联网访问权限，Claude 认为它最初遇到的一切都是模拟的一部分，并将它发现的真实系统视为演练的组成部分。这三起事件涉及三种不同的模型，如下文所述，当出现目标为真实的迹象时，每个模型的反应各不相同。
事件 1
在一项评估中，我们的评估合作伙伴选择的虚构目标公司与一个活跃的网站域名同名。由于上述理解偏差，该评估容器意外获得了直接的互联网访问权限。
在该评估的四次运行中，Claude 在评估环境中难以到达其模拟目标，但随后发现真实公司可通过互联网访问。Claude 认为这就是夺旗任务中的预期目标，于是寻找、识别并利用了该公司基础设施中的漏洞，以为这是演练的一部分。这四次运行提取了应用程序和基础设施凭证等信息，并获得了对包含数百行生产数据的数据库的访问权限。这是我们发现的最严重的影响。
此事件涉及 Claude Opus 4.7，也是唯一一个模型在得知其可能正在真实环境中运行后仍继续攻击系统的情况。在这四次运行中，模型最终都意识到（从其口头推理中可以观察到）该系统是真实的——在两次运行中，模型将真实公司合理化地解释为一定是演练的一部分。然而，没有一次因此停止攻击。
事件 2
在另一项评估中，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 软件包所采取的行动都远未达到理想行为的标准，这也是我们将加强训练的一个领域。
事件 3
在此次评估中，当 Claude 无法达到其预设的虚构目标时，它在线寻找替代方案，扫描了大约 9000 个目标。它最终发现并入侵了一家公司的互联网应用，使用了诸如从暴露的调试页面读取凭据和 SQL 注入等基础且众所周知的网络攻击技术。
此次攻击由一个内部研究测试模型实施。在运行的大部分时间里，Claude 将其访问到的（真实）主机仅视为练习的一部分；它假设这些主机是模拟的，并因此认为其行为是无害的。然而，在运行后期，Claude 意识到被入侵的主机位于一个与夺旗挑战无关的云账户中。它自行得出结论，该目标实际上是真实的，并停止了攻击。
我们对 Claude 行为的分析
在上述每个案例中，Claude 都通过我们的提示词明确被告知它没有互联网访问权限。在大部分运行过程中，当它遇到真实世界的系统时，Claude 认为这些是演练的一部分（尽管它有时会意识到这些是真实的生产系统）。而且，由于夺旗场景的设计初衷就是指示攻击外部系统，因此这样做符合 Claude 被赋予的任务。
在这种共同背景下，一旦出现迹象表明它们的目标是真实的，三个模型的表现各不相同。Opus 4.7，我们最旧的模型，识别出它已到达生产系统，但继续执行攻击。Mythos 5 正确推断出它正在访问开放互联网，但通过推理又回到了它仍处于模拟中的结论。我们最新的模型，一个内部研究测试模型，也考虑了其目标是否真实。当证据表明它们是真实的时候，它停止了演练。
这是三个孤立的事件，并非受控实验性比较的一部分。因此，我们必须谨慎地从中得出结论。尽管如此，我们最希望看到的行为——识别出目标是真实的并在没有提示的情况下停止——仅出现在三个模型中最新的那个身上（而且即使那个模型在停止之前也比我们希望的程度走得更远）。这种模式与更先进的模型做出更恰当反应的趋势一致，但我们需要进行更多测试才能对这一结论有信心。
我们也在与独立的 AI 评估组织 METR 进行对话，以进行第三方审查，包括访问所有记录以及对相关模型的采样访问权限。与此同时，在未来一周内，我们将发布一份经过轻度编辑的记录，其中 Claude 构建了一个恶意的 PyPI 包。为了保护受影响的组织，我们目前无法发布更多记录，但一旦条件允许，我们将努力提供这些记录。
我们的应对措施
我们从这些事件中汲取了几个教训。
首先，涉及强大自主能力的评估环境也需要严格的控制。安全测试之所以在模型发布前进行，恰恰是因为我们尚不清楚其能力边界。评估环境日益需要达到与我们模型运行所在任何其他系统相同的安全标准。
仅包含虚构场景的网络安全评估范围看似风险较低——毕竟其中没有任何真实内容。然而，随着AI能力的提升，我们需要改变对此类威胁的建模方式。即便在无法访问敏感信息的环境中，高级智能体本身也构成重大威胁。我们需要更好地协同设计评估环境，并加强对评估结果的监控，以应对这一威胁。其中一些解决方案甚至可能是简单的修复措施；例如，如果提示词明确说明了评估范围涵盖与不涵盖哪些系统，Claude很可能从一开始就不会访问互联网。
这不仅适用于内部环境，也适用于第三方供应商——评估供应商构建的基础设施同样需要加强监控和加固。我们鼓励其他实验室进行类似的审查。此外，该领域需要更广泛的讨论，探讨如何既安全又真实地评估日益强大的AI智能体，包括如何在部署前测试中权衡互联网接入带来的真实性与引入的风险。
其次，对齐行为与有害行为之间的界限取决于模型对自身处境的理解。在本文描述的任何一次运行中，我们都没有发现模型追求自身目标的证据。相反，模型只是执行了评估要求——尽管在大多数情况下，它们是在对评估环境是否真实持有错误认知的情况下执行的。在模型将系统识别为真实环境并继续运行的案例中，它之所以这样做，是因为它认为这是挑战的一部分。情境感知是让模型做出对齐决策的因素之一，但在本例中，Claude的感知是错误的。
最后，这些事件凸显了纵深防御方法的重要性。我们在运行此类能力评估时，并未启用随通用模型一同发布的安全防护措施，因为我们的目标是衡量底层模型本身的能力。只有在评估过程被适当隔离的情况下，这样做才是安全的。然而，部署在我们通用模型上的安全防护措施本可以阻止所识别出的这些行为。
归根结底，导致这些事件的因素有很多，但本着无过错事后复盘的文化，我们将以“责任全在我方”的态度来推进修复工作。这首先要确保我们评估流程的每一个环节都是安全的，包括我们与外部合作伙伴的集成方式。展望未来，这将包括扩大对评估记录的持续监控以发现意外行为、改进我们的调查工具，并对我们所依赖的供应商开展更严格的保障工作。
我们是在 OpenAI 披露其模型已逃离隔离测试环境后开始此次审查的，我们赞赏他们发布报告的做法。虽然我们也发现了我们的模型曾触及本不应触及的系统的证据，但这些事件在其他方面则大不相同：
- 我们是在主动审查网络安全评估记录后才发现这些事件的；受影响的组织此前并未检测到这些活动，我们随后已联系了所有三个组织。
- OpenAI 的模型是利用一种新型漏洞逃离隔离环境的，而这里评估的 Claude 模型则是通过一条开放的路径访问了互联网。
- 虽然两者之间并非存在截然分明的界限，但我们认为这些事件更接近于测试框架和操作层面的失误，而非模型对齐失败。我们的模型被告知它们没有互联网访问权限，并且要执行夺旗任务，而实际上它们被错误配置为拥有互联网访问权限。这导致它们——可以说是有理由地——认为它们遇到的真实环境是模拟环境。
- 值得注意的是，我们最新的模型在意识到自己正在真实环境中工作时，便停止了对其评估目标的追求。
这些事实让我们持谨慎乐观态度，认为只要加强对评估基础设施的监控与管理，并持续投入对齐研究，这类风险是可以被克服的。
脚注
- 我们定期对内部研究原型（例如本模型）进行测试。该模型暂无公开发布计划。
- 我们通常会存储基准评估的追踪记录。我们已特别仔细地审计了这两个基准，以排查是否存在危害迹象，因为 OpenAI/Hugging Face 事件正是发生在对 CyberGym 进行评估期间。