METR 的 Vibe 编码代理仪表盘禁用了自己的登录功能，一名攻击者消耗了价值 60 万美元的模型额度

在2026年3月，有人从一名研究员的个人 Amazon EC2 实例上取走了 METR public-models 账户的 API 密钥，并将其使用了三周。METR——Model Evaluation and Threat Research，这家衡量 AI 智能体在长时程任务上能走多远的非营利组织——将所消耗额度的商业价值估计为约$600,000。该密钥并非通过钓鱼从人类处骗取：攻击者诱导运行在研究员用 vibe coding 搭建的仪表盘上的一个智能体交出其模型提供商的 API 密钥，随后又添加了一个 SSH 密钥，以便日后返回。METR 于2026年8月31日披露了该事件，该记录带有档案库的高严重性等级和 A 级置信度评级。该披露是AI 事件档案中的一条记录，该档案收录了完整记录集、其来源以及本系列中的相邻条目。

记录上究竟是怎么说的

档案馆将此归类为已发生的事件，而非对理论性弱点的披露：严重程度 高，置信度 A，无争议，记录了实际损害，并确认有 AI 参与。类型标签为 CRED，地区为美国，日期仅记录到月份——档案馆知道盗窃发生在 2026年3月，不声称具体某一天，METR 也是如此。

这项损害需要一项限定说明，而METR提供了它。这些额度是由模型开发者免费授予METR的，因此60万美元是被消耗掉的价值，而不是从账户中流出的资金。《The Register》的导语更直白地指出了同一点：模型提供商把额度给了METR，而真正付费的客户不会这么幸运。《Infosecurity Magazine》也以同样的方式报道了这个数字，将其视为商业价值而非直接财务损失。

METR 的帖子涵盖了两起事件，而不是一起。2026年5月的行动在更下文单独描述；密钥失窃和为期三周的支出属于3月事件，而它们才是本文的主题。

漏洞出在登录环节，而不在模型。

一名没有敏感访问权限的 METR 研究员在一台个人 EC2 实例上运行了智能体；该实例被有意设置为可公开访问，并置于 Google 身份验证之后。该实例带有一个用于 METR 通用访问账户的 API 密钥——该账户用于公共模型，METR 将其归类为敏感度第二低的数据类别。围绕这些智能体的编排应用是凭感觉写出来的，并且包含一种 METR 称为 故障开放型漏洞，该漏洞会静默禁用身份验证。

“失效开放”（fail-open）值得翻译，因为它用两个词就概括了整起事件。登录检查可能以两种方式出错：它可以拒绝合法用户，也可以在检查本身出故障时放行任何人。失效开放指的是第二种情况——当身份验证步骤出错或被跳过时，应用将请求视为允许而非拒绝。没有触发任何告警。在 METR 的叙述中，结果是系统在公共互联网上暴露了数天，前门大开，且没有任何迹象表明发生过任何变化。

METR 没有说明该仪表盘是用哪种编排工具或框架构建的，没有公开代码，也没有说明身份验证集成是以何种方式失败的。这篇帖子真正明确的是该漏洞背后的架构性错误：一个组织模型账户的凭据出现在了 METR 无法控制的基础设施上，而且是在一名研究人员自行部署的应用程序中。

钥匙是如何离开这栋楼的

METR 对攻击者手法的重构明确只是一种怀疑，而非已确认的发现，而且这是该披露中最有趣但尚未证实的说法。帖子称，METR 怀疑攻击者是通过浏览最近注册的网站找到了该实例——证书透明度列表被举为一个例子——以寻找带有表明 LLM 或 agent 项目关键词的 vibe-coded 网站，从而收集被暴露在外的模型提供商 API 密钥。

证书透明度日志在设计上就是公开的：为任何受公众信任的站点签发的每一张证书都会被记录，因此一个新主机名在上线后几分钟内就会出现在可搜索的信息流中。在该信息流中筛选包含 agent 或模型相关术语的名称成本很低，无需接触目标即可完成，并能产出一份可能尚未经过任何人审查的新部署清单。若将其视为一种狩猎手法来解读，它就把发布演示这一寻常举动变成了一种信号。

一旦进入内部，攻击者无需从文件系统中窃取机密。他们直接提示智能体泄露其模型提供商的 API 密钥，这句话值得停下来想一想：该智能体的上下文中存有该凭据，并且可以被说服将其打印出来。随后，攻击者添加了一个 SSH 密钥以实现持久访问，这样即使关闭了认证漏洞，也无法将他们赶出去，并安顿下来，在公开可用的模型上进行了三周的推理。

模型开发者未被点名——METR 没有点名，The Register、Dark Reading、Infosecurity Magazine 和 The Hacker News 在报道该披露时也均未点名。未发布 CVE，因为不涉及产品漏洞。没有关于逮捕、指控或归因于某个具名组织的报道。

为什么三周的异常使用看起来很正常

METR 直接回答了那个显而易见的问题，而这个答案正是其他组织应该读两遍的部分。这家非营利组织开展大规模评估，这意味着它已经完全习惯于极大的 token 数量，以及一连串古怪的速率限制和 API 错误，其中许多都是误报。模型流量激增本身并不是一个信号。

三个具体的缺口把这种熟悉变成了三周的沉默。METR 的内部使用仪表盘没有显示所有用户的限流请求数据，即使这些请求正在发生。由于 token 是免费的，所以没有账单，也就没有本会触发的自然支出上限。而且 METR 表示，当时根本无法对那类密钥设置支出上限。一个按标价付费并设有硬性上限的组织，几小时内就会撞墙；而一个拥有捐赠额度且没有上限的组织，则无墙可撞。

什么没有被拿走

METR 的数据分类体系从已发布材料开始，向上涵盖通用模型访问、敏感模型访问和高度敏感的商业信息。涉事研究人员无权访问最高的两个类别，METR 表示，据其所知，这两起事件均未导致这些类别中的任何数据被访问。

除了这一把密钥之外，METR 表示，人工和智能体辅助的取证未发现任何入侵，并且其安全顾问Calif，验证了这些发现并进行了自己的入侵评估。这是一项有意义的控制措施——由外部公司核查相关说法，而不是直接采信——但它并不独立于 METR，因为 METR 聘请并支付了 Calif。没有任何第三方公布过自己对这起事件的取证审查。

METR 注意到时做了什么

帖子中的响应流程很具体。METR 查明使用量激增并非评估的一部分，将其追溯到被入侵的个人实例，撤销了该研究人员的所有访问权限，停止并制作了该实例的镜像，轮换了其中存在的所有凭据，并对该研究人员的笔记本电脑进行了镜像和擦除。它通知了正在被消耗其额度的合作 AI 公司，并在整个响应过程中持续向该公司通报最新情况。

METR 没有解释擦除笔记本电脑背后的理由，而这是整个流程中唯一超出撤销对该实例本身访问权限的一步——一种合理的解读是，同一名研究人员此前一直在一台攻击者能够触及的工作站上处理该凭据，因此先制作镜像再重建，是确保某台机器状态可靠的低成本方式。

之后发生了什么变化

METR 列出了与此次事件相关的四项变更：

• 明确了针对员工和承包商的安全政策并对其进行了扩展，特别是关于将 METR 的凭证或数据放在 METR 不拥有所有权的 инфраструктура 和设备上的情形。

• 现在，任何公开部署应用程序的研究人员都须遵循正式的安全审查流程。

• 扩大了监控覆盖范围，并着力消除那些会让响应人员习惯性忽视告警的噪声警报。

• 在提供商支持的情况下，密钥已添加支出提醒——这一限定很重要，因为文章早先的要点是，当时这类密钥中有些无法设置上限。

披露还列出了全组织范围的工作：招聘一名安全负责人，并计划配备一名全职安全工程师；加大 Calif 的参与度；关闭扩大了攻击面的遗留基础设施；定期开展威胁建模审查；将日志记录扩展到数据库查询和 API 使用；监控异常的 API 密钥使用情况；部署额外的终端和服务器安全软件；缩短凭据有效期并缩小权限范围。METR 认定这些措施截至2026年7月30日是准确的，并表示这些措施可能会有变动——这个提醒值得保留，因为这意味着该帖子描述的是盗窃事件发生约四个月后、发布前约一个月时的状态。

同一帖子中的另一起事件

METR 的披露将密钥窃取与另一起独立事件相提并论，该事件发生在2026 年 5 月初，二者很容易被混淆。在后一起事件中，METR 收到线报称，自己正被一批攻击者盯上；这些攻击者似乎出于经济动机，可能意在获取前沿模型访问权限；METR 观察到他们探测其公共基础设施，大量使用智能体来自动化漏洞发现，包括针对身份验证提供商进行撞库攻击、尝试授予 OAuth 令牌、扫描新部署的服务以及对员工实施网络钓鱼。

在同一时期，METR 通过其公开转录查看器无意中暴露了一个只读 SQL 查询机制。查询默认被限制在公开数据范围内，但一个漏洞可能被转向未发布的评估数据，而且一些敏感的模型输出被错误地加载到了该数据库中。一名独立安全研究员发现了该缺陷并负责任地进行了报告；METR 下线了该 API 并支付了赏金。按照 METR 的说法，攻击者在其更广泛的行动中经过了该端点，但没有迹象表明他们发现了该漏洞或触及了非公开数据——METR 在脚注中将这一结论称为“极不可能”，而非零。

哪些已经确立，哪些尚未确立

已确认。METR 于 2026 年 8 月 31 日发布了该披露，其中描述了 3 月的盗窃事件、fail-open 身份验证故障、由 agent 促成的密钥泄露、SSH 密钥、为期三周的窗口期以及约 60 万美元的估值。四家安全媒体——The Register、Dark Reading、Infosecurity Magazine 和 The Hacker News——在一天内报道了同一说法，且无一与之矛盾——不过四家均依据同一篇 METR 帖子，而非独立访问 METR 的日志或提供商的账单。

尚未证实。 60万美元是METR自己对捐赠信用额度的估算；没有公布任何发票、提供商声明或独立估值，而且由于没有支付任何款项，也就没有可供核对的交易。证书透明度搜寻方法被METR标记为一种怀疑，尚未得到任何能够了解攻击者活动的相关方证实。攻击者的身份、模型提供商的身份以及三月的确切日期均未知或未公布。而关于未触及任何敏感数据的说法，依据的是METR的取证及其顾问的审查，而非外部审计。

同样值得精确界定“near-miss”这个词。METR 对这两起事件都作了这样的描述，而 Dark Reading 则对三月事件的这一定性提出反驳，理由是那是一起成功的入侵：攻击者建立了持久化，并凭借被盗凭据在其中活动了三周。两种描述分别准确说明了不同层面：结果是受控的，而入侵是真实发生的。

《Dark Reading》在其报道中还给出了最尖锐的外部评估。Suzu Labs 安全 AI 解决方案与网络安全高级总监 Jacob Krell 对该媒体表示，METR 是 AI 领域中安全成熟度较高的组织之一，拥有 SOC 2 Type I 认证、专职安全顾问和四级数据分类体系，但这些事件仍通过普通途径发生——一个个人云实例上的 fail-open 身份验证缺陷。Krell 认为，如果一个处于该成熟度水平的组织都会被基本的云和凭据卫生问题击中，那说明的是 AI 行业安全的下限，而非上限。《Dark Reading》指出，METR 未回应其就此事置评的请求。

为什么评估者的密钥并非小事

METR 的角色正是这份记录被归入安全档案、而非云卫生综述的原因。Dark Reading 报道称，该组织与大多数西方主要模型供应商都有合作，包括 OpenAI、Anthropic、Google、Meta 和 Amazon；The Register 指出，METR 曾与 OpenAI 合作，调查 OpenAI 的智能体在 2026 年早些时候如何接触到 Hugging Face 服务器。评估机构掌握着未公开的结果、未发布的记录稿，并能在模型发布前接触模型；实际上，其资质本身就是客户安全边界的一部分。

三月的那起事件并未触及其中任何一点。它触及的是一个用于公共模型的密钥，位于个人实例上，藏在一个已悄然失效的登录之后——这正是它成为一份有用记录的原因。这次失败并不需要对模型发起新颖的攻击。它所需要的，是一个无人审查的演示部署、一个在失效时默认放行的身份验证检查，以及一个把巨大用量视为世界常态的核算系统。