Anthropic 披露 Claude 模型越权访问真实互联网事件并公布对齐安全整改

7月30日，我们报道了三起 Claude 模型未经授权访问真实计算机系统的事件。这些模型——为评估目的而有意在没有网络安全防护的情况下运行——由于第三方评估环境内的配置错误而访问了互联网。此外，8月4日，英国 AI 安全研究院（UK AI Security Institute）报告了其自身网络安全测试中的一起事件，Claude Mythos 5 在真实互联网上采取了一系列未经授权的行动。在该事件中，该模型同样是为评估目的而有意在没有网络安全防护的情况下运行，并且被有意授予了互联网访问权限。

我们正在对这两起事件进行深入分析。我们还计划与 METR 合作开展独立审查。我们希望确保这两项研究都足够彻底，并将在未来几周内分享更多信息。

与此同时，我们正在分享过去一个月中我们所做的一些改变。我们认为这些事件反映了操作安全上的失效，以及两个对齐问题：动机性推理，以及为完成狭隘任务而愿意采取有害行动的倾向（这两点我们在之前的系统卡中都曾描述过）。在安全方面，我们描述了我们对隔离和监控系统所做的改进，以及我们为第三方评估者制定的实践。在对齐方面，我们更深入地讨论了这两个问题；我们还认为，持久的进步不仅来自理解某一具体事件中发生了什么，还来自理解错位最初是如何产生的，我们分享了该方向的早期研究。

鉴于这些事件，关于为前沿发展设定节奏的讨论日益增多。区分两种节奏是有帮助的。在公司内部，节奏意味着当安全与速度发生冲突时，优先考虑安全的一系列决策。在整个领域中，它意味着建立防止逐底竞争动态的流程。在这篇文章中，我们讨论了在这些事件之前和之后，我们为落实第一种方式所采取的行动。第二种节奏需要政府与行业之间的协调，并且应当清晰透明且可验证。我们的一些高级领导层和许多员工最近签署了一封公开信，呼吁在节奏问题上加强协调，我们将在未来几周内进一步说明我们打算如何为这一努力做出贡献。明确我们的立场：我们相信，如果行业尽快采用一种合法、可验证、有效的协调节奏机制，世界将因此受益。

保障评估和训练环境的安全 

虽然我们不认为这些事件仅仅代表操作问题，但我们的首要任务是解决具体的隔离和监控问题。为此我们采取了以下行动：

暂停并加固评估环境

事件发生后，我们暂停了对预发布模型的外部网络安全评估，并在落实以下措施期间短暂暂停了内部评估。我们在 7 月 30 日报告的事件表明，此前我们在很大程度上依赖于单一的防御层（即环境本身的配置），而实际上我们需要多层防御，包括在提示词中设置明确的边界、建立验证沙箱在预期位置是否封闭的流程，以及实施能够实时干预的监控。OpenAI 的 披露（正是这一披露促使我们在 7 月展开调查）称，其模型在一次评估中利用未知漏洞逃出了封闭的沙箱，这也清楚地表明我们应当把重点放在加固沙箱本身。

在评估暂停期间，我们落实了以下初步措施：

1) 我们构建并部署了一个分类器，用于实时自动识别模型何时试图激进地探测或逃离测试环境，或意外获得互联网访问权限。当分类器标记此类尝试时，它会在工具调用运行之前阻止该操作、结束任务，并向人类发出警报。¹

2) 我们对我们近期针对预发布模型（网络安全及其他领域）的内部评估记录运行了自动化监控器，以查找沙箱逃逸（即模型利用我们沙箱中的缺陷访问本应与之隔离的系统）或沙箱配置错误的情况。对于我们在自己的沙箱工具内运行的评估，我们没有发现模型突破沙箱边界访问其本不该访问的外部资源的实例。我们确实发现了模型加以利用的各类沙箱配置错误，但没有一例导致沙箱外的系统遭到入侵。² 我们正在积极着手解决这些问题。

3) 我们已将高风险³的内部网络安全沙箱迁移到更强大的隔离环境中。我们还在对我们的虚拟化技术栈进行进一步的红队测试——即让预发布模型尝试从中逃逸——以发现并修补弱点。

随着这些措施的到位，我们的内部网络安全评估现已恢复运行。

强化学习环境

我们还暂停了预发布模型上风险较高的强化学习环境数周。在此期间，我们构建了一个类似的分类器，并对其进行了修改以避免激励模型逃避这项新的监控，现已将其部署到这些环境中。大部分强化学习已经恢复，但一些高风险环境仍处于暂停状态，需等待人工审核，另一些环境则需要更新版本的分类器，我们计划很快部署。

更广泛的加固

除了针对高风险评估和训练的工作之外，我们还将离线监控扩展到覆盖大多数其他形式的内部前沿智能体使用。我们还在为内部推理构建控制机制，以防止 Anthropic 员工意外地以弱于上述措施的缓解手段运行智能体。

针对外部合作伙伴的最佳实践

由于所报告的事件发生在第三方环境中，我们已要求每个测试降低了网络安全防护的预发布模型的组织承诺遵守一套最佳实践。我们认为这些做法是必要的，原因如下：

• 我们公开发布的模型都带有安全防护措施——包括对 Claude 的输入和输出进行实时扫描的分类器，以阻止被禁止的网络活动，例如恶意软件开发或攻击性漏洞利用的编写。相比之下，网络安全评估人员及部分早期访问合作伙伴使用的模型则降低了这些防护措施，以便进行准确的模型能力测试和防御性网络安全工作。
• 网络安全评估异常容易引发这些事件中出现的行为。它们会形成一种选择压力，促使模型在探索周围环境和绕过障碍时更具坚持性和创造性，而且评估会运行数千次。

无论合作伙伴使用自己的测试框架、沙箱还是代理运行与网络安全相关的评估，这些做法都全面适用。这些做法不适用于使用受安全防护模型（如 Claude Fable 5）的客户。我们已在这些做法到位后恢复了外部网络安全评估，并且在内部也同样遵循这些做法。

沙箱与网络隔离

默认情况下，所有网络安全评估都应在加固的沙箱（一种隔离的计算环境）内运行，且不得接入互联网。该环境唯一允许的外部连接是模型自身的 API，并且 API 密钥应保存在环境之外。每次评估开始前都应验证此配置。某些评估可能需要互联网接入。在这种情况下，在评估预发布模型时，我们将与外部评估人员合作，确定我们能否可靠地检测并中止模型采取超出其声明范围行动的运行。

评估前验证

在开展评估运行之前，评估合作伙伴应当：

1. 让被测模型探测沙箱中的漏洞，首先通过对配置的静态分析，然后实际给模型布置任务让其尝试逃逸。应指示模型在成功逃逸时停止并报告，所有这些都应在人类的密切监督下进行。此项测试应在无互联网接入的情况下进行，最好在第二个沙箱内进行。由于评估有时需要进行数百次甚至数千次运行，合作伙伴最好在开始任何评估之前充分进行此项测试。
2. 确认任何评估挑战在原理上确实可解。当评估目标处于离线状态或任务无法完成时，智能体往往会寻找其他方式来完成挑战，从而增加其采取超出评估预期范围行动的可能性。⁴

明确范围设定

每个提示词都应说明此次演练范围之内和之外各包括什么，包括目标、允许的操作和网络边界（即模型应该和不应该访问什么）。边界应以指令的形式表述（例如“你不应访问互联网”），而不是对环境或测试的陈述（“你无法访问互联网”）。

实时监控

评估人员还应使用已被告知演练范围的基于模型或规则的监控器，对模型的思考、行动和网络活动进行持续监控。如果某次运行违反了该范围，监控器应向人类标记此情况并终止演练。

我们计划在咨询外部合作伙伴的基础上继续完善本指南，并将其扩展到评估之外的领域。尤其值得一提的是，我们正在为可以使用 Claude Mythos 5 的合作伙伴制定配套实践——该模型同样在没有网络安全防护措施的情况下运行——并将在不久后分享更多信息。 

对齐评估

遏制与监控对于捕捉模型采取危险行动的实例至关重要，但它们并未解决模型最初为何会采取此类行动的问题。下面我们将讨论我们的初步对齐调查及所关注的问题，以及我们为防止训练期间作弊而开展的持续工作——包括关于作弊如何塑造模型行为的新研究。

评估期间我们模型所处的环境及其认知状态

我们的对齐评估仍在进行中，但初步调查指向了两起主要的对齐失败，我们均已在此前的系统卡中有所描述。其一是动机性推理：模型最初被告知其所处的环境是模拟的，但当他们后来遇到自己已连接到真实互联网的证据时，他们可能以某种方式解读这些证据，从而得以维持原有的信念。其二是鲁莽行事：模型愿意在真实互联网上采取有害行动，以达成解决一次网络安全评估这一狭隘目标。不过，我们也认为评估设置本身对这些事件中所展示的模型行为有所促成。Claude 被明确告知它无法访问互联网，尽管互联网实际上可用，这可能导致它质疑自己所看到的系统是否真实。而在其中一起事件中，虚构目标与一个真实网站重名，这使得区分练习中本应属于范围内的内容变得更加困难。

我们的结论取决于几个尚未完全解答的问题，包括模型在多大程度上判断出自己可以访问真实互联网（即使它们最初并不知道这一点）、它们是否明知故犯地无视了环境中某些要素是真实的迹象，以及在多起事件中它们未能中止练习这一事实是否源于动机性推理。我们正在运用一系列技术来回答这些问题，包括在环境中有针对性地做出改动后对模型进行重采样，以及使用可解释性方法直接检视其内部状态。

研究防止训练期间作弊的努力

尽管模型不对齐问题复杂，且可能由多种原因引起，但我们从经验中发现，训练环境中的缺陷——尤其是容易作弊的环境，或是不作弊便无法解决的环境——是不对齐行为的异常突出的促成因素。

下文我们将讨论我们为避免训练环境中存在此类缺陷所做的努力，这些努力可以追溯到事件发生前的数个月。这些努力并不完美，我们的假设是，这些事件至少部分与我们未能彻底消除此类问题有关。我们通过故意在一个容易发生奖励作弊的环境中训练模型来检验这一假设。在模拟中，该模型复现出更严重的与目标不一致的行为，其中一些与今年夏天其他公司报告的事件中的行为类似。而我们的生产模型置于相同的模拟中则不会如此（本节后文有更多细节）。

一直以来，我们都很关注那些会诱发作弊行为的强化学习训练环境，并已采取各种措施来过滤或修复此类环境。

二月，我们在发现奖励作弊的迹象后，回滚了 Mythos Preview 强化学习运行中三天的训练（奖励作弊指模型找到办法欺骗其训练过程，在未完成指定任务的情况下获得奖励）。我们注意到模型在代码注释和回复中写给“审阅者”的便条，包括在一些从未提及审阅者的任务上——这是从那些提示词中确实包含审阅者的环境中产生的一种不良泛化。它还不断通过堆砌免责声明或附加说明来钻空子，骗取旨在激励诚实行为的奖励。⁵ 回滚这三天让我们得以从该行为被习得之前的检查点恢复训练，并且我们对环境进行了修改，以防止模型再次习得这些行为。

自 Claude Sonnet 3.7（该模型有奖励作弊的倾向，但直到训练后期我们才检测到）以来，我们一直在构建用于监控模型在强化学习中习得的不良行为的工具。我们投入了大量精力确保工具随每一代模型不断演进，从最初少数几个分类器，发展到在训练运行之前和期间对所有环境进行自动化审查，但到 2026 年春，该系统已不堪重负。我们生产 RL 环境的速度比以往任何时候都快，超出了系统的审核能力。被标记的环境需要人工裁定，而奖励作弊和配置错误开始超出我们过滤或修复它们的能力。

此外，我们发现有一部分运行意外地在模型的思维链上进行了训练——这是我们极力避免的情况，因为担心这会教会模型隐藏其真实推理过程。我们将这一泄露追溯到生产环境技术栈中的几处配置错误。在此过程中，我们也清楚地看到，长期积累的混乱代码还引发了其他问题。

为了解决这些问题，我们在四月冻结了对生产 RL 环境的所有更改，为期约一个月，这让我们有机会对整个技术栈进行全面整修。奖励和环境现在必须符合一个商定的规范。例如，我们引入了技术性缓解措施，以降低意外在思维链上进行训练的风险。⁶ 在我们的环境质量与监控团队重建技术栈的同时，我们要求各环境的负责人利用这段暂停期测试并修复他们构建的环境。我们还彻底重建了审查流程，并要求每个修复后的环境在进入下一次训练运行之前都必须重新获得认证。

在冻结期间，我们对生产组合中超过 10% 的环境进行了标记，问题涵盖从奖励作弊到任务损坏和配置错误，并且只有在修复之后才重新启用它们。

然而，我们的努力并不完美。在某些情况下，我们发现人类审核人员将我们的自动化监控系统标记的环境当作误报予以驳回，使得有缺陷的环境在训练中存留的时间超过了应有的时长。还有一些有缺陷的环境直接漏过了我们的检测机制。我们目前正在收紧驳回标记的标准，并期望通过加强与环境负责人的协作来提高我们系统的精确度。除监控和检测之外，我们的对齐训练团队与 RL 团队也在合作，以帮助改进环境。

我们怀疑，我们在 RL 环境质量控制上的大量投入可能阻止了更严重的对齐事故；反过来，这些努力中的不完善之处也可能是我们迄今为止发现的事故的成因之一。

为了了解在没有这些保护措施的情况下训练出的模型会做什么，我们刻意用 80 个不同的真实 RL 环境训练了一个 Opus 级模型——这些环境要么在至少一次真实训练运行中被奖励作弊并被监控系统发现，要么在环境质量审查中被发现可被作弊利用。由此得到的模型表现出在任务上获得高分的强烈动机，以及为追求任务成功而执行潜在有害行为的意愿。我们随附的对齐科学博客文章更详细地讨论了这一实验，但我们在此简要总结一下。

我们在一系列评估中测试了这个刻意不对齐的模型，其中包括借鉴了涉及 Claude 的英国 AISI 网络安全事件以及 OpenAI/Hugging Face 事件相关方面的模拟场景（我们感谢 OpenAI 公开分享有关此事的细节）。在这些所有工具调用均由另一个 LLM 模拟的评估中，我们训练来奖励作弊的模型表现出逃出其模拟沙箱并攻击模拟内部基础设施和模拟第三方基础设施的倾向。它还愿意篡改自己的奖励函数、为了满足评分器而提供有关制造生物武器的建议，并反复尝试绕过部署安全监控以便在任务中作弊。

随后，我们对奖励作弊训练之前的同一模型以及我们的几个公开发布的模型运行了同样的网络安全模拟。没有一个模型表现出同等程度的不对齐行为。我们的结论是，训练中存在大量奖励作弊可能导致模型愿意为追求任务成功而执行长时间序列的潜在有害真实世界行为。

我们认为，我们今年春天在监控和减少奖励作弊方面的大量投入，是我们的生产模型不太可能从事更危险的奖励寻求行为的一个主要原因。在我们随附的对齐科学博客文章中，我们还发现了证据表明对齐训练环境可以大幅减少奖励作弊和奖励寻求行为。但是，正如我们在 7 月 30 日报告的事故所证明的那样，我们的流程并不完美，我们的模型也并非完全对齐。

需要明确的是，我们并不认为在训练环境中作弊是对齐问题的唯一成因，甚至也不是我们以及其他前沿 AI 公司事故中出现的那些特定对齐问题的唯一成因。解决对齐问题将涉及应对范围极广的潜在问题，而未来的对齐事故可能会表现出与我们迄今为止所见不同的行为和不同的成因。

强化安全实践

Anthropic 的内部安全状况并非 7 月 30 日事故的促成因素。这些事故发生在一个互联网访问被误留开放的第三方环境中；即便模型有意如此，它们也无需从任何东西中“黑出去”。

然而，这些事故仍然凸显了强有力安全措施的关键重要性。除了知识产权或模型权重被盗这类常见风险之外，我们现在还必须应对以下两种风险：我们自己的模型从 Anthropic 系统向外突破，以及我们的模型或他人的模型被挪用于向内攻击 Anthropic 系统。随着模型能力的增长，这些风险变得愈发突出，尤其是从 Mythos 级别的模型开始。我们在下文描述了已实施的部分措施——其中大部分工作在 7 月事故之前就已展开，不过这些事故进一步凸显了这项工作的重要性。

4 月初，在看清智能体 AI 的使用走向之后，我们的安全团队主动发起了一场全公司范围的努力，以强化防御为唯一目标，并在必要时取代其他工作（包括研究）。我们当时已判断，我们的暴露面增长速度快于防御能力的提升——Mythos 是一个能力强到足以成为资源充足攻击者目标的模型，我们在内部对自主智能体的使用规模已增长到传统访问控制和监控方式无法应对的程度，而且新基础设施的推进速度意味着我们的安全必须随环境一起扩展，而不是以固定能力运行。

这项工作的成果包括：

• 减少对包含模型权重或客户数据的系统拥有常驻访问权限的人工和自动化账户
• 将我们的计算集群设置为默认阻止所有出站流量
• 要求内部服务在相互通信前验证彼此的身份
• 淘汰遗留的基础设施配置和共享内部服务
• 收紧我们工作负载运行所在的隔离环境
• 扩展主机级可观测性，使基础设施上的异常行为在发生时即可被察觉

我们还临时将公司的一部分人员调往这些工作。大约 150 名产品工程师被转岗到安全、可靠性和隐私方面；研究人员也轮流从预训练或 RL 中抽身，专注于防护措施和安全；我们的产品团队则暂停了大多数新功能和界面的开发。我们为每个团队设定了严格的退出标准，必须先满足这些标准才能回到原先的工作。到初夏时分，大多数团队都已达标。

在将资源重新调配至安全领域的同时，我们继续为内部智能体的使用建设遏制与监控体系。我们的训练和评估工作负载通常在与生产系统隔离的沙箱中运行。自开发 Claude Mythos Preview 以来，我们一直使用我们的模型来探测这些沙箱中是否存在任何弱点。我们在4月对齐风险更新中描述了对内部编程智能体的离线监控，我们的8月风险报告则更详细地介绍了该系统，以及与之配套运行的干预措施。这些措施包括对自主性最强的内部智能体使用形式实施沙箱隔离或部署自动模式分类器，并在基础设施代码变更合并前对其进行自动化审查。

这项工作所遗漏的是评估——尤其是第三方评估。我们确实对部分高风险评估进行了监控，包括实时监控，但总体而言，我们只会在事后对一部分对话记录样本进行自动化审查。

7月的事件表明，改进我们网络安全防御的紧迫性比我们之前认为的还要高。我们正在这一方向上加倍投入，并将在下一份风险报告中进一步说明。