以评估 AI 能力著称的非营利组织 METR 公布了 2026 年发生的两起安全事件。第一起是研究员个人环境中泄露的 API 密钥被滥用了三周，被消耗掉的额度按商业价值计算约为 60 万美元（约 9300 万日元）。第二起则是外部攻击者对其公开基础设施展开的系统性探测。METR 表示，两起事件均未发现敏感信息被访问的证据。
※1 美元 = 155 日元（截至 2026 年 9 月 4 日）
起点是研究员让 AI 写出来的一个小应用
第一起事件要追溯到 2026 年 3 月。一位没有敏感访问权限的研究员，在自己个人账号下的 Amazon EC2 实例上运行智能体。该实例是有意对外开放的，前面挡着 Google 认证。实例里同时存放着 METR 公开模型账户的一个 API 密钥。
问题出在这个应用是让 AI 生成的代码，也就是所谓的 vibe coding。它的认证逻辑存在一个失败即放行的缺陷：校验出错时不是拒绝而是直接放过。由于失效过程没有任何提示，谁都没有察觉。结果这套环境在互联网上裸奔了好几天。
METR 推测，攻击者是通过翻查证书透明度日志找出近期注册的域名，再从中筛选名称里带有语言模型或智能体等高信号词的站点。目标正是那里可能存放的模型厂商 API 密钥。个人随手搭建的开发环境，如今已经成了密钥猎手的货架。
入侵手法也很有时代特征。攻击者直接向运行中的智能体发出提示，让它把手里的 API 密钥说出来，随后添加 SSH 密钥保持访问，并用这份被盗凭据在三周内消耗了大量 token。
为什么三周都没发现
一个以评估为主业的组织，为什么这么久才察觉。METR 给出了三点原因。
其一，大量消耗 token 本来就是日常。针对未发布模型跑大规模评估时，速率限制和 API 报错会不断出现，其中很多是不反映真实用量的假信号，团队早已习以为常。
其二，当时的内部用量看板并不会向全部用户展示被限速的请求，异常迹象没有出现在有人盯着的地方。
其三，也是最关键的一点：这批额度是模型开发方免费提供给 METR 的，不产生账单。既没有金额这道天然的刹车，当时也没有办法给这类密钥设置消费上限。60 万美元只是被消耗额度的商业价值，并非 METR 实际损失的金钱。但正因为不用付钱，才没有人去看这个数字。
5 月遭遇外部的成规模攻击
第二起发生在同年 5 月。METR 收到线报，得知自己正被一批看起来以牟利为目的的攻击者盯上，对方很可能是冲着前沿模型的访问权来的。
他们的手法是对公开基础设施进行地毯式探测：针对认证服务的撞库、尝试获取 OAuth 令牌、扫描新上线的服务，以及对员工发起钓鱼。值得注意的是，漏洞发现工作大部分交给了智能体自动完成。
麻烦的是，同一时期 METR 自己也留了口子。对外提供的记录查看功能意外暴露了一个只读的 SQL 查询机制。默认情况下查询范围限定在公开数据，但利用一个缺陷就能触及未公开的评估数据。更糟的是，这个数据库里还误装入了本不该存放的敏感模型数据。
该缺陷由一位独立安全研究员发现并负责任地披露。METR 随即下线了该接口并支付了奖金。攻击者虽然在大范围行动中顺带探测过这个端点，但没有证据显示他们发现了缺陷或接触到任何非公开数据。
把对外服务与内部系统隔开，并配备专职安全人员
针对这两起事件，METR 重整了体系。首先明确并扩充了适用于全体员工和外包人员的规定，重点是不得把 METR 的凭据或数据放到非 METR 的基础设施和设备上。研究员对外部署应用时，也必须走一套正式的安全评审流程。监控覆盖面被扩大，同时清理了容易被忽略的噪音告警，并在条件允许的密钥上加了用量告警。
架构上，对外应用现在运行在一个与内部基础设施在结构上完全分离的专用生产环境中，避免公开侧的配置失误导致内部数据外泄。
人员方面，METR 招聘了安全负责人，并计划继续扩编，包括一名全职安全工程师。那些无谓扩大攻击面的遗留基础设施已被关停。数据库查询和 API 使用的日志记录得到加强，也建立了针对 API 密钥异常使用的监控。凭据有效期被缩短，权限范围也进一步收窄。METR 特别说明，上述措施的描述截至 2026 年 7 月 30 日有效。
总结
METR 这次披露中最值得注意的，不是损失规模，而是让问题长期隐形的那些条件。在一个大量调用 API 已成常态的组织里，异常的 token 消耗会融进背景噪音。免费额度也不会有账单这种简单直白的警报。而最初的入口，只是一个由 AI 写出来的个人小应用。交给智能体的密钥，问一句它就会交出来。重新审视密钥放在哪里、能用多久，看似绕远，却是最稳妥的对策。
