一个环境变量，让这家AI平台被捅了一刀

   11 月 7 日，Meta 前首席战略官戴夫·韦纳宣布加入 AI 初创公司 Fireworks 当 CFO。这家公司估值 175 亿美元，正在和红杉谈新一轮融资，预期能到 300 亿到 400 亿。 

   人事新闻里藏了一条更该被注意的信息：Fireworks 在 10 月发现了一起安全事件。

   官方公告写得很克制：未经授权的第三方，使用了内部的 Fireworks 凭证，访问了少数客户账户中"用于评估作业的环境变量"。 

"环境变量"这四个字，做过开发的人看到都会心里一紧。那里放的东西，通常就是 API Key、访问令牌、数据库连接串。

   官方紧接着补了一句：根据目前的调查，尚未发现任何未经授权访问客户模型、数据集、训练数据、个人信息或推理流量的证据。 

   这句话信息量也不小。它说的是"没发现证据"，不是"没发生"。而且它列的范围很精准——模型、数据、个人信息、推理流量都排除了，唯独没有说"凭证本身没被拿走"。 

   因为凭证，本来就是被拿走的那部分。 

   这也是为什么，安全圈一直有句话：最贵的漏洞，往往不是代码写错了，而是钥匙放错了地方。 

   Fireworks 不是小公司。它 2022 年由前 Meta 和谷歌员工创立，专做开放模型的推理和训练平台，英伟达也投了。D 轮估值 175 亿美元，客户里有大量做模型定制和部署的企业。 

   这类平台的位置很特殊：它站在客户和模型之间，手里握着大量客户的调用凭证。它一出事，受影响的不是自己的资产，而是所有把 key 托管给它的客户。 

   回到我们自己身上。大部分人不会遇到"内部凭证被滥用"这种级别的事，但每天在做的事，风险本质是一样的——把 key 到处贴。 

   几个最常见的泄漏路径，几乎每个人都踩过至少一个。 

一是贴进聊天窗口。调试代码跑不通，把报错和配置文件整段发给 AI 或者同事——里面的 key 也一起发出去了。你以为在求助，其实在广播。 

二是提交到 Git。`.env` 文件忘了写进 `.gitignore`，一次 push 就永久留在提交历史里。哪怕后来删掉，历史记录还在，爬虫专门扫这个。 

三是日志打印。为了排查问题临时 `print(config)`，上线忘了删。日志系统一采集，key 就散落在十几个地方。 

四是前端硬编码。最要命的一种。把 key 写进浏览器能看到的 JS 里，等于把密码贴在门牌上，谁打开开发者工具都能拿走。 

AI 时代的安全边界，已经不在模型上，而在凭证上。模型再强，也挡不住有人拿着你的 key 刷额度。

   有几个动作成本很低，但收益很高，建议今天就去改。 

一是按用途拆 key。开发、测试、生产各用一把，别一把 key 打天下。这样哪一把漏了，影响范围是可控的，直接停用那一把就行。 

二是设额度上限。大部分平台都支持给单个 key 设消费上限。就算真被刷，损失也有天花板，不至于第二天醒来看到一张天价账单。 

三是定期轮换。把换 key 变成跟改密码一样的习惯。尤其是团队里有成员离职的时候，第一件事应该是回收权限，而不是交接文档。 

四是别把 key 贴进聊天。要贴就贴脱敏版本，把中间几位换成星号。这个动作只需要两秒，但能挡掉绝大多数意外。 

   Fireworks 这事的最终损失可能不大，但它提醒了一件事：你托管给别人的每一把钥匙，都是别人安全水平的下限。

   所以选服务商的时候，别只看价格和速度，也看一眼它怎么处理凭证——是不是支持子 key、有没有额度限制、出事了会不会说清楚。 

   aadclaw.com 这边一直支持按需分配子 key 和设置额度上限，这也是我们觉得最该做好的基础功。毕竟中转站这个位置，天然就是凭证的集散地，马虎不得。 

扫码进群，一起聊 AI 和 API

群里聊模型选择、踩坑经验、额度怎么用最划算

   你的 key 现在放在几个地方？评论区自查一下，说不定能发现问题。 

   转给那个习惯把配置整段发群里的同事，他可能正需要这篇。 

蓝核科技