正在加载，请稍候
英国独立顾问的 Claude Max 账号在无人使用时用量从 45% 涨到 55%，查明是会话密钥被拿去铸造未授权授权令牌。本文给出四个可核对的识别信号与四步处置顺序。
8 月 4 日，英国东萨塞克斯的独立 AI 顾问 Grant De Swardt 一整天没写代码，Claude Max 20x 的额度却在往上走。第二天他关掉所有挂载项、暂停定时任务、禁用云端执行，配额仍从 45% 爬到 55%。
他向平台索要一份逐条用量明细，没拿到。对方承认"确实不对劲"，随后封停付费账号、作废全部会话与服务端编程凭据，退回首余时间的 44.49 英镑。事后查明的原因只有一句话：一个被攻陷的会话密钥，被用来铸造未授权的授权令牌。TechCrunch 9 月 8 日的报道记录了他把经历发到 Reddit 后收到 80 多条评论，发现自己不是孤例。
这条链路里没有一步需要知道你的登录口令，所以"密码够复杂就没事"的直觉在这里失效。
真正让盗刷难以察觉的，是第三点背后的账务粒度：支持系统记录总量，但不提供逐条明细，即使你主动索要也不给。额度可以被静默抽走数月，而你在账单页看到的只是一条平滑上升的曲线。
还有一处细节值得记住：平台方认定恶意软件并非通过使用该模型本身传播，来源可能是下载了被感染的软件或点击了带毒广告。同一封邮件里，公司也承认这不是用户自己能控制的失误。
这位顾问的运气在于他恰好有一个近乎完美的对照实验。他的原话值得逐字保留：在最干净的受控区间里，用量从 45% 涨到 55%，期间他没有做任何工作，定时任务已暂停或完成，云端执行被禁用，本地也没有对应的活跃编码任务。以下四个信号按可观测性从高到低排列。
| 信号 | 正常情况 | 盗刷特征 |
|---|---|---|
| 空闲时段用量 | 无人操作时曲线走平 | 无人操作仍在爬升，且跨天持续 |
| 排除自有自动化 | 暂停定时任务后用量归零 | 暂停调度、禁用云端执行后照涨 |
| 曲线斜率 | 随实际工作量线性变化 | 12 分钟从 0 冲到 49%；连续三天在无人使用时耗尽上限 |
| 授权与订阅状态 | 授权列表与你的设备一一对应 | 出现陌生第三方授权；账号被"未经同意自动升级"并产生扣款 |
最后一行来自 Reddit 与 GitHub issue 里的其他受害者：有人称账号在本人未操作的情况下被自动升级、信用卡被扣款、用量从 0% 直接跳到 100%；也有人只发了两三条提示词加一次网页搜索，12 分钟烧掉 49%。
一个反直觉的点：平台不一定比你更早发现。这位顾问从未收到那封"你的令牌正在被盗"的警告邮件，而另外两位受害者收到了。说明此类通知依赖内部风控命中，不是人人都有的兜底机制。
我们内部也踩过一次类似的坑：早期给工具链配凭据时只做了密码轮换，复盘才发现旧的服务端令牌在轮换窗口里仍然有效，等于什么都没换。现在的规矩是凭据轮换必须带上"作废旧令牌"的确认步骤。
整件事里最值得写进采购评估表的，是缺明细带来的时间差。没有逐条用量，用户就无法区分"我自己跑多了"和"别人在花我的钱"。
TechCrunch 就"用户如何识别滥用"向平台方提问，对方拒绝置评。这位顾问的结论说得更直：他不认为这些用户有任何自我保护的办法。最终他取消了订阅，转用可以在多个模型间切换的工具。
对企业采购者来说，下面三行可以直接写进评估表：是否提供带时间戳的用量明细或对账导出；是否支持额度阈值告警与 Webhook 回调；发现异常后是否有明确的工单通道与响应时限。这三项缺任何一项，事故的发现时间都不由你掌握。
以下几条按"出事时的损失面"排序，前三条优先做。
我们给企业客户做 AI 工具链权限治理时，通常先把"账号归谁、令牌存哪、异常谁看"这三问的答案落成一张表，再谈优化。如果你的团队也在用订阅制的编程助手提效，可以看看我们做过的AI 工具链治理相关案例，翻一翻技术博客里的同类工程复盘，或者直接联系我们过一遍权限与成本口径。
不能单独挡住。会话态与已铸造的令牌往往是独立凭据，改口令不一定让它们失效。必须同时作废全部会话和服务端令牌，并撤掉陌生授权。
因为多数订阅制服务只按周期汇总总用量，不提供逐条调用明细。你看到的是总量曲线，无法归因到具体会话或客户端，所以盗刷可以潜伏较长时间。
它被设计成长期有效、可在无人值守环境下调用，权限上又等价于你自己的开发工作。攻击者拿到它不需要你的任何交互，就能持续消耗额度。
有必要，但可以从最小集合开始：账号收归组织席位、每月做一次用量对账、明确异常时谁有权作废凭据。这三条对小团队的成本接近于零。