AI 评估平台 Braintrust 出了一个很典型、也很麻烦的安全事件。

根据 TechCrunch 看到的一封客户邮件，Braintrust 称其一个 Amazon Web Services 云账户遭到未授权访问。这个账户里包含客户用于访问云端 AI 模型的 API 密钥。公司随后要求每一位客户轮换存放在 Braintrust 平台上的 API keys。

这里最容易误读的一点是：Braintrust 目前没有确认所有客户密钥都被泄露，也没有说客户系统已经被入侵。

但问题也不能因此变小。

API key 不是普通资料。它更像一张可调用服务的门禁卡。只要权限够大，攻击者即使没有攻进客户自己的系统，也可能冒充合法请求去访问下游 AI 服务、触发调用、消耗额度，甚至碰到企业内部流程。

所以这件事的主线很清楚：Braintrust 本身的安全事故是一层风险，客户托管在第三方 AI 工具里的密钥，才是可能向下游扩散的那一层风险。

Braintrust 披露了什么，没披露什么

Braintrust 在客户邮件中说，一个 AWS 云账户存在 unauthorized access。该账户包含客户用于访问云端 AI 模型的 API 密钥。

公司称，已经联系了一名受影响客户。截至目前，暂未发现更广泛暴露的证据。

Braintrust 后来在官网披露了这起安全事件。公司表示，事件已经被遏制，并已锁定受影响账户，审计和限制相关系统访问，轮换内部 secrets。入侵原因仍在调查。

Braintrust 发言人 Martin Bergman 对 TechCrunch 的说法也要分开看。他表示，给客户发信是“出于谨慎”，公司“确认了一起安全事件，但目前没有泄露证据”。

这不是互相矛盾，而是边界不同：公司确认有安全事件，确认相关 AWS 账户里有客户密钥；但公司没有确认攻击者读取了所有密钥，也没有公布更大范围泄露。

已确认仍未确认客户该怎么理解
一个 AWS 云账户遭未授权访问攻击者是否读取了全部客户密钥不能等最终报告，先按潜在暴露处理
账户内包含客户 AI 模型 API keys受影响客户数量和数据规模检查密钥权限、调用日志和账单
公司已联系一名受影响客户入侵原因和攻击者身份关注后续根因说明，而不是只看安抚措辞
已锁定账户、限制访问、轮换内部 secrets是否还有其他系统被波及采购和安全评估需要补充材料

这张表的重点只有一句：事实还没完全清楚，但客户不能等事实完全清楚再动手。

安全事件里经常有这种时间差。厂商需要调查证据，客户需要先把风险口子堵住。宁可多轮换一次，也不能把一把可能外流的钥匙继续挂在生产环境上。

API 密钥泄露的麻烦，在于它看起来像合法访问

Braintrust 的产品定位，是帮助企业监控、评测 AI 模型和 AI 产品。它的创始人兼 CEO Ankur Goyal 曾把 Braintrust 称为“工程师构建 AI 软件的操作系统”。

这类平台为什么会存客户密钥？原因也不复杂。

企业要做模型评测、提示词实验、效果监控，往往要接入 OpenAI、Anthropic、AWS Bedrock 或其他云端模型服务。为了让工具跑起来，客户会把相关 API key 放到第三方平台里。

便利就从这里来，风险也从这里来。

API key 的危险不在于“文件被看见”这件事本身，而在于它可能带着权限。攻击者拿到密钥后，访问行为可能显示为正常 API 调用。它不像传统入侵那样一定有明显破门动作。

对使用 Braintrust 的 AI 工程团队来说，眼下最实际的动作很具体：撤销旧 key，签发新 key，更新环境变量和 CI/CD 配置，重新部署相关服务。

安全负责人要看另一组东西：近期模型调用日志、异常请求、额度消耗、账单变化，以及这些 key 是否被赋予了过高权限。

这里有一个现实约束。很多团队会把评测、监控、实验平台接在同一套模型账号上。这样省事，但一旦轮换密钥，影响的可能不是一个页面配置，而是一串流水线。

采购团队也会变谨慎。正在评估 Braintrust 或类似 AI 工具的企业，可能会延后上线，至少会要求补充安全说明：密钥如何加密、谁能访问、日志保留多久、是否支持最小权限和客户自管密钥。

这不是“换不用换工具”的简单题。更现实的问题是：第三方平台到底该不该长期保管高权限 secrets？如果必须保管，权限能不能缩到只够完成任务。

CircleCI 的旧账，提醒 AI 工具链别重蹈覆辙

这类事故并不是 AI 行业独有。

2023 年，开发工具平台 CircleCI 遭遇类似云端数据泄露后，也要求客户轮换存放在平台上的 “any and all secrets”。那次事件让很多工程团队重新意识到：CI/CD 平台不只是构建工具，它还是 secrets 集散地。

Braintrust 这次事件的相似点也在这里。产品形态不同，但风险结构接近：第三方 SaaS 替客户保存密钥，一旦平台侧出事，客户侧也要跟着清理。

AI 工具链还有自己的放大器。

模型评测、提示词管理、监控、数据标注、实验平台，经常要接多个模型供应商。一个团队可能同时用几套 key。只要管理方式粗放，第三方平台就会变成新的钥匙串。

目前最该盯住三件事。

观察点为什么重要如果没有答案，客户该怎么做
入侵原因是什么判断是否还有同类账户或配置风险继续按高风险处理，扩大自查范围
哪些密钥可能被访问决定轮换范围和排查范围默认轮换存放在平台上的相关 keys
是否提供更细审计日志帮客户判断是否被读取或滥用查下游模型平台日志和账单异常

我更在意的不是 Braintrust 会不会给出一份漂亮的事后说明，而是这件事会不会改变企业使用 AI 工具的默认姿势。

过去很多团队接第三方平台，先问能不能跑、好不好用、接入快不快。现在还得补一个问题：我的 key 放进去后，出事时谁能证明它没被用过？

这就是密钥托管的硬处。信任可以给，权限不能乱给。AI 工具链跑得越快，越不能把所有门禁卡都交给一个中间平台保管。