结论先行：外部 AI 服务的凭据被盗，最先响的通常不是安全告警，而是账单。这类调用在业务日志里看起来完全正常——接口没有报错，服务没有中断，用户没有投诉，只有用量曲线在某个时间点抬起来。可行的做法是把「用量与账单异常」当成一条独立的安全信号来运营，配三条核对动作：定一条用量基线、把账单按凭据拆开看、把异常时段的调用特征与自家任务表对齐。
本文只谈凭据被盗之后怎么从成本侧发现与核算，不谈应用身份该怎么清点、也不谈密钥轮换的操作步骤。文中事件细节取自公开披露信息，不含具体平台名、机构名与地域，量化数字为披露方统计口径，供参考。
十月发生了什么
按公开披露的时间线，2026 年 10 月内至少九家提供应用与 AI 开发托管服务的平台先后披露安全事件，其中多起涉及客户存放在平台环境变量里的各类凭据。有一家平台在 10 月 30 日要求客户按「所有环境变量都已被解密」来处理，随后证实部分客户托管在其上的模型服务凭据遭到未授权使用。另一家平台在 11 月初披露，其云开发环境可能存在凭据暴露，受影响凭据已被替换。
这里有一个结构性的事实值得说清楚：这类平台的作用是替客户把应用跑起来，客户为了让容器里的程序能调用外部模型，必须把凭据以环境变量的形式交给平台保管。凭据一旦被平台侧拿到，就不再只受客户自己控制。所以这类事件的波及面不由客户的防护水平决定，而由平台这一层的暴露程度决定。
披露方给出的两组数字很有说明力。其一，在一个月内受影响的平台至少有九家，指向的是一种针对性的批量搜寻，目标正是「有模型访问权限的那部分环境变量」。其二，在已经核实的案例里，被拿走的凭据在 30 小时内产生了约 80 万次调用，另一把在 13 小时内产生约 170 万次，按标价折算合计约 10 万美元。这两组数字说明一件事：盗用者的动作非常快，从凭据流出到刷出可观费用，窗口是以小时计的。
为什么业务侧看不见这件事
把这类盗用和传统的入侵放在一起比较，会发现它特别安静。
| 观察面 | 常规入侵的迹象 | 凭据盗用的迹象 |
|---|---|---|
| 业务接口 | 报错率上升、超时增多 | 完全正常，调用成功 |
| 用户侧 | 功能不可用、投诉进来 | 无感知 |
| 安全设备 | 异常登录、横向流量 | 没有人的账号参与，多因素认证不起作用 |
| 用量与账单 | 可能无变化 | 调用量与费用在数小时内抬升 |
第四行是这类事件稳定会露出痕迹的地方。原因很直接：盗用者拿到的是一张可以消费的凭证，他的收益来自「把额度用掉或转卖出去」，每一次使用都会在原账号的账单上留下记录。账单是这种攻击绕不过去的一环。
三条从成本侧核出来的动作
其一，先有一条用量基线
没有基线就看不出异常。但这里的基线不需要很精确——多数企业的模型调用量在一天之内有稳定的形状：上班时段抬升，夜间落到低位，周末更低。基线的作用只是回答一个问题：某个夜间时段调用量突然翻了十倍，这是不是我们能解释的事。
可用的做法是按日记录三个数：调用总量、费用总额、调用最集中的那个时段。三个数连着看两周，形状就出来了。之后每周复核一次即可，不需要做成实时看板。
其二，账单要按凭据拆开看
这是最容易被忽略的一步。多数单位拿到的账单是账户级汇总，一个总数，看不出钱花在哪。而盗用发生后，最重要的信息恰恰是「哪一把凭据在刷」。
如果供应商的后台支持按密钥或按项目筛选，就直接把账单过滤到具体凭据上；如果只给账户级汇总，就得靠发版记录、任务执行记录、以及各业务线的报送数据做排除法——把能解释的部分扣掉，剩下的就是待解释的部分。
按凭据拆开还有一个长期价值：不同业务用不同凭据之后，一把凭据出问题时，可以只吊销这一把，不至于为了保生产而不敢动。
其三，把异常时段与自家任务表对齐
用量抬升不等于被盗。实际工作中，账单突然变高更多是这几种原因：批处理任务重跑、Agent 陷入循环反复重试、并发参数配错、一次没人限流的批量文档解析。
所以核对的顺序应当是先排除内部原因，再看外部。具体做法是把那个时段的几件事叠在一起看：有没有发版、有没有跑批量任务、有没有改过定时脚本、消耗的是哪个模型。四个问题里如果都对不上，才是需要往盗用方向查的时候。
认定之后，先做哪两件事
确认存在未授权调用之后，动作的顺序会影响损失。先在签发方吊销旧凭据，再去改平台侧的配置。原因是：从平台上删掉一个环境变量，只是抹掉了平台数据库里的那条字符串；如果凭据已经被复制到平台之外，能不能继续调用完全取决于签发方那边是否已经把它作废。
第二件事是固定证据。把异常时段的调用记录、凭据标识、时间线整理成一份结构化材料，比口头申诉有用得多。整理时注意不要在工单、群聊、排查记录表里贴完整的凭据明文——这会制造新的泄露点。
还有一条时间上的提醒：撤销之后要继续看两三天账单。深圳市奇摩计算机有限公司在给客户做外部 AI 服务治理时，通常会把这条用量基线作为交付项之一：先按日记录调用总量、费用总额与最集中的时段，跑满两周再谈异常判定。部分供应商的用量面板与最终结算之间有几小时到跨天的延迟，后续跳出来的费用要核对实际发生时间是在销毁之前还是之后。
边界与前提
这一套做法解决的是「发现与核算」，不解决「凭据为什么会流出」——后者的责任在平台侧，客户能做的只有事前选择与事中监测。另外，用量基线需要至少两周的数据才能形成，临时抱佛脚看不出异常。把外部 AI 服务的凭据纳入成本侧的例行核对，本身不产生直接收益，但它把这类事件的发现时间从「客户投诉」提前到了「账单异常」。
需要梳理自家外部 AI 服务用量与账单口径的，可以预约咨询。