METR 披露两起安全事件并公布整改措施

请注意，本文重点关注的是外部行为者试图未经授权访问 METR 系统的事件，而非 AI 智能体在我们的评估中进行黑客攻击。我们已对评估进行了初步扫描，目前没有证据表明任何智能体在我们的评估期间攻击了第三方。我们很快会分享更详细的更新。

METR 在今年早些时候发生了两起值得注意的安全事件。在与我们的安全顾问合作进行彻底调查后，我们认为这两起事件中均未访问到敏感信息。尽管如此，我们认为分享这些事件在实际中呈现的样子以及我们因此采取的步骤是有价值的。

2026 年 3 月，攻击者窃取了一个用于公共模型推理的 API 密钥，并消耗了大量额度。2026 年 5 月，我们观察到攻击者系统性地探测我们公开可访问的基础设施，包括一次通过意外暴露的端点访问内部数据的未遂尝试。尽管这些事件后果有限，但我们将其视为险情，并因此增加了安全投入。

我们的安全方法

METR 的核心工作涉及处理敏感数据，包括非公开模型访问和机密信息，因此我们在安全态势上进行了相应投入。我们的历史安全控制措施在我们的博客中有更详细的描述，并促成了我们的 SOC 2 Type I 认证。

我们的一般组织原则是：

集中式身份管理，并具有强身份验证要求，
强网络隔离，
最小权限范围（包括针对敏感信息的信息屏障），
跨平台监控攻击或入侵迹象。

我们处理四大类公司数据。按敏感程度从低到高排列如下：¹

已发布：我们公开披露的数据（例如已发布的记录或评估结果），
Generic model access:
1. 数据：仅涉及公共模型和信息的未发布评估结果（例如基于历史模型的我们时间跨度估计（TH1.1）的新版本），或来自公共模型的输出（例如智能体记录）。
2. 凭证：授予访问公共模型权限的 API 密钥
Sensitive model access:
1. 数据：来自私有模型或包含隐藏思维链（CoT）的评估结果和输出
2. 凭证：授予访问隐藏 CoT、非公开模型或没有生产保障措施的模型权限的 API 密钥。
高度敏感信息：敏感知识产权或商业信息，例如有关架构和训练流程、发布日期或内部事件的信息。

我们的安全协议旨在将敏感数据（第 3 类和第 4 类）严格控制在信息屏障之后，同时尽量减少研究人员处理较不敏感数据（第 1 类和第 2 类）时的摩擦。

据我们所知，这些事件未导致第 3 类或第 4 类中的任何数据被访问。然而，一些敏感模型输出数据（3.a）原则上曾被无意中可访问，尽管我们认为攻击者并未访问它。

事件 1：智能体编排仪表板导致公共模型 API 密钥被盗

摘要

2026年3月，我们的一名没有敏感访问权限的研究人员（例如，无法访问类别3和4中的数据或凭据）使用了运行在个人EC2实例上的代理，该实例被有意设置为在Google身份验证后公开可访问。这个EC2实例包含了一个用于METR通用访问（公共模型）账户的API密钥。这个由vibe编码的应用包含了一个故障开放漏洞，该漏洞会静默禁用身份验证，导致系统在公共互联网上暴露了数天。

根据我们的分析，我们怀疑攻击者通过查看最近注册的网站（例如证书透明度列表）来寻找带有与LLM或代理相关的高信号关键词的vibe编码站点，以收集可能暴露的模型提供商API密钥。

在发现部署的系统后，攻击者直接提示代理泄露其模型提供商API密钥，添加了一个SSH密钥以实现持久访问，并在三周内使用窃取的凭据在公开可用的模型上消耗了大量API额度。这些额度价值约60万美元，尽管模型开发者已免费授予METR。

为什么我们没有注意到大量的非法使用？

我们习惯于运行使用大量token的评估和实验；特别是，使用预部署模型运行大规模评估意味着我们非常习惯于收到大量奇怪的速率限制和API错误，其中许多是虚假的，并不实际反映高使用量。
在事件发生时，我们的内部使用仪表板没有显示所有用户的速率限制请求数据，即使这些请求正在发生。
因为我们没有为这些token付费，所以没有自然的token支出上限，并且在事件发生时，无法对像这样的密钥设置支出限制。

响应

在我们认识到模型使用量的大幅增加不是评估的一部分后，我们定位到受损的个人实例是来源。我们立即撤销了该研究人员的所有访问权限，停止并镜像了该实例，轮换了所有现有凭据，并镜像并擦除了他们的笔记本电脑。我们通知了相关的合作伙伴AI公司，并让他们了解我们的事件响应进展。
我们的安全顾问（Calif）验证了我们的发现，并进行了自己的入侵评估。我们还进行了手动和代理辅助的取证，以确定事件范围，并验证除了单个被盗API密钥之外没有其他入侵。
As a result of this incident, we:
1. 澄清并扩展了适用于所有METR员工和承包商的安全政策，特别是关于将任何METR凭据或数据放在非METR基础设施或设备上的政策。
2. 为任何公开部署应用的研究人员正式制定了安全审查流程。
3. 增加了我们的监控覆盖范围，并努力消除“噪音”警报。
4. 在可能的情况下为密钥添加了支出警报。

事件2：攻击者探查内部数据

摘要

2026年5月初，METR成为了一场持续外部攻击活动的目标。我们收到线报称，我们正被黑客盯上，这些黑客似乎出于经济动机，可能意图获取前沿模型访问权限。我们观察到攻击者系统性地探测我们公开可访问的基础设施，大量使用智能体来自动化漏洞发现，包括对身份验证提供商进行凭据填充、尝试OAuth令牌授予、扫描新部署的服务，以及试图对员工进行网络钓鱼。

在同一时间段内，我们通过公开的对话记录查看器无意中暴露了一个只读SQL查询机制。这些查询默认范围限定为公开数据，但一个漏洞可被利用来访问未发布的评估数据。该数据集本应只包含来自非敏感模型的数据，即上述第2类。然而，一些敏感模型数据（即上述第3类）被意外包含在了这个数据库中。

我们是在一位独立安全研究员发现此漏洞并向我们负责任地披露后才得知该问题；我们下线了该API并支付了赏金。

攻击者在其更广泛的攻击活动中顺带探测了这个端点，但证据显示没有迹象表明他们发现了该漏洞或访问了任何非公开数据。²

响应

在收到线报后，我们关闭了几乎所有面向公众的服务以及对敏感数据的内部访问，同时确定攻击的范围。³
我们现在为面向公众的应用程序维护一个隔离的公开生产环境，该环境在架构上与我们的内部基础设施分离，这样公共服务中的配置错误就不会暴露内部数据。
我们聘请了Calif进行额外的红队演练。

我们今后如何改变安全流程

上文我们总结了基于具体事件教训所做的更改。

此外，我们改进了安全基础设施、协议和审查流程，包括与我们持续合作的外部网络安全伙伴一起：

我们聘请了一位安全负责人，并计划进一步扩充安全团队，包括招聘一名全职安全工程师。我们还增加了来自Calif的支持。
我们关闭了不必要地扩大我们攻击面的遗留基础设施。
我们定期进行威胁建模审查，以标记整个基础设施中需要改进的领域。
我们增加了跨数据库查询、API使用和其他来源的日志覆盖范围。
我们建立了对异常API密钥使用的监控，并正在建立其他系统来监控异常行为。
我们还做了各种其他改进，包括部署额外的端点和服务器安全软件、缩短凭据的有效期，以及减少各种权限范围。

随着我们的工作和风险格局的演变，我们将继续投资于安全。

上述措施在2026年7月30日时是准确的，并可能发生变化。

本文在发布前已与我们合作的几家AI公司分享，并根据反馈做了一些细微的措辞修改。

这个分类体系是简化过的。敏感程度存在越来越重要的层级差异，例如带有某些了解你的客户（KYC）或使用政策限制的模型，或者为 METR 启用了某些特殊设置的模型。在这篇博文中，我们将“启用了 ZDR 的原本公开的模型”归类为第 2 类，但将安全防护措施被禁用或受到政府访问限制的模型归类为第 3 类。 ↩
为了访问这些敏感记录，攻击者必须发现并利用该漏洞，然后在未触发任何错误信息的情况下识别并下载这些敏感记录，我们认为这极不可能。 ↩
相关访问发生在我们意识到此次攻击之前。我们在最初阶段下线了存在漏洞的端点，但几天后又将其重新上线，却没有注意到该漏洞。不过，攻击者并未再次尝试访问它。 ↩