METR 安全事件暴露了价值 60 万美元的 AI 凭证失陷

METR 披露了两起安全事件：攻击者窃取了一枚 API key，并消耗了价值约 60 万美元的模型额度。首次攻击持续了三周，期间出现了异常流量和反复的限流错误，却始终未被发现。

由于模型开发商向 METR 免费提供了这些额度，这笔损失并未转化为直接账单。这一细节限制了财务影响，但也消除了本可能更早暴露滥用行为的支出阈值。

METR 安全事件的意义不止于一家研究机构。一个实验性 agent 控制面板将云端访问权限、实时凭证、公开暴露和薄弱监控集中在同一系统中。这种组合使一次身份验证失效演变为对高价值计算资源的长期访问。

METR 表示，其调查未发现攻击者访问最敏感信息的证据。然而，第二起事件揭示了公开研究工具与私有评估数据之间的距离有多么接近。两起事件共同挑战了这样一种假设：低风险原型可以采用更宽松的安全控制。

METR 安全事件始于一个暴露在外的 Agent 控制面板

首起事件始于一次常见的身份验证失效，但 AI agent 为攻击者提供了从公开访问到窃取凭证的路径。

2026 年 3 月，一名 METR 研究人员在个人 Amazon EC2 实例上部署了 agents。EC2 是 Amazon Web Services 提供的虚拟服务器租用平台。该研究人员有意让该实例可通过互联网访问，并在其前方配置了 Google 身份验证。

该应用包含了 METR 所称的故障开放漏洞。故障开放系统会在身份验证控制失效时继续运行，而非拒绝访问。在本案中，该故障悄然禁用了身份验证，使控制面板暴露数日。

该 EC2 实例还存有一枚 API key，关联 METR 用于访问公开模型的通用账户。API key 是软件用于向在线服务验证请求身份的凭证。

根据 METR 的安全披露，攻击者诱导一名 agent 泄露了该模型供应商的 key。随后，攻击者安装了 SSH key，从而建立了一种可持续远程访问被攻陷服务器的方式。

这一过程很重要。攻击者无需突破前沿模型的安全防护，也无需开发新的 AI 漏洞利用手段。最初的突破口来自一个以不安全状态失效的普通 Web 应用控制机制。

但 agent 仍然影响了结果。一旦外部人员进入该界面，agent 就可能访问或复现一枚在应用外部同样具有价值的凭证。因此，被攻陷的控制面板成为进入另一模型供应商账户的桥梁。

METR 怀疑攻击者通过监控近期注册的网站发现了该实例。证书透明度记录能够帮助识别新域名和子域名，因为它们会公开记录已签发的 Web 证书。

该机构认为，攻击者在这些记录中搜索了与大语言模型和 agents 有关的术语。这类术语可以识别可能包含高价值供应商凭证的实验性服务。

这一解释仍属于 METR 的判断，而非经过公开验证的归因。METR 尚未确认攻击者、模型供应商或确切的发现基础设施。

获取凭证后，入侵者使用了整整三周。METR 计算称，所消耗的额度价值约 60 万美元，尽管其并未实际支付这笔费用。

事件中引人注目的数字可能会分散人们对更广泛失效链条的注意力。公开暴露、agent 可访问的凭证、持续性的主机访问权限，以及不完整的用量可见性，都一直未得到解决。

其中任何一项控制措施都可能减轻损失。身份验证本可拒绝访问；凭证隔离本可阻止泄露；主机监控本可发现新增的 SSH key；供应商侧限制本可约束消耗。

攻击之所以成功，是因为这些防线未能阻断同一攻击链条。

为何三周的模型滥用看起来像正常研究活动

METR 的常规工作负载制造了足够多的运营噪声，掩盖了攻击者的活动。

METR 通过可能消耗大量 tokens 的实验来评估先进 AI 系统。Tokens 是衡量模型处理或生成文本的单位。大规模评估运行也可能触发异常的限流和供应商错误。

这种运营模式削弱了一项常见的安全信号。高用量不会自动显得恶意，因为合法的 METR 研究也可能产生类似行为。

METR 表示，事件发生时，其内部控制面板未显示每位用户遭到限流的请求。因此，调查人员无法完整了解与被攻陷账户相关的活动。

该机构也没有为受影响 key 设置自然的支出上限。由于模型供应商免费提供额度，一张不断增长的账单不会迫使其立即展开调查。

没有账单并不意味着资源毫无价值。模型推理会消耗计算能力，而对该能力的访问可以被转售或用于无关的工作负载。即使 METR 避免了现金支出，攻击者仍获得了可转移的经济利益。

对已披露时间线的独立报道也强调了相同的监控缺口。非法消耗混入了一个早已习惯高 token 用量和不稳定限流信息的环境中。

这正是 METR 安全事件中的核心反转。规模通常帮助研究团队测试能力更强的模型，但同样的规模也使异常消耗更难辨识。

传统的支出告警可以迅速暴露被盗的云端凭证。然而，捐赠额度、研究配额和预付费容量都可能削弱这道防线。组织仍需要基于使用模式、请求来源、key 身份和预期工作负载设置限制。

阈值还应考虑失败和被限流的请求。即使它们没有出现在标准计费总额中，这些请求也可能揭示侦察行为或试图消耗资源的活动。

该事件说明，仅看原始用量并不是完整指标。更好的检测系统应判断活动是否符合该 key 已确立的用途。

分配给单项实验的凭证，不应悄然支持数周无关流量。为每个应用分别配置 keys 会让这种比较更容易，因为它们减少了与单一身份关联的合法行为数量。

短期凭证将进一步缩短攻击窗口。会过期或需要续期的 key，可限制被复制的值持续有效的时间。长期有效的 secrets 会给攻击者更多时间建立持久访问并将其变现。

METR 的应对措施包括在供应商支持的情况下增加支出告警。该机构还扩大了监控覆盖范围，并致力于减少噪声告警。

这些改动解决了可见症状，但更深层的教训在于系统边界。研究工作负载不应仅仅因为异常用量经常发生，就让无法解释的活动变得可以接受。

正常运营需要可衡量的范围、明确的负责人和定义清晰的例外情况。否则，“研究流量”会成为一个宽泛类别，同时掩盖合法实验和未经授权的消耗。

真正的冲突是快速实验与受控访问之间的矛盾

Agent 开发鼓励快速部署，而安全依赖于原型通常缺乏的严格边界。

METR 将这个暴露的控制面板描述为 vibe-coded，即主要通过 AI 辅助提示和迭代生成开发而成。该标签并不能证明 AI 编程工具导致了身份验证缺陷。

相关问题在于，最终形成的应用是如何被审查和部署的。该软件接受公开流量、与 agents 交互，并在实时供应商凭证附近运行。这些条件使其不再只是一次可随意丢弃的本地原型。

快速实验对于模型评估很有价值。研究人员经常需要定制界面、临时编排工具和新的模型组合。漫长的审批流程可能阻碍探索性工作。

然而，安全类别应取决于系统的访问权限和暴露程度，而非其预期寿命。一个临时应用一旦能够从互联网访问并持有可复用凭证，就具备了类似生产系统的属性。

Agent 也不应能够泄露原始 key。应用通常需要获得调用外部服务的授权，但这不代表必须将可复用的 secret 放在模型可读取的上下文中。

凭证代理可以代表 agent 发出授权请求，而无需暴露底层 key。范围受限的能力也可以约束应用可访问的模型、操作或用量级别。

这种分离很重要，因为语言模型会处理不受信任的指令。进入 agent 界面的攻击者可能要求模型暴露隐藏数据、滥用已连接工具，或执行超出应用预期工作流程的操作。

OWASP 的 agent 安全指南将敏感数据暴露、过度权限、工具滥用和提示注入列为相关风险。该指南建议限制权限，并将凭证置于 agent 可访问上下文之外。

METR 的披露称，攻击者直接诱导一名 agent 泄露了其供应商 key。这与基于提示的凭证提取相似，但公开证据并未提供足够细节，无法进行正式分类。

身份验证缺陷仍是第一个决定性的控制失效。若非公开访问，外部人员便不会拥有能够发出该请求的界面。

因此，若将该事件仅称为提示注入攻击，将会过度简化问题。损失路径结合了不安全部署、secret 暴露、宽松的 agent 访问权限、持久化访问和薄弱的消耗监控。

同样，只归咎于 vibe coding 也会忽视一套既有的安全实践，而这些实践无论代码如何生成都同样适用。由人工编写的原型也可能故障开放、暴露 secrets 并遗漏遥测能力。

METR 已为其生产评估平台制定了文档化的安全控制措施。其公开的 SOC 2 报告描述了截至 2025 年 8 月为该定义系统设计的控制措施。

SOC 2 Type I 报告评估的是某一时点的控制设计。它并不保证每项个人实验、临时服务或后续部署都遵循相同控制措施。

这一区别正是该事件的核心。组织可以保护其主要平台，同时研究人员却可能在其正式边界之外创建平行基础设施。

个人云账户让这种碎片化更难被发现。中央安全团队可能缺乏对托管环境之外创建的实例的日志、资产清单、网络控制和自动化策略执行能力。

METR 表示，该研究人员无法访问其敏感度最高的两类资源。这限制了表面上的影响范围。然而，该实例中仍包含一个值得攻击者觊觎的服务商凭证。

教训并不是实验必须停止，而是只要涉及互联网暴露和真实凭证，即便只是短期研究工具，也应自动触发基础安全审查。

第二次攻击使评估数据面临风险

5 月的攻击活动表明，攻击者不仅关注廉价算力，也在试探通往非公开模型访问权限和评估数据的路径。

2026 年 5 月初，METR 得知黑客正瞄准其公共基础设施。该组织评估认为，攻击者的动机是经济利益，并称他们可能试图获取前沿模型的访问权限。

METR 观察到系统性的探测活动，包括撞库攻击、尝试获取 OAuth 授权、扫描新部署的服务，以及针对员工的钓鱼攻击。撞库攻击会将此前泄露的登录凭据组合用于尝试登录其他服务。

该组织称，攻击者大量使用智能体自动发现漏洞。这一说法表明，AI 降低了扫描多个服务和认证路径所需的工作量，但 METR 并未公布性能测量数据。

同一时期，METR 通过其公开的对话记录查看器，无意中暴露了一个只读 SQL 查询机制。SQL 是应用程序用于从结构化数据库检索信息的语言。

这些查询原本默认只返回公开记录。一个漏洞可能改变该范围，并暴露未发布的评估数据。

METR 预计底层数据库仅包含涉及公开模型的结果。然而，其中意外混入了一些敏感模型输出。

一名独立安全研究人员发现了该漏洞，并以负责任的方式进行了报告。METR 随即下线受影响的 API，并支付了漏洞赏金。

攻击者在扫描 METR 基础设施时曾接触该端点。该组织表示，其证据显示没有迹象表明攻击者发现了这一漏洞或访问了非公开信息。

这一结论需要谨慎表述。缺乏证据并不能从数学意义上证明访问从未发生。它仅反映了 METR 及其安全顾问从现有日志和取证材料中发现的情况。

METR 解释称，利用该漏洞需要完成多个具体步骤。攻击者必须发现范围限定漏洞、正确加以利用、识别敏感对话记录，并在不触发错误的情况下下载这些内容。

该组织认为，这一连串操作发生的可能性极低。它也承认存在一个复杂情况：其曾暂时移除该端点，后来又在未察觉漏洞的情况下恢复上线，且未发现后续攻击者访问。

与被盗用的额度相比，第二起事件涉及的风险不同。未发布的评估结果可能暴露模型弱点、行为模式、隐藏输出，或依据保密协议提供的信息。

METR 将其信息划分为四个大类。已发布材料处于最低级别。公开模型凭证和未发布的公开模型结果属于下一类别。

更高的两个类别涵盖敏感模型访问权限和高度敏感的组织信息。METR 表示，其调查发现，两起事件期间均没有对这些类别信息的访问。

不过，当时对话记录数据库中包含了一些本不应存在的更高类别材料。这意味着，在任何人试图利用查询机制之前，预定的信息分类边界就已经失效。

仅靠政策来分隔数据并不足够；如果记录可能进入错误的数据库，有效隔离还需要自动化分类检查、查询时的访问控制，以及能够保留证据供后续调查的日志。

第一起事件暴露了凭证边界问题，第二起则暴露了数据边界问题。两者都涉及面向公众的研究系统，而这些系统与高价值资源的距离，比其设计角色所应允许的更近。

METR 的应对降低了风险，但仍留下验证问题

METR 已调整其架构和安全流程，但外部人士尚无法衡量这些控制措施对未来实验的覆盖是否一致。

在发现 3 月的滥用行为后，METR 撤销了该研究人员的访问权限，并停止了受影响的实例。它创建了取证镜像、轮换了凭证、对该研究人员的笔记本电脑进行了镜像和擦除，并通知了相关模型公司。

安全咨询公司 Calif 审查了 METR 的调查结果，并进行了独立的入侵评估。METR 还使用人工和智能体辅助取证来调查该事件。

该组织表示，这些工作未发现除单个公开模型 API 密钥外的其他入侵情况。它尚未公布顾问的完整评估报告、详细的入侵指标，或服务商的身份。

METR 扩展了有关个人基础设施上凭证和数据的政策，也为部署公开应用的研究人员建立了正式安全审查机制。

在 5 月攻击活动之后，METR 暂时禁用了几乎所有面向公众的服务，以及对敏感数据的内部访问。随后，它创建了一个在架构上与内部基础设施隔离的公共生产环境。

这种隔离直接应对了对话记录查看器的风险。如果持续一致地执行，公开应用中的缺陷将不再能够成为进入内部数据系统的路径。

METR 还关闭了遗留基础设施、增加了日志记录、缩短了凭证有效期、缩小了权限范围，并部署了更多终端和服务器安全软件。

该组织聘请了一名安全负责人，并表示计划进一步扩充团队。它还委托开展额外的红队工作，即由获得授权的测试人员模拟攻击者行为以发现弱点。

这些措施与披露的失效模式相契合，改善了资产清单、隔离处置、凭证管理、遥测能力和责任追溯。

持怀疑态度的人会问：覆盖范围如何？只有在研究人员无法通过个人云账户、未受管理的服务或复制到实验工具中的凭证绕过这些政策和集中式环境时，这些措施才能真正发挥作用。

METR 尚未公布有关这一覆盖范围的可衡量目标。读者不知道如今有多少比例的公开部署会接受审查，也不知道异常密钥使用会在多快时间内触发调查。

模型服务商层面运行哪些控制措施同样尚不明确。消费警报有所帮助，但硬性使用上限、短期令牌、更窄的权限范围和自动撤销能提供更强的限制。

并非每家模型服务商都提供相同的控制能力。METR 指出，在 3 月事件发生时，它无法为受影响的密钥设置消费上限。

因此，尽管 METR 控制着暴露的应用，服务商也应共同承担更广泛设计问题的一部分。处理高价值模型访问权限的组织需要具备这样一种假设：密钥终将泄露。

这一披露本身值得肯定。METR 公布了详细的事件序列，承认了多项内部失误，并区分了可能暴露与已有实际访问证据之间的差别。

然而，透明度不应与独立验证混为一谈。核心发现仍来自 METR 自身的调查及其聘请的顾问。

没有公开证据能识别攻击者身份或确认其动机。60 万美元的估值也只是获授额度的近似价值，并非已支付账单或经独立审计的损失。

这些限定并不会抹去事件本身。它们界定了现有证据所能支持的结论，并防止标题中的数字显得比事实更精确。

METR 披露后安全团队应关注什么

下一项考验是，METR 的新控制措施能否带来可见的限制、更快的检测，以及更安全的公开研究系统。

第一个信号是围绕公开部署的执行力度。METR 已将安全审查制度化，但该政策是否有价值，取决于每个面向互联网的实验是否都会被纳入受管理的资产清单。

一个有价值的结果应包括：自动发现与该组织相关的新域名、云实例和公开端点。安全团队应将该清单与获批准的应用及指定负责人进行比对。

如果未来研究工具始终运行在隔离的公共环境中，METR 的应对将支持其关于架构边界已得到改善的说法。另一项包含真实凭证的个人部署则会削弱这一结论。

第二个信号是可衡量的凭证隔离能力。METR 在可能的情况下增加了使用监控和消费警报，但警报仍需要人工解读和响应。

组织应关注更短的凭证有效期、应用专用密钥、受限的服务商权限，以及在异常活动后自动暂停。原始凭证应始终无法被智能体的提示上下文和输出通道访问。

OWASP 对提示注入风险的讨论解释了，模型指令本身为何无法保护秘密。攻击者可以操纵一个暴露的模型，使其忽略预定限制，或泄露其上下文中可获得的信息。

如果 METR 或其服务商采用经由代理的访问机制和硬性消费上限，类似的接口入侵应造成更小损失。若控制措施仍主要基于警报，攻击者可能依然可以持续活动，直到有人识别出异常模式。

第三个信号是有关数据隔离的证据。METR 表示其新的公共环境在架构上已实现隔离，但 5 月的问题还涉及敏感记录被放入错误数据库。

仅凭网络隔离无法自行纠正错误分类的信息。METR 需要能够在受限评估数据进入面向公众的存储前发现它们的保障措施。

未来的披露、审计或技术更新应表明，这些控制措施是否同时防止直接访问和意外数据存放。一份干净的外部评估将增强人们对修订后边界的信心。

METR 的安全事件也促使 AI 公司重新审视其提供评估访问权限的方式。外部评估人员需要真实的模型能力，但广泛且长期有效的凭证会形成极具吸引力的攻击目标。

服务商可通过限定范围的令牌、按项目设定的限制、来源限制、快速撤销，以及对被拒绝请求的可见性来降低这一风险。这些功能同时保护服务商和评估人员。

开发者也应将相同的思路应用于较小型的智能体项目。一个能够访问电子邮件、源代码、云服务或内部文档的原型，已经拥有一条具有实际意义的安全边界。

记录此类实验的团队可以使用受控的知识库，保留威胁模型、部署负责人、审查决策和事件经验。文档无法替代技术控制，但可以让未受管理的例外情况更容易被发现。

最有用的问题不是某个应用是否由氛围编程构建，而是不受信任的用户能否接触它、它可访问哪些凭证，以及当每一条指令都被视为恶意时会发生什么。

METR 的披露给出了一个罕见而具体的答案：一次公开认证失败触及了智能体，智能体暴露了凭证，而不完整的监控使三周未经授权的使用得以持续。

安全负责人现在应在自己的系统中测试同样的链条：外部人员能否发现该接口？模型能否泄露秘密？宿主是否能接受持久访问？异常消耗能否混入预期流量？

如果其中任何一项的答案为是，那么当前未发生事故反映的是时机，而非得到控制。下一次 METR 更新应会显示，其新架构是否已将来之不易的经验转化为可执行的限制。