聚合站 key 泄露不等于厂商封号：先看清真正的影响半径再决定怎么办
聚合站的 API key 泄露后，攻击面与泄露厂商原生 key 并不相同：它受聚合层余额、额度、日志和路由策略约束，但也可能被用来刷量消耗余额。本文说明聚合 key 能做什么、不能做什么，与厂商 key 的区别，以及泄露后第一步应查哪些用量日志、按什么顺序处置。
先弄清楚：聚合 key 不是厂商 key
很多人一看到 key 泄露就想到「账号被封」，但聚合站的 key 和厂商原生 key 是两种东西。
厂商 key 直接绑定你在该厂商的账号，泄露后攻击者以你的身份调用，风险直接落在你在该厂商的账号主体上。聚合站的 key 通常是聚合层签发的一把凭据，请求先经过聚合层，再由聚合层用上游凭据转发给模型厂商。
这个结构决定了：泄露的聚合 key 影响半径，首先落在「你在聚合站的账户余额与用量」，而不是直接落在你在各家厂商的账号上。
泄露的聚合 key 能做什么
在 key 仍然有效的前提下，持有者通常可以：
- 用这把 key 调用聚合站已授权的模型，产生 token 消耗
- 消耗你账户里的余额（按你账户的计费方式扣减）
- 在聚合站侧留下调用记录，形成可观测的用量日志
- 如果聚合站支持多 key 管理与权限区分，可能触达该 key 被授予的模型范围
这些行为的共同点是：都发生在聚合层，表现为你的账户支出与用量上升。
它不能做什么
同样重要的是边界。聚合 key 一般不能：
- 直接登录你在模型厂商的账号后台，或修改厂商侧的账户设置
- 绕过聚合站本身的额度、模型白名单等账户级限制（如果账户配置了的话）
- 触碰你没有在聚合站开通的模型或能力
- 直接获取你在聚合站的充值方式、支付信息等与调用无关的数据
换句话说，泄露的是一把「调用凭据」，不是「账户控制权」。这并不代表可以掉以轻心——余额被刷同样是真实损失——但处置思路与厂商 key 泄露不同。
和泄露厂商 key 的关键区别
| 维度 | 聚合 key | 厂商 key |
| --- | --- | --- |
| 影响落点 | 聚合站账户余额与用量 | 厂商账号本身 |
| 处置入口 | 聚合站后台（吊销、限额） | 厂商控制台 |
| 波及范围 | 受聚合层路由与授权约束 | 该厂商账号下的权限 |
| 观测数据 | 聚合站的用量日志 | 厂商侧的用量与账单 |
实务上的含义是：聚合 key 泄露时，你第一步不是去各家厂商后台排查，而是先在聚合站侧确认用量异常。厂商侧的记录反映的是聚合层转发过去的请求，定位攻击源不如聚合层日志直接。
第一步：查哪些用量日志
发现 key 可能泄露后，先不要急着下结论，按下面的顺序看数据：
- 按 key 维度看调用量：如果后台支持按 key 拆分用量，先定位这把 key 的请求量与 token 消耗曲线，看是否有明显偏离日常的时段。
- 按时间看突增：对比泄露可能发生的时间点前后，找用量抬升的起点。这决定了攻击窗口有多长。
- 按模型看分布：攻击者常集中调用某个高价值或易转售的模型。模型分布的突变往往比总量更早暴露问题。
- 按来源看请求特征：如果日志记录 IP、UA、调用时段等元数据，留意与你正常使用习惯不符的模式，例如非工作时段的高频请求。
- 核对余额扣减：把用量日志与余额变化对上，确认消耗是否确实来自这把 key，排除其他 key 或正常业务的影响。
这些检查的目的不是取证，而是先回答两个问题：这把 key 是否真的被外部使用，以及用了多少。
处置顺序：先止血，再复盘
确认异常后，顺序通常是：
- 吊销或轮换该 key，切断继续消耗的通道
- 如果聚合站支持，为该账户设置用量上限或模型白名单，缩小下次泄露的影响面
- 用第一步查到的日志区间，估算损失并判断是否需要进一步沟通
- 复盘 key 的存放位置：是否写进了前端代码、公开仓库、聊天记录或截图
轮换之后，新 key 应只放在服务端或受控的密钥管理位置，不要出现在客户端可分发的产物里。
一个容易被忽略的点
聚合 key 泄露的损失通常是「可计量的余额消耗」，这让它看起来没有厂商 key 泄露那么吓人。但正因为聚合 key 往往一把调多个模型、放在统一入口，一旦泄露，暴露的是你整个调用面，而不仅是某一个模型。
所以更稳妥的做法是平时就按用途拆 key、按 key 设限额，让任何一把 key 泄露时的影响半径都是可控的。这比事后追查更省事。