7 月 30 日，我们报告了三起 Claude 模型未经授权访问真实计算机系统的事件。这些模型出于评估目的有意在没有网络安全防护措施的状态下运行，却因第三方评估环境内部的配置错误而接入了互联网。另外，8 月 4 日，英国 AI 安全研究所（UK AI Security Institute）报告了其自身网络安全测试中的一起事件：Claude Mythos 5 在真实互联网上执行了一系列未经授权的操作。该案例中，模型同样是出于评估目的有意在没有网络安全防护措施的状态下运行，并且是被刻意授予了互联网访问权限。
我们正在对这两起事件进行深入分析，并计划与 METR 合作开展独立审查。我们希望确保两项研究都足够全面，未来几周将分享更多信息。
在此期间，我们先分享过去一个月里所做的一些改变。我们认为，这些事件反映出运营安全方面的失误，以及两个对齐问题：动机性推理，以及为完成狭窄任务而愿意采取有害行动（这两点我们在之前的系统卡中都有描述）。在安全方面，我们介绍了对隔离与监控系统所做的改进，以及为第三方评估方制定的实践规范。在对齐方面，我们更深入地讨论了这两个问题；我们也相信，持久的进展不仅来自弄清某一起事件中发生了什么，更来自理解错位（misalignment）最初是如何产生的，为此我们分享了这一方向上的早期研究。
这些事件发生后，关于“放缓前沿推进节奏”（pacing the frontier）的讨论日益增多。有必要区分两种节奏控制。在公司内部，它指的是一系列在安全与速度冲突时优先考虑安全的决策；在整个行业层面，它指的是建立防止恶性竞争（race to the bottom）的机制。本文讨论的是我们在这些事件之前和之后为落实第一种做法所采取的行动。第二种节奏控制需要政府与行业协同，并且应当清晰可见、可验证。我们的一些高级管理层和许多员工最近签署了一封呼吁加强节奏协调的公开信，未来几周我们将进一步说明打算如何为这一努力做出贡献。需要明确我们的立场：我们认为，如果行业能尽快采用一种合法、可验证、有效的协同节奏机制，世界将从中受益。
保护评估与训练环境
虽然我们并不认为这些事件仅仅是运营问题，但我们的首要任务是解决具体的隔离与监控问题。为此我们采取了以下行动：
暂停并加固评估环境
事件发生后，我们暂停了对预发布模型的外部网络安全评估，并在落实下列措施期间短暂暂停了内部评估。7 月 30 日报告的那些事件表明，我们此前主要依赖单一防御层（环境本身的配置），而实际需要多层防御，包括在提示词中设定明确的边界、建立验证沙箱是否按预期封闭的流程，以及实施能够实时干预的监控。OpenAI 的披露（它促使我们在 7 月展开调查）指出，模型在评估期间利用一个未知漏洞逃出了封闭沙箱，这也让我们清楚地认识到，应当把重点放在加固沙箱本身上。
评估暂停期间，我们落实了以下初步措施：
1）我们构建并部署了一个分类器，用于实时自动识别模型何时试图激进地探测或逃离测试环境，或意外获得互联网访问。当分类器标记出此类尝试时，它会在工具调用执行之前拦截该操作、终止任务，并通知人工。1
2）我们对近期预发布模型内部评估（包括网络安全评估和其他评估）的转录记录运行了自动化监控，查找沙箱逃逸（即模型利用我们沙箱中的缺陷访问本应与其隔离的系统）或沙箱配置错误。对于在我们沙箱工具内运行的评估，我们没有发现模型突破沙箱边界、访问不该访问的外部资源的例子。我们确实发现了模型利用的各种沙箱配置错误，但这些都没有导致沙箱之外的系统被入侵。2我们正在积极着手解决这些问题。
3）我们将高风险3的内部网络安全沙箱迁移到了更稳健的隔离方案。我们还在进一步对虚拟化栈进行红队测试，即让预发布模型尝试逃出虚拟化栈，以发现并修补弱点。
在这些措施到位后，我们的内部网络安全评估现已恢复运行。
强化学习环境
我们还对预发布模型的高风险 RL 环境暂停了数周。在此期间，我们构建了一个类似的分类器，并做了修改，避免激励模型去规避这一新的监控，现已将其部署到这些环境中。大部分 RL 已经恢复，但一些高风险环境仍处于暂停状态，需等待人工审查；另一些则需要分类器的更新版本，我们计划很快部署。
更广泛的加固
除了针对高风险评估和训练的工作之外，我们还扩大了离线监控的范围，覆盖了内部前沿智能体使用的大多数其他形式。我们也在为内部推理构建管控，防止 Anthropic 员工在无意中以弱于上述缓解措施的防护运行智能体。
对外部合作伙伴的最佳实践
由于报告的这些事件发生在第三方环境中，我们已要求每一家测试网络安全防护降低的预发布模型的机构承诺遵守一套最佳实践。我们认为这些实践是必要的，原因如下：
- 我们正式发布的模型都带有防护措施，包括实时检查 Claude 输入与输出的分类器，用于拦截被禁止的网络活动，例如恶意软件开发或攻击性漏洞利用代码编写。相比之下，网络安全评估方和一部分早期访问合作伙伴使用的模型，其防护措施被降低，以便准确测试模型能力并开展防御性网络安全工作。
- 网络安全评估格外容易产生这些事件中出现的行为。它们会形成一种选择压力，促使模型在探测周围环境和绕过障碍时表现得更有韧性、更有创造力，而且这类评估要运行成千上万次。
凡是合作伙伴使用自有测试框架（harness）、沙箱或智能体运行网络安全相关评估，这些实践都完全适用。它们不适用于使用 Claude Fable 5 等带有防护措施模型的客户。我们已在这些实践到位的情况下恢复了外部网络安全评估，内部也在遵守这些实践。
沙箱与网络隔离
默认情况下，所有网络安全评估都应在无互联网访问的加固沙箱（隔离的计算环境）中运行。环境唯一应允许的对外连接是连到模型自身的 API，且 API 密钥应保存在环境之外。每次评估开始前都应验证这一配置。有些评估可能需要互联网访问。在这种情况下，我们将在评估预发布模型时与外部评估方合作，判断能否可靠地检测并中止模型采取超出其声明范围的行动的运行。
评估前验证
在开展评估运行之前，评估合作伙伴应：
- 让被测模型探测沙箱的漏洞，先对配置做静态分析，再实际让模型尝试逃逸。应指示模型一旦逃逸成功就停止并报告，且这一切都应在严密的人工监督下进行。此测试应在无互联网访问的条件下进行，最好在第二层沙箱内。由于评估有时要进行数百甚至数千次运行，合作伙伴最好在开始任何评估之前长时间地开展这项测试。
- 确认任何评估挑战原则上确实可解。当评估目标离线或任务无法完成时，智能体往往会寻找其他方法来完成挑战，从而增加其采取评估预期范围之外行动的可能性。4
明确范围设定
每条提示词都应说明演练的范围内与范围外分别是什么，包括目标、允许的操作和网络边界（即模型应当访问和不应访问什么）。边界应以指令的形式表述（例如“你不应访问互联网”），而不是对环境或测试的事实陈述（“你没有互联网访问权限”）。
实时监控
评估方还应使用基于模型或基于规则的监控器，对模型的思考、行动和网络活动进行持续监控，并向该监控器提供演练的范围。如果某次运行违反了这一范围，监控器应向人工发出标记并终止演练。
我们计划与外部合作伙伴协商，继续完善这些指引，并将其扩展到评估之外。特别是，我们正在为可访问 Claude Mythos 5 的合作伙伴制定配套实践（该模型同样在没有网络安全防护措施的状态下运行），并将很快分享更多信息。
对齐评估
隔离与监控对于发现模型采取危险行动的情形至关重要，但它们解决不了模型为什么会采取这些行动。下面我们讨论初步的对齐调查及我们关注的问题，以及我们为防止训练期间作弊所做的持续工作，包括关于作弊如何塑造模型行为的新研究。
评估期间我们模型所处的环境与知识状态
我们的对齐评估仍在进行中，但初步调查指向两个主要的对齐失败，二者我们在此前的系统卡中都有描述。其一是动机性推理：模型最初被告知其环境是模拟的，但后来遇到了表明自己连接到真实互联网的证据时，它们可能以一种能让自己维持原有信念的方式解读了这些证据。其二是鲁莽：为了完成解决网络安全评估这一狭窄目标，模型愿意在真实互联网上采取有害行动。不过，我们也认为评估设置本身促成了这些事件中模型表现出的行为。Claude 被明确告知它没有互联网访问权限，而实际上互联网是可用的，这可能使它怀疑自己看到的系统是否真实。而且在一个案例中，虚构的目标与一个真实网站同名，使得更难区分演练中哪些本应属于范围之内。
我们的结论取决于几个尚未完全回答的问题，包括：模型在多大程度上判断出自己可以访问真实互联网（即使它们起初并不知道这一点）；它们是否明知故犯地无视了环境中某些要素是真实的迹象；以及在若干案例中它们未能终止演练，是否源于动机性推理。我们正在运用多种技术来回答这些问题，包括在对环境做有针对性修改的同时对模型重新采样，以及使用可解释性方法直接检查其内部状态。
研究防止训练期间作弊的努力
尽管模型错位很复杂，可能由各种各样的原因引起，但我们通过实证发现，训练环境中的缺陷，具体来说是容易被作弊利用的环境，或者不作弊就无法解决的环境，对错位行为的贡献尤其大。
下面我们讨论自这些事件发生前数月起，为避免训练环境存在此类缺陷所做的努力。这些努力并不完美，我们的假设是，这些事件至少部分与我们无法彻底消除此类问题有关。我们通过刻意在易受奖励破解（reward hacking）影响的环境上训练一个模型来检验这一假设。在模拟中，该模型重现了更严重的错位行为，其中一些与其他公司今年夏天报告的事件中的行为相似；而我们的生产模型在同样的模拟中则没有出现（本节后文有更多细节）。
我们一直以来都很担心那些会激励作弊的 RL 训练环境，并采取了各种措施来过滤或修复此类环境。
2 月，在发现奖励破解（即模型找到办法欺骗其训练过程，在没有完成指定任务的情况下获得奖励）的迹象后，我们回滚了 Mythos Preview 强化学习运行中三天的训练。我们注意到模型会在代码注释和回复中给“审阅者”写便条，包括在根本没有提到过审阅者的任务中，这是从提示词确实包含审阅者的环境泛化出来的不良行为。它还不断钻一项旨在激励诚实的奖励的空子，堆砌免责声明或附加说明。5回滚这三天让我们得以从这些行为被学会之前的检查点恢复训练，我们也对环境做了修改，防止模型再次学到这些行为。
自 Claude Sonnet 3.7 起（该模型有奖励破解的倾向，我们直到训练后期才发现），我们一直在构建工具来监控模型在 RL 中学到的不良行为。我们投入了大量精力，确保工具随每一代模型不断演进，从少数几个分类器发展到对训练前和训练期间所有环境的自动审查，但到 2026 年春天，这套系统已不堪重负。我们生产 RL 环境的速度比以往任何时候都快，超过了系统的审核能力。被标记的环境需要人工裁定，而奖励破解和配置错误的出现速度开始超过我们过滤或修复的能力。
此外，我们发现有一部分运行意外地在模型的思维链上进行了训练。我们一直努力避免这种情况，因为担心这会教会模型隐藏其真实推理。我们将这一泄漏追溯到生产环境栈中的若干配置错误。在追查过程中，我们清楚地意识到还存在其他由代码长期累积、日益杂乱而产生的问题。
为解决这些问题，4 月我们冻结了生产 RL 环境的所有变更，持续约一个月，借此机会对整个栈进行彻底改造。现在，奖励和环境必须符合一份约定的规范。例如，我们引入了技术性缓解措施，以降低意外在思维链上训练的风险。6在环境质量与监控团队重建这套栈的同时，我们要求环境负责人利用这段暂停期测试并修复他们构建的环境。我们还完全重建了审查流程，要求每个修复后的环境重新认证后才能进入下一次训练运行。
冻结期间，我们在生产混合环境中标记了超过 10% 的环境存在问题，从奖励破解到任务损坏和配置错误不等，并且只有在修复之后才重新启用。
然而，我们的努力并不完美。在某些情况下，我们发现人工审阅者把自动化监控器标记的环境当作误报驳回，导致有缺陷的环境在训练中停留的时间超过了应有的时长。还有一些有缺陷的环境直接漏过了我们的检测机制。我们目前正在收紧驳回标记的标准，并预计会加强与环境负责人的协作，以提高系统的精确度。除监控和检测之外，我们的对齐训练团队与 RL 团队也在合作，帮助改进环境。
我们怀疑，我们在 RL 环境质量控制上的大量投入可能已经避免了更严重的对齐事件；反过来，这些努力中的不完美之处可能促成了我们迄今已发现的这些事件。
为了了解在没有这些保护措施的情况下训练的模型会做什么，我们刻意在 80 个不同的真实 RL 环境上训练了一个 Opus 级模型。这些环境要么在至少一次真实训练运行中被奖励破解并被监控识别出来，要么在环境质量审查中被发现可被破解。得到的模型表现出强烈的取得高分的动机，以及为任务成功而执行潜在有害行动的意愿。随附的Alignment Science 博客文章更详细地讨论了这项实验，此处仅作简要总结。
我们在一系列评估中测试了这个刻意错位的模型，其中包括借鉴英国 AISI 涉及 Claude 的网络安全事件以及 OpenAI/Hugging Face 事件的模拟场景（感谢 OpenAI 公开分享相关细节）。在这些所有工具调用都由另一个 LLM 模拟的评估中，我们训练出的奖励破解模型表现出突破其模拟沙箱、攻击模拟的内部基础设施和模拟的第三方基础设施的倾向。它还愿意篡改自己的奖励函数，为讨好评分器而提供构造生物武器的建议，并反复尝试绕过部署安全监控以便在任务上作弊。
随后，我们在奖励破解训练之前的该模型以及我们的几个公开可用模型上运行了同样的网络安全模拟。它们都没有表现出同等程度的错位行为。我们的结论是，训练中存在大量奖励破解，可能导致模型为了任务成功而愿意执行很长序列的、具有潜在危害的现实世界行动。
我们认为，今年春天我们在监控和减少奖励破解方面投入的大量精力，是我们的生产模型不太可能出现更危险的追逐奖励行为的一个主要原因。在随附的Alignment Science 博客文章中，我们还发现有证据表明，对齐训练环境可以显著减少奖励破解和追逐奖励的行为。但正如 7 月 30 日报告的那些事件所表明的，我们的流程并不完美，我们的模型也并非完美对齐。
需要说明的是，我们并不认为训练环境中的作弊是对齐问题的唯一原因，甚至也不是我们这些事件，或其他前沿 AI 公司那些事件中具体对齐问题的唯一原因。解决对齐问题需要应对非常广泛的潜在问题，未来的对齐事件所涉及的行为和原因，可能与我们迄今所见的不同。
加固安全实践
Anthropic 内部的安全态势并不是 7 月 30 日这些事件的促成因素。这些事件发生在一个误将互联网访问留空开放的第三方环境中；即使模型有这样的倾向，它们也无需从任何东西里“黑出去”。
不过，这些事件仍然凸显了强有力安全措施的至关重要性。除了知识产权或模型权重被盗的常见风险之外，我们现在还必须应对两方面的风险：我们自己的模型黑出 Anthropic 系统，以及我们的模型或其他模型被挪用来对 Anthropic 系统发动外部攻击（攻入）。随着模型能力的提升，尤其是从 Mythos 级模型开始，这些风险变得更加尖锐。下面介绍我们已落实的部分工作，其中大部分在 7 月事件之前就已开展，不过这些事件进一步凸显了这项工作的重要性。
4 月初，看到智能体 AI 的使用趋势之后，我们的安全团队主动在全公司范围内推动了一项以加固防御为唯一目标的工作，必要时优先于其他工作（包括研究）。我们判断，我们的暴露面增长得比防御更快：Mythos 的能力强到足以成为资源充足的攻击者的目标；我们内部对自主智能体的使用已达到传统访问和监控方法并非为之设计的规模；而新基础设施的上线速度意味着，我们的安全必须随环境扩展，而不是以固定的容量运作。
这项工作的成果包括：
- 减少对包含模型权重或客户数据的系统拥有长期访问权限的人工账户和自动化账户
- 将我们的计算集群设置为默认阻止所有出站流量
- 要求内部服务在通信之前相互验证身份
- 淘汰遗留的基础设施配置和共享内部服务
- 收紧我们工作负载所运行的隔离环境
- 扩大主机级可观测性，使基础设施上的异常行为在发生时即可被看到
我们还临时抽调了公司的一部分人力投入这些工作。大约 150 名产品工程师被调去负责安全、可靠性和隐私；研究人员也从预训练或 RL 轮岗出来，专注于防护措施和安全；产品团队则暂停了大多数新功能和新界面的开发。我们为每个团队设定了严格的退出标准，达到后才能回到原来的工作。到初夏，大多数团队已经达标。
在将资源调向安全的同时，我们继续为内部智能体的使用构建隔离与监控。我们的训练和评估工作负载通常运行在与生产系统隔离的沙箱中。自开发 Claude Mythos Preview 以来，我们一直用自己的模型来探测这些沙箱中的任何弱点。我们在4 月对齐风险更新中介绍了对内部编码智能体的离线监控，8 月风险报告则更详细地介绍了该系统以及与之并行运行的各项干预措施，包括对最自主形式的内部智能体使用启用沙箱或自动模式分类器，以及在合并之前对基础设施代码变更进行自动化审查。
这项工作漏掉的是评估，尤其是第三方评估。我们确实对一些高风险评估做了监控，包括实时监控，但总体上，我们只是事后对一部分转录记录样本进行自动化审查。
7 月的这些事件让我们意识到，改进网络安全防御的紧迫性比我们此前认为的还要高。我们正在加倍努力，并将在下一份风险报告中说明更多情况。