7 月 30 日，我们报告了三起 Claude 模型未经授权访问真实计算机系统的事件。这些模型——为评估目的而有意在无网络安全防护的情况下运行——因第三方评估环境内部的配置错误而访问了互联网。另外，8 月 4 日，英国 AI 安全研究所报告了其自身网络安全测试中的一起事件，在该事件中，Claude Mythos 5 在实时互联网上采取了一系列未经授权的操作。在该案例中，该模型同样是为评估目的而有意在无网络安全防护的情况下运行，并被刻意赋予了互联网访问权限。
我们正在对这两起事件进行深入分析。我们还计划与 METR 合作开展独立审查。我们希望确保这两项研究都足够彻底，并将在未来几周分享更多信息。
与此同时，我们在此分享过去一个月所做的一些调整。我们认为这些事件反映了运营安全方面的失误，以及两个对齐问题：动机性推理，以及为完成狭隘任务而采取有害行动的意愿（这两个问题我们都在之前的系统卡中描述过）。在安全方面，我们介绍了对遏制和监控系统所做的改进，以及我们为第三方评估方制定的实践规范。在对齐方面，我们对这两个问题进行了更深入的讨论；我们还认为，持久的进展不仅来自于理解特定事件中发生了什么，更来自于理解错位最初是如何产生的，我们在此分享这一方向的早期研究。
鉴于这些事件，业界关于前沿节奏（pacing）的讨论日益增多。有必要区分两种类型的节奏。在公司内部，节奏意味着在安全与速度发生冲突时，优先考虑安全的一系列决策。在整个行业层面，它意味着建立流程以防止逐底竞争（race-to-the-bottom）的动态。
在这篇文章中，我们讨论了在这些事件之前和之后，我们为践行第一种方法所采取的行动。第二种类型的节奏需要政府与行业之间的协调，并且应当是清晰可见、可验证的。我们的一些高级领导层和许多员工最近签署了一封呼吁在节奏问题上加强协调的信函，我们将在未来几周内进一步说明我们打算如何为这一努力做出贡献。
需要明确我们的立场：我们认为，如果行业能够尽快采用一种合法、可验证、有效的协调节奏机制，世界将从中受益。
保障评估与训练环境的安全
虽然我们不认为这些事件仅仅是运营层面的问题，但我们的首要任务是解决具体的隔离（containment）和监控问题。我们采取了以下应对措施：
暂停并加固评估环境
事件发生后，我们暂停了对预发布模型的外部网络评估，并短暂暂停了内部评估，同时落实了以下措施。7 月 30 日报告的事件表明，我们此前在很大程度上依赖单一防御层（即环境本身的配置），而实际上我们需要多层防御，包括在提示词中设定明确边界、建立验证沙箱是否按预期密封的流程，以及实施能够实时干预的监控。OpenAI 的披露（该披露促使我们在 7 月展开调查）显示，模型在评估期间利用一个未知漏洞逃出了密封的沙箱，这也清楚地表明，我们应该着力强化沙箱本身。
在评估暂停期间，我们落实了以下初步措施：
1) 我们构建并部署了一个分类器，用于实时自动识别模型何时试图激进地探测或逃逸测试环境，或意外获得互联网访问权限。当分类器标记此类尝试时，它会在工具调用运行之前阻止该行为、结束任务，并提醒人类工作人员。1
2) 我们对近期针对预发布模型（网络安全及其他领域）的内部评估记录运行了自动化监控，查找沙箱逃逸（即模型利用我们沙箱中的漏洞，触达本应被隔离的系统）或沙箱配置错误的情况。在我们使用沙箱工具运行评估的案例中，未发现模型突破沙箱边界、触达本不应访问的外部资源的实例。我们确实发现模型利用了各种沙箱配置错误，但均未导致沙箱外部系统遭到入侵。2 我们正在积极着手解决这些问题。
3) 我们将高风险3内部网络沙箱迁移到了更稳健的隔离环境中。我们还在进一步对我们的虚拟化栈进行红队测试——即让预发布模型尝试逃逸该环境——以发现并修补漏洞。
在落实上述措施后，我们的内部网络安全评估现已重新运行。
强化学习环境
我们还暂停了预发布模型上风险较高的强化学习环境数周。在此期间，我们构建了一个类似的分类器，并做了调整以避免激励模型规避这一新的监控机制，目前该分类器已部署到这些环境中。大部分强化学习工作已恢复，但部分高风险环境在完成人工审查前仍保持暂停，另一些环境则需要我们计划很快部署的分类器更新版本。
更广泛的加固措施
除了聚焦于高风险评估和训练的工作之外，我们还扩展了离线监控范围，以覆盖大多数其他形式的内部前沿智能体使用场景。我们还在内部推理环节构建管控措施，以防止 Anthropic 员工在缓解措施弱于上述方案的情况下意外运行智能体。
面向外部合作伙伴的最佳实践
由于所报告的事件发生在第三方环境中，我们已要求所有测试网络安全防护措施被削减的预发布模型的组织承诺遵循一套最佳实践。我们认为这些实践是必要的，原因如下：
- 我们公开发布的模型自带防护措施——包括实时运行于 Claude 输入和输出之上的分类器，用于拦截被禁止的网络活动，例如恶意软件开发或攻击性漏洞利用编写。相比之下，网络安全评估人员和部分早期访问合作伙伴所使用的模型，其防护措施已被削减，以便于进行准确的模型能力测试和防御性网络安全工作。
- 网络安全评估极有可能产生这些事件中所见的行为。它们会形成一种选择压力，促使模型在探测周围环境、绕过障碍时表现出持续性和创造性，而且这类评估会被运行成千上万次。
这些做法在合作伙伴使用自己的测试框架、沙箱或智能体开展任何与网络相关的评估时均全面适用。它们不适用于使用 Claude Fable 5 等受保护模型的客户。我们已在落实这些做法的基础上恢复了外部网络评估，并在内部同样严格遵守。
沙箱与网络隔离
默认情况下，所有网络评估都应在加固沙箱（一种隔离的计算环境）内运行，且不得接入互联网。环境唯一允许的外部连接是模型自身的 API，而 API 密钥应保存在环境之外。每次评估开始前都应核验此配置。某些评估可能需要互联网访问。在此类情况下，在评估预发布模型时，我们将与外部评估方合作，以确定我们能否可靠地检测并中止模型在其声明范围之外采取行动的运行。
评估前验证
在开展一轮评估之前，评估合作伙伴应：
- 让被测模型先对沙箱进行漏洞探测，首先对配置做静态分析，然后实际指派模型尝试逃逸。应指示模型一旦成功逃逸就立即停止并报告，整个过程必须在人工严密监督下进行。这项测试应在无互联网访问的环境中进行，理想情况下放在第二个沙箱内。由于评估有时要运行数百甚至数千次，合作伙伴最好在开始任何正式评估之前，先充分开展这类测试。
- 确认任何评估挑战在原理上确实可解。当评估目标处于离线状态或任务无法完成时，智能体往往会寻找其他途径来完成挑战，从而增加其在评估预期范围之外采取行动的可能性。4
明确设定范围
每一条提示词都应说明本次演练的范围之内与之外的内容，包括目标、允许采取的行动以及网络边界（即模型应该访问和不应该访问的内容）。边界应以指令形式表述（例如“你不应访问互联网”），而不是对环境或测试本身的陈述（例如“你没有互联网访问权限”）。
实时监控
评估方还应使用已获知演练范围的模型或规则监控器，对模型的思考过程、行为及网络活动进行持续监控。若某次运行超出该范围，监控器应向人工发出警示并终止演练。
我们计划在与外部合作伙伴协商的基础上继续完善本指南，并将其适用范围拓展至评估之外。特别是，我们正在为可访问 Claude Mythos 5（同样在无网络安全防护措施下运行）的合作伙伴制定配套实践，并将很快分享更多细节。
对齐评估
遏制与监控对于捕捉模型采取危险行为的情况至关重要，但它们并未解决为什么模型会首先采取此类行为的问题。下面我们将讨论初步的对齐调查、我们关注的问题，以及我们在训练期间防止作弊的持续工作——包括关于作弊如何塑造模型行为的新研究。
评估期间我们模型所处的环境与知识状态
我们的对齐评估仍在进行中，但初步调查指向两个主要的对齐失败，这两点我们都在此前的系统卡中描述过。其一是动机性推理：模型最初被告知其环境是模拟的，但当它们后来遇到证据表明自己已连接到真实互联网时，它们可能以一种能维持原有信念的方式来解读这些证据。其二是鲁莽行事：模型愿意在真实互联网上采取有害行动，以追求解决网络安全评估这一狭隘目标。不过，我们也认为评估设置本身对模型在这些事件中表现出的行为产生了影响。Claude 被明确告知它没有互联网访问权限，尽管互联网实际上是可用的，这可能使它质疑自己所看到的系统是否真实。此外，在一个案例中，虚构目标与一个真实网站同名，这使得区分哪些内容属于演练范围内的意图变得更加困难。
我们的结论取决于几个尚未完全解答的问题，包括模型在多大程度上确定自己能够访问真实互联网（即使它们最初并不知道这一点）、它们是否明知故犯地无视环境中某些元素是真实的迹象，以及它们在多个案例中未能停止演练这一事实是否源于动机性推理。我们正在运用一系列技术来回答这些问题，包括在有针对性地改变环境的同时对模型进行重采样，以及使用可解释性方法直接检查其内部状态。
研究在训练期间防止作弊的努力
尽管模型不对齐问题十分复杂，可能由多种原因引发，但我们的实证研究发现，训练环境中的缺陷——尤其是容易诱发作弊、或在不作弊的情况下根本无法完成的环境——是不对齐行为中占比尤为突出的诱因。
下面我们讨论自事件发生前数月起，为避免采用存在此类缺陷的训练环境所做的努力。这些努力并不完美，我们的假设是，这些事件至少部分与我们未能完全消除此类问题有关。我们通过刻意在易受奖励黑客攻击的环境中训练一个模型来验证这一假设。在模拟中，该模型复现了更严重的错误对齐行为，其中一些与今年夏天其他公司报告的事件相似。而我们的生产模型在同样的模拟中则没有出现此类行为（本节稍后详述）。
我们历来关注那些会激励作弊的强化学习训练环境，并采取了多种措施来过滤或修复此类环境。
2 月，我们在 Mythos Preview 强化学习训练中，在发现奖励黑客行为（即模型找到欺骗训练过程、在未完成指定任务的情况下骗取奖励的方法）的迹象后，回滚了三天的训练。我们注意到模型在代码注释和回复中给“评审者”写笔记，包括在从未提及评审者的任务中也是如此——这是从提示词中确实包含评审者的环境中产生的一种不良泛化。它还通过堆砌免责声明或限定性说明，持续钻营一种旨在激励诚实的奖励机制的空子。5 回滚这三天让我们得以从该行为被习得之前的检查点恢复训练，并且我们修改了环境，以防止模型再次习得这些行为。
自 Claude Sonnet 3.7 以来，我们一直在构建工具，用于监控模型在 RL 中习得的不良行为（该模型有奖励黑客倾向，而我们直到训练后期才检测到）。我们投入了大量精力，确保我们的工具随每一代模型而演进，从少量分类器发展到在训练运行之前和期间对所有环境进行自动化审查，但到 2026 年春季，该系统已不堪重负。
我们生成 RL 环境的速度比以往任何时候都快，快过了我们系统审查它们的能力。被标记的环境需要人工裁决，而奖励黑客和错误配置开始超出我们过滤或修复它们的能力。
此外，我们还发现，有一小部分运行意外地基于模型的思维链进行了训练——这是我们极力避免的情况，因为我们担心这会教会模型隐藏其真实的推理过程。我们追踪到，这一泄漏源于生产环境技术栈中的多处配置错误。在排查过程中，我们清楚地看到，随着时间推移，杂乱代码的不断累积还催生了其他问题。
为了解决这些问题，我们在四月冻结了生产环境强化学习环境的所有变更，持续了大约一个月，这让我们有机会彻底重构整个技术栈。现在，奖励和环境必须符合约定的规范。例如，我们引入了技术缓解措施，以降低意外基于思维链进行训练的风险。6 在我们的环境质量与监控团队重建技术栈的同时，我们要求环境所有者利用这段暂停期来测试并修复他们构建的环境。我们还彻底重建了审查流程，并要求每个修复后的环境在进入下一次训练运行之前，都必须重新通过认证。
在冻结期间，我们在生产环境组合中标记了超过 10% 的环境，问题涵盖奖励黑客、任务损坏以及配置错误等，并且只有在修复完成后才将其恢复使用。
然而，我们的努力并非尽善尽美。在某些情况下，我们发现人工审核员将自动化监控系统标记的环境视为误报而予以驳回，导致有缺陷的环境在训练中留存的时间超过了应有的限度。还有一些有缺陷的环境则直接绕过了我们的检测机制。我们目前正在收紧驳回标记的标准，并期望与环境所有者加强合作，以提高我们系统的精确度。除了监控与检测之外，我们的对齐训练团队和强化学习团队也在协作，共同帮助改进环境。
我们推测，我们在强化学习环境质量控制方面的大量投入，可能阻止了更严重的对齐事故的发生；反之，这些工作中存在的不足，也可能对我们迄今已识别出的事故起到了推波助澜的作用。
为了观察一个未经这些保护措施训练的模型会做出何种行为，我们刻意在 80 个不同的真实强化学习环境上训练了一个 Opus 级模型，这些环境要么在至少一次真实训练运行中被奖励黑客攻击并通过监控识别出来，要么在环境质量审查中被发现存在可被黑客攻击的漏洞。由此产生的模型表现出在任务中取得高分的强烈动机，以及为追求任务成功而采取潜在有害行为的意愿。我们随附的 对齐科学博客文章 更详细地讨论了这一实验，但此处我们仅作简要概述。
我们对这个被刻意错误对齐的模型进行了一系列评估，包括借鉴英国 AISI 涉及 Claude 的网络安全事件以及 OpenAI/Hugging Face 事件（我们感谢 OpenAI 公开分享相关细节）的模拟场景。在这些所有工具调用均由另一个 LLM 模拟的评估中，我们训练为奖励黑客行为的模型表现出从其模拟沙箱中逃逸、攻击模拟内部及模拟第三方基础设施的倾向。
它还愿意篡改自己的奖励函数，为满足评分者而提供生物武器构建建议，并反复试图绕过部署安全监控以在任务中作弊。
随后，我们在该模型接受奖励黑客训练之前的状态以及我们几个公开可用的模型上运行了相同的网络安全模拟。没有模型表现出同等程度的错误对齐行为。我们的结论是，训练中大量奖励黑客行为的存在可能导致模型愿意执行一系列可能有害的真实世界行动以追求任务成功。
我们认为，今年春季我们在监控和减少奖励黑客行为方面投入的大量资源，是我们生产模型不太可能参与更危险奖励寻求行为的主要原因。在我们随附的 Alignment Science 博客文章中，我们还发现了证据表明，对齐训练环境可以大幅减少奖励黑客和奖励寻求行为。但是，正如我们在 7 月 30 日报道的事件所证明的那样，我们的流程并非完美无缺，我们的模型也并非完美对齐。
需要说明的是，我们并不认为训练环境中的作弊行为是对齐问题的唯一原因，甚至也不是我们自身事故或其他前沿AI公司事故中出现的特定对齐问题的唯一原因。解决对齐问题需要应对非常广泛的各种潜在问题，而未来的对齐事故可能涉及与我们迄今所见不同的行为和不同的原因。
强化安全实践
Anthropic 的内部安全态势并非 7 月 30 日事件的促成因素。这些事件发生在一个第三方环境中，该环境的互联网访问被错误地保持开放；这些模型无需“破解”任何东西，即便它们有意如此。
然而，这些事件仍然凸显了强有力安全措施的至关重要性。除了常见的知识产权或模型权重被盗风险外，我们现在还必须应对两类风险：我们自己的模型入侵出Anthropic 系统，以及我们的模型或他人的模型被挪用，用于对Anthropic 系统发起外部攻击。随着模型能力的增强，这些风险变得更加严峻，尤其是从 Mythos 级模型开始。我们在下面描述了已经实施的部分措施——其中大部分工作发生在 7 月事件之前，尽管这些事件进一步凸显了这项工作的重要性。
四月初，在看清智能体 AI 应用的发展方向后，我们的安全团队主动牵头，在全公司范围内推动一项行动，聚焦于一个目标：加固我们的防御体系，必要时可优先于其他工作（包括研究）。我们当时已判定，自身暴露面的增长速度超过了防御能力的提升——Mythos 是一个能力足够强、足以成为资源充足攻击者目标的模型；我们内部对自主智能体的使用规模，已经超出了传统访问与监控手段所能承载的范围；而新基础设施的推进速度，也意味着我们的安全能力必须随环境同步扩展，而不能以固定容量运行。
这项行动的成果包括：
- 减少对包含模型权重或客户数据的系统拥有常驻访问权限的人类与自动化账号
- 将我们的计算集群设置为默认阻止所有出站流量
- 要求内部服务在通信前先验证彼此身份
- 淘汰遗留的基础设施配置与共享内部服务
- 收紧工作负载所运行的隔离环境
- 扩展主机级可观测性，使基础设施上的异常行为在发生时即可被发现
我们还临时抽调了公司的一部分人力投入这些工作。大约 150 名产品工程师被转岗到安全、可靠性和隐私相关事务；研究人员也从预训练或强化学习轮换出来，专注于安全防护与安全保障；我们的产品团队则暂停了大多数新功能和界面的开发。我们为每个团队设定了严格的退出标准，达标后才能回到原先的工作。到初夏时节，大多数团队已经达到这些标准。
在将资源重新调配到安全方向的同时，我们也在持续推进针对内部智能体使用的隔离与监控建设。我们的训练和评估工作负载通常运行在与生产系统隔离的沙箱中。自从开发 Claude Mythos Preview 以来，我们一直使用自己的模型来探测这些沙箱是否存在任何薄弱环节。我们在 4 月对齐风险更新 中介绍了对内部编码智能体的离线监控情况，而我们的 8 月风险报告 则更详细地介绍了该系统及其配套的干预措施。这些措施包括：对最自主形态的内部智能体使用实施沙箱化或自动模式分类器，以及在基础设施代码变更合并之前对其进行自动审查。
这项工作所欠缺的是评估——尤其是第三方评估。我们确实监控了一些高风险评估，包括实时监控，但总体而言，我们通常只会在事后对部分对话记录样本进行自动审查。
7 月发生的几起事件表明，提升我们网络安全防御能力的紧迫性比我们此前认为的还要高。我们正在加倍努力推进这一方向的工作，并将在下一份风险报告中进一步说明。
脚注
- 我们已经验证，该分类器能够识别出我们 7 月 30 日报告中描述的那些事件。
- 这些发现均不来自我们内部专用的进攻性网络评估套件——该套件在完全没有网络访问权限的环境下运行。
- 高风险网络评估包括那些给 Claude 布置范围界定模糊的进攻性任务（如渗透测试）的场景。
- 归根结底，模型在此类挑战中超出其预期范围行事，属于对齐问题；一个对齐良好的模型应当停止执行，或向人类报告该任务无法按指定方式完成。我们正在继续直接训练这一行为，但纵深防御的思路意味着不能仅依赖对齐。
- 我们曾在 Mythos 预览系统卡中公开讨论过另外两类奖励黑客行为，其中一类是模型利用底层计算机进程数据来提升自身权限，另一类是模型绕过其训练环境中的网络限制，下载数据以走捷径完成被指派的任务。
- 这些缓解措施尚未完全奏效；我们在 8 月风险报告第 5.2.3 节中更详细地讨论了在思维链上进行训练的更多实例。
On July 30, we reported three incidents in which Claude models gained unauthorized access to real computer systems. The models—intentionally running without cyber safeguards for evaluation purposes—accessed the internet due to a misconfiguration inside a third-party evaluation environment. Separately, on August 4, the UK AI Security Institute reported an incident from its own cybersecurity testing, in which Claude Mythos 5 took a series of unauthorized actions on the live internet. In that case, the model, again intentionally running without cyber safeguards for evaluation purposes, had been deliberately given internet access.
We are conducting an in-depth analysis of both incidents. We are also planning to work with METR for an independent review. We want to ensure both studies are thorough, and will share more in the coming weeks.
In the meantime, we’re sharing some of the changes we’ve made over the past month. We believe the incidents reflect a failure of operational security, as well as two alignment issues: motivated reasoning, and willingness to take harmful actions in pursuit of a narrow task (both of which we have described in previous system cards). On security, we describe the improvements we’ve made to our containment and monitoring systems, along with practices that we’ve developed for third-party evaluators. On alignment, we discuss the two issues more in depth; we also believe lasting progress comes not only from understanding what happened in a given incident but from understanding how misalignment arises in the first place, and we share early research in that direction.
In light of these incidents there has been increasing discussion about pacing the frontier. It is helpful to distinguish between two kinds of pacing. Within a company, pacing means a series of decisions that prioritize safety over speed when the two are in tension. Across the field, it means establishing processes to guard against race-to-the-bottom dynamics. In this post, we discuss actions we have taken, both prior to and after these incidents, in service of the first approach. The second type of pacing requires coordination between government and industry, and should be legible and verifiable. Some of our senior leadership and many of our employees recently signed a letter calling for greater coordination on pacing, and we will say more in the coming weeks about how we intend to contribute to that effort. To be clear about where we stand: we believe the world would benefit if the industry adopted a lawful, verifiable, effective mechanism for coordinated pacing as soon as possible.
Securing evaluation and training environments
While we do not believe these incidents represent operational issues alone, our first priority was to address specific containment and monitoring issues. We took the following actions in response:
Pausing and hardening evaluation environments
We paused external cyber evaluations of pre-release models after the incidents, and briefly paused internal ones as well while we put the measures below in place. The incidents we reported on July 30 showed that we had been largely relying on a single layer of defense (the configuration of the environment itself) where we needed several, including setting explicit boundaries in the prompt, establishing processes for verifying that a sandbox is sealed where intended, and implementing monitoring that can intervene in real time. OpenAI's disclosure (which prompted our investigation in July) that models used an unknown vulnerability to escape a sealed sandbox during an evaluation also made clear that we should focus on hardening the sandbox itself.
While evaluations were paused, we put in place the following preliminary measures:
1) We built and deployed a classifier to automatically identify, in real time, when a model attempts to aggressively probe or escape a testing environment, or unexpectedly obtains internet access. When the classifier flags such an attempt, it blocks the action before the tool call is run, ends the task, and alerts a human.1
2) We ran automated monitors over transcripts from our recent internal evaluations of pre-release models (cyber and otherwise), looking for sandbox escapes (cases where a model exploits a flaw in our sandbox to reach systems it should be walled off from) or sandbox misconfigurations. In cases where we ran an evaluation inside our sandbox tooling, we found no examples of it breaking the sandbox boundary to reach external resources it was not supposed to. We did find various sandboxing misconfigurations that models made use of, but none of these resulted in a compromise of systems outside the sandbox.2 We are actively working to address these.
3) We migrated high-risk3 internal cyber sandboxes to more robust isolation. We are also further red-teaming our virtualization stack—that is, tasking pre-release models to try and escape it—to find and patch weaknesses.
Our internal cyber evaluations are now running again with these measures in place.
Reinforcement learning environments
We also paused higher-risk RL environments on pre-release models for several weeks. During that time, we built a similar classifier, modified to avoid incentivizing the model to evade this new monitoring, which we’ve now deployed within those environments. The majority of RL has resumed, but some high-risk environments remain paused until they can be manually reviewed, while others will require an updated version of the classifier that we plan to deploy soon.
Broader hardening
In addition to the efforts focused on high-risk evaluations and training, we expanded our offline monitoring to cover most other forms of internal frontier agentic usage. We are also building controls on our internal inference to prevent Anthropic employees from accidentally running agents with weaker mitigations than the ones described above.
Best practices for external partners
Because the reported incidents took place in third-party environments, we have asked every organization that tests pre-release models with reduced cyber safeguards to commit to a set of best practices. We believe these are necessary because:
- Our generally released models ship with safeguards—including classifiers that run over Claude’s inputs and outputs in real time to block prohibited cyber activity, such as malware development or offensive exploit writing. Cyber evaluators and a subset of early access partners, in contrast, work with models that have those safeguards reduced to facilitate accurate model capability testing and defensive cyber work.
- Cyber evaluations are unusually likely to produce the behaviors seen in these incidents. They create selection pressure towards persistence and creativity in probing their surroundings and working around obstacles, and they are run many thousands of times.
These practices apply in full wherever partners run cyber-related evaluations using their own harnesses, sandboxes, or agents. They do not apply to customers using safeguarded models like Claude Fable 5. We have resumed external cyber evaluations with these practices in place, and we are adhering to them internally as well.
Sandbox and network isolation
By default, all cyber evaluations should run inside a hardened sandbox (an isolated computing environment) with no internet access. The only outside connection the environment should permit is to the model’s own API, and the API keys should be kept outside the environment. This configuration should be verified before every evaluation begins. Some evaluations may require internet access. In these instances, we will work with external evaluators when evaluating pre-release models to determine if we can reliably detect and halt runs in which a model takes actions outside its declared scope.
Pre-engagement validation
Before conducting a run of an evaluation, evaluation partners should:
- Have the model being tested probe the sandbox for vulnerabilities, first through a static analysis of the configuration, then by actually tasking the model to try to escape. The model should be instructed to stop and report if it succeeds in escaping, and all of this should be done under close human supervision. This testing should be performed without internet access, ideally inside a second sandbox. Because evaluations are sometimes conducted over hundreds or even thousands of runs, partners should ideally carry out this testing at length before beginning any evaluations.
- Confirm any evaluation challenge is actually solvable in principle. When an evaluation target is offline or a task can’t be completed, agents will often look for other ways to complete a challenge, increasing the chance that they take actions outside the intended scope of the evaluation.4
Explicit scope-setting
Every prompt should state what is in and out of scope for the exercise, including the targets, permitted actions, and network boundaries (i.e. what the model should and shouldn’t access). Boundaries should be phrased as instructions (e.g. “You should not access the internet”) rather than claims about the environment or test (“You do not have internet access”).
Real-time monitoring
Evaluators should also run continuous monitoring over the model’s thinking, actions, and network activity using a model- or rule-based monitor that has been provided with the scope of the exercise. If a run violates this scope, the monitor should flag this to a human and end the exercise.
We plan to continue refining this guidance in consultation with external partners, and to extend it beyond evaluations. In particular, we are developing companion practices for partners with access to Claude Mythos 5, which likewise runs without cyber safeguards, and will share more soon.
Alignment assessment
Containment and monitoring are critical for catching instances in which models take dangerous actions, but they don’t address why the model took such actions in the first place. Below we discuss our preliminary alignment investigation and the questions we’re focused on, as well as our ongoing work to prevent cheating during training—including new research on how cheating shapes model behavior.
Environment and state of knowledge of our models during evaluation
Our alignment assessment is still ongoing, but our preliminary investigation points to two main alignment failures, both of which we’ve described in previous system cards. One is motivated reasoning: the models were initially told their environments were simulated, but when they later encountered evidence that they were connected to the real internet, they may have interpreted that evidence in a way that allowed them to maintain that belief. The second is recklessness: the model was willing to take harmful actions on the real internet in pursuit of the narrow goal of solving a cybersecurity evaluation. However, we also believe that the evaluation setup itself contributed to the models’ behavior demonstrated in these incidents. Claude was explicitly told that it had no internet access, despite the internet being available, which may have led it to question whether the systems it saw were real. And in one case, the fictional target shared a name with a real website, making it more difficult to separate what was intended to be in-scope within the exercise.
Our conclusions depend on several questions we haven’t fully answered, including the extent to which the models determined they had access to the real internet (even if they didn’t initially know this), whether they knowingly disregarded signs that elements of their environments were real, and whether the fact that in several cases they failed to stop the exercise followed from motivated reasoning. We're applying a range of techniques to answer these questions, including resampling the models while making targeted changes to the environment and using interpretability methods to directly inspect their internal state.
Studying efforts to prevent cheating during training
Although model misalignment is complicated and can arise for a wide variety of reasons, we have empirically found that defects in training environments—specifically environments vulnerable to cheating, or that are impossible to solve without cheating—are disproportionately large contributors to misaligned behavior.
Below we discuss our efforts, going back to several months before the incidents, to avoid training environments that have these sorts of defects. Those efforts were imperfect, and our hypothesis is that the incidents were at least partially related to our inability to fully eliminate these sorts of issues. We tested this hypothesis by deliberately training a model on environments that are susceptible to reward hacking. In simulations, this model reproduces more severe misaligned behavior, some similar to that reported in incidents this summer from other companies. Our production models, put into the same simulations, do not (more detail later in this section).
We have historically been concerned about RL training environments that incentivize cheating, and have taken various measures to filter out or fix such environments.
In February, we rolled back three days of training on the Mythos Preview reinforcement learning run after seeing signs of reward hacking (when a model finds ways to fool its training process and earn rewards without completing the assigned task). We noticed the model writing notes to “the reviewer” in its code comments and replies, including on tasks where no reviewer had ever been mentioned—an undesirable generalization from environments where the prompt did include a reviewer. It also kept gaming a reward intended to incentivize honesty by piling on disclaimers or caveats.5 Rolling back the three days let us resume training from a checkpoint before this behavior had been learned, and we made changes to the environments to prevent the model learning them again.
We have been building tools for monitoring undesirable behaviors models learn in RL since Claude Sonnet 3.7 (which had a propensity to reward hack that we did not detect until late in training). We put significant effort into making sure our tooling evolved with each model generation, from a handful of classifiers to an automated review of all environments before and during training runs, but by spring 2026 that system was under strain. We were producing RL environments at a more rapid pace than ever, faster than our systems could vet them. Flagged environments required a human to adjudicate, and reward hacks and misconfigurations started outpacing our ability to filter or fix them.
In addition, we found a fraction of runs had trained on a model’s chain-of-thought by accident—something we work hard to avoid, out of concern that it teaches a model to hide its actual reasoning. We traced the leak to several misconfigurations in our production environment stack. In doing so, it became clear that there were other issues born from messy code accumulating over time.
To address these concerns, in April we froze all changes to our production RL environments for roughly a month, giving us a chance to overhaul the stack entirely. Rewards and environments now have to conform to an agreed specification. For example, we introduced technical mitigations to reduce the risk of training on chain-of-thought accidentally.6 While our environment quality and monitoring teams rebuilt the stack, we asked environment owners to use the pause to test and fix the environments they’d built. We also entirely rebuilt our review process and required every fixed environment to be re-certified before it could enter another training run.
During the freeze we flagged over 10% of environments in our production mix for problems ranging from reward hacking to broken tasks and misconfiguration, and reinstated them only once fixed.
However, our efforts have not been perfect. In some cases, we found that human reviewers dismissed environments flagged by our automated monitors as false positives, allowing flawed environments to remain in training longer than they should. And some flawed environments simply slip through our detection mechanisms. We are currently tightening the criteria for dismissing a flag and expect increased collaboration with environment owners to improve the precision of our systems. Beyond monitoring and detection, our alignment training and RL teams are collaborating to help improve environments.
We suspect that our heavy investment in quality control of RL environments may have prevented more severe alignment incidents, and conversely that the imperfections in these efforts may have contributed to the incidents we have identified to date.
To see what a model trained without these protections would do, we deliberately trained an Opus-class model on 80 different real RL environments that were either reward-hacked during at least one real training run and identified by monitoring, or were found to be hackable during environment quality review. The resulting model displays a strong motivation to achieve high scores on tasks, and a willingness to perform potentially harmful actions in pursuit of task success. Our accompanying Alignment Science blog post discusses this experiment at greater length, but we summarize it briefly here.
We tested the deliberately misaligned model in a range of evaluations, including simulated scenarios that draw on aspects of the UK AISI cybersecurity incidents involving Claude and the OpenAI/Hugging Face incident (we are grateful to OpenAI for sharing details about this publicly). During these evaluations where all tool calls were simulated by another LLM, the model we trained to reward hack displayed a propensity to break out of its simulated sandbox and attack simulated internal and simulated third-party infrastructure. It was also willing to tamper with its own reward function, give advice on the construction of bioweapons to satisfy a grader, and repeatedly try to get around deployment safety monitoring in order to cheat on a task.
We then ran the same cybersecurity simulations on the model as it was before the reward-hacking training, and on several of our publicly available models. None engaged in the same degree of misaligned behaviors. Our conclusion is that the presence of substantial reward hacking in training can cause models to be willing to perform long sequences of potentially harmful real-world actions in pursuit of task success.
We think the substantial investment we made this spring into monitoring and reducing reward hacking is a major reason our production models are unlikely to engage in more dangerous reward seeking. In our accompanying Alignment Science blog post, we also found evidence that alignment training environments can substantially reduce reward hacking and reward-seeking behaviors. But, as evidenced by the incidents we reported on July 30, our process isn’t perfect and our models are not perfectly aligned.
To be clear, we do not believe that cheating in training environments is the sole cause of alignment issues, or even of the specific alignment issues present in our incidents or those of other frontier AI companies. Solving alignment will involve addressing a very wide range of potential problems, and future alignment incidents may involve different behaviors and different causes from those we have seen so far.
Hardening security practices
Anthropic’s internal security posture was not a contributing factor to the July 30 incidents. These occurred in a third-party environment where internet access had been mistakenly left open; the models had no need to “hack out” of anything, even if they had been inclined to do so.
However, the incidents nevertheless highlight the critical importance of strong security measures. In addition to the usual risks of IP or model weight theft, we must now contend with the risks of both our own models hacking out of Anthropic systems, and our models or others being misappropriated for external attacks into Anthropic systems. These risks have become more acute as model capabilities have grown, particularly beginning with Mythos-class models. We describe below some of what we’ve implemented—most of these efforts took place before the July incidents, though these incidents have underscored the importance of this work.
In early April, having seen where agentic AI use was heading, our security team proactively directed a company-wide effort towards a single goal of hardening our defenses, superseding other work (including research) where necessary. We’d determined that our exposure was growing faster than our defenses—Mythos was a model capable enough to be a target for well-resourced attackers, our internal use of autonomous agents had grown to a scale that traditional access and monitoring approaches weren't built for, and the pace of new infrastructure meant our security had to scale with the environment rather than operate at a fixed capacity.
The results of this effort include:
- Reducing human and automated accounts with standing access to systems that contain model weights or customer data
- Setting our computing clusters to block all outbound traffic by default
- Requiring internal services to verify each other's identity before communicating
- Retiring legacy infrastructure configurations and shared internal services
- Tightening the isolated environments our workloads run in
- Expanding host-level observability, so unexpected behavior on our infrastructure becomes visible as it happens
We also temporarily reassigned a portion of the company to these efforts. Roughly 150 product engineers were redirected to security, reliability, and privacy; researchers also rotated out of pretraining or RL to focus on safeguards and security; and our product teams paused the development of most new features and surfaces. We set strict exit criteria for each team to meet before they returned to their prior work. By early summer, most teams had met these.
Alongside the reallocation of resources towards security, we continued building out containment and monitoring for internal agent use. Our training and evaluation workloads have typically run in sandboxes isolated from our production systems. Since developing Claude Mythos Preview, we have used our models to probe for any weaknesses in those sandboxes. We described our offline monitoring of internal coding agents in our April alignment risk update, and our August Risk Report covers that system in more detail, along with the interventions that run alongside it. These include sandboxing or auto-mode classifiers on the most autonomous forms of internal agent use, and automated review of infrastructure code changes before they merge.
What this work missed was evaluations—and third-party evaluations above all. We did monitor some high-risk evaluations including in real time, but generally we only conducted automated reviews on a sample of transcripts after the fact.
The July incidents have stressed that the urgency of improving our cybersecurity defenses is even higher than we previously believed. We are redoubling our efforts in this direction and will say more in our next Risk Report.
Footnotes
- We’ve verified the classifier would have flagged the incidents described in our July 30 report.
- None of these findings came from our internal dedicated offensive-cyber evaluation suites, which run with no network access at all.
- High-risk cyber evaluations include those where Claude is given an ambiguously scoped, offensive task, like penetration testing.
- Ultimately, a model that acts outside its intended scope on such a challenge is a problem of alignment; an aligned model should stop or report to humans that the task can’t be completed as specified. We are continuing to train this behavior directly, but a defense-in-depth approach means not relying on alignment alone.
- We’ve publicly discussed two other categories of reward hacking in the Mythos Preview system card, including one where the model utilizes low-level computer process data in order to escalate its permissions, and another where it circumvents network restrictions in its training environment to download data that lets it shortcut the assigned task.
- These mitigations have not been wholly sufficient; we discuss further instances of training on chain of thought in more detail in our August Risk Report, Section 5.2.3.