蒸馏攻击1.51亿次｜API Key治理避坑清单

前沿模型实验室披露了一批针对其模型的蒸馏攻击：数月内识别出近 2 亿次相关交互，规模最大的一场被归因于单一组织，2026 年 5 月到 7 月约 1.51 亿次交互、峰值每天接近 300 万次，分布在 3,500 个不同账户上。攻击者抽取的是模型思维链，用来微调出更小的替代模型。这事对多数开发者的直接感受是"跟我无关"，但把视角换成平台方：3,500 个账户里任何一个，都可能是被拖库的普通接入方。这篇把攻击链拆开，换成 API 接入侧的 Key 治理、行为审计和异常发现清单，全部动作在 4sapi（https://4sapi.com）这类中转接入架构里都能落地。

一、开篇痛点：我的 Key 到底会被谁、怎么用掉

API 接入方在这类事件里是被动角色。Key 泄露的路径很日常：前端代码里硬编码、日志文件里明文打印、团队成员离职没回收、仓库历史提交里躺着一份 .env。泄露之后的消耗方式更日常：攻击者拿批量 Key 做蒸馏式高频调用，单账户消耗不大、请求模式规整，账单曲线要过好几天才显形。

真正的痛点不是泄露本身，而是发现得太晚。等到月底对账看到异常，消耗已经发生；等到供应商发来风控邮件，账户可能已经被限制。我在 4sapi 维护多模型中转时处理过的情况里，从 Key 泄露到被发现的中位时间是以天计的，而自动化攻击完成一轮批量抽取只需要几个小时。治理的目标就是把这段时间差压到分钟级。

二、原理速览：蒸馏攻击链长什么样

把披露信息里的攻击链画出来：

text

攻击组织
   │  注册/收购 3500 个普通账户
   ▼
大量小账户池 ──► 每账户低频调用，行为规整
   │
   │  共享同一套提取提示词（伪装成翻译请求等）
   ▼
目标模型泄露思维链 ──► 收集响应 ──► 监督微调小模型

三个特征值得记住。第一是"化整为零"：不用一个超级账户硬冲，而是把流量摊到几千个普通账户上，单账户看起来正常。第二是"提示词同源"：3,500 个账户共享同一套用于提取思维链的提示词——例如把查询伪装成"把工作记忆翻译成片假名"的翻译指令——这是平台侧识别的最强信号，也是接入侧能借鉴的特征工程思路。第三是"目标明确"：抽的不是答案，是思维链，请求内容有很强的结构性（要求模型输出推理过程）。

平台侧能靠全量流量关联识别这种模式，单个接入方看不到全局，但接入方有自己的优势：自有的业务上下文。哪些请求合理、哪些请求越界，业务侧比平台更清楚。

三、角色对照：平台风控能看到的 vs 接入方能看到的

观测面	平台风控	接入方（中转/业务侧）
账户关联	跨账户行为聚类，能看出 3,500 个账户同源	只有自己的 Key，看不出别人
提示词指纹	全量请求去重，同源提示词一眼识别	能看到自己入口的提示词分布
消费速率	全局阈值，覆盖海量账户	精确到单 Key、单项目、单环境
数据边界	不知道请求内容是否属于业务	知道业务该问什么、不该问什么
泄露发现	账户行为异常才触发	Key 出现未知 IP、未知 UA、异常时段即触发

结论很清楚：平台的强项是全局关联，接入方的强项是业务上下文。两边不互替，接入方要把自己的强项用足。

四、Key 治理：从"一把钥匙开所有门"到分域管理

第一步是把 Key 的生命周期管起来。一个基本的分配原则：

text

项目维度拆分 Key
   ├── 生产环境 Key：独立预算、独立限额、最小权限
   ├── 测试环境 Key：低限额，过期自动作废
   ├── 个人调试 Key：绑定到人，离职回收
   └── 第三方集成 Key：限定模型白名单与调用频次

对应的治理清单：

按项目、按环境拆 Key，每个 Key 挂独立预算与限额，单 Key 失守不影响全局。
Key 不进代码库：环境变量或密钥管理服务注入，CI 里加一层密钥扫描防误提交。
定期轮换：生产 Key 按月或按季轮换，轮换窗口双 Key 并行，切换无痛。
离职即回收：Key 与人员绑定，入离职流程里加一项 Key 审计。
最小权限：第三方集成只开它需要的模型和频次，不开全家桶。

我在 4sapi 的中转后台给每个下游项目发独立 Key 时，顺手把"单 Key 日消耗上限 + 峰值 QPS 限制"设成默认值，下游要提额走工单。这个默认值挡住过至少一次测试环境配置错误引发的循环调用。

五、行为审计：把"规整得可疑"的流量识别出来

蒸馏攻击在接入侧的镜像特征是：请求模式过于规整。正常的业务流量有长尾——有人问短句、有人贴长文档、时段随业务波动；攻击流量往往提示词同源、参数固定、时段均匀。审计层要抓的就是这种"不像人的规整"：

python

# 请求指纹审计：按 Key 维度统计请求相似度与节奏
from collections import Counter

def audit_key_behavior(logs: list[dict]) -> dict:
    """logs: [{key_id, prompt_hash, hour, tokens_in, tokens_out}] 演示结构"""
    by_key = {}
    for log in logs:
        k = log["key_id"]
        by_key.setdefault(k, []).append(log)

    alerts = {}
    for k, items in by_key.items():
        # 信号一：提示词哈希高度集中（同源提示词）
        hash_ratio = max(Counter(i["prompt_hash"] for i in items).values()) / len(items)
        # 信号二：调用时段过于均匀（夜间占比异常）
        night_ratio = sum(1 for i in items if 2 <= i["hour"] <= 6) / len(items)
        # 信号三：输入输出比异常（思维链抽取类请求常见长输出）
        io_ratio = sum(i["tokens_out"] for i in items) / max(sum(i["tokens_in"] for i in items), 1)
        if hash_ratio > 0.5 or night_ratio > 0.4 or io_ratio > 3:
            alerts[k] = {"hash_ratio": round(hash_ratio, 2),
                         "night_ratio": round(night_ratio, 2),
                         "io_ratio": round(io_ratio, 2)}
    return alerts

阈值全部是演示值，含义比数值重要：提示词同源、时段异常、输入输出比畸形，三个信号各自独立报警，命中两条以上就人工复核。审计记录本身要脱敏保存——记 prompt_hash 不记原文，记 token 数不记内容，审计日志的访问权限同样要管。

六、预算熔断：异常消耗的最后一道闸

发现之后要能止损失。熔断设计三件事：

层级	触发条件	动作
单 Key	日消耗超预算 120%，或 QPS 超限	自动降限额，告警通知
单项目	周消耗环比涨幅超 80%	暂停非核心模型，人工复核
全局	账单日增速超历史 P95	高风险模型停用，全量告警

熔断的常见坑有两个。一是阈值拍脑袋定：应该用历史流量分布（比如 P95）做基线，而不是统一常数。二是熔断后没有演练过的恢复流程：恢复要人工复核，风暴期不做自动放行，避免攻击者用间歇流量骗过自动阈值。熔断动作本身也要记账——每次触发的时间、原因、处置人、恢复时间都进审计日志，这套记录既是对内复盘的素材，也是向供应商申诉误判时的凭据。

七、第三方中转选型的安全尽调

接入聚合类中转服务时，安全尽调看四件事。一看凭证机制：是否支持独立子 Key、能否按 Key 限额与熔断，只给一把共享主 Key 的服务直接排除。二看日志政策：请求内容保存多久、是否明文、审计接口是否开放——这决定了泄露事件发生后能不能追溯。三看上游透明度：明示上游渠道与合规承诺的服务，出问题时才有得谈。四看风控联动：滥用告警能否推送到下游，还是只能等封禁短信。

这四条的优先级高于价格差。一个单价便宜两成但没有子 Key 机制的服务，意味着熔断粒度从"单个项目"退化到"整个公司"，一次异常消耗就能拖垮全部业务；省下的差价远不够抵一次事故的损失。尽调结论写成一页纸存档，换供应商时直接对照，不用每次从头开始。

八、Agent 业务调模型时的取数防护

Agent 业务是 Key 治理的特殊场景：模型在执行中会主动抓网页、拉接口、读文档，取回来的内容原样进入上下文。攻击面从这里扩展——网页里可能埋着注入文本，诱导模型带着 Key 去访问不该访问的地址，或者把上下文里的敏感信息转存到外部服务。

防护动作有三个。Agent 的工具调用走独立低权限凭证，与主业务 Key 物理分离，即使被诱导，能碰到的资源也有限。外部内容进上下文前过一遍标记与清洗，外部数据永远只当数据不当指令，这条规则写进系统提示也写进工具层。工具白名单收敛，Agent 能访问的域名与接口显式列出，清单外一律拒绝，拒绝事件进审计日志。

披露案例里 Agent 把公共服务当免费基础设施用的教训就在眼前：取数行为的边界不在模型自觉，在工具配置。工具清单每季度随业务复盘一次，下线功能的取数通道同步关闭。

九、合规边界：不做什么

不做也不鼓励任何蒸馏、套取思维链、绕过供应商反滥用机制的操作；这类行为违反服务条款，披露案例里已经是被点名追责的对象。
接入别人家中转服务时，确认上游来源合法；采购聚合服务优先选明示上游渠道、有合规承诺的供应商。
自家平台被滥用时，配合供应商风控流程处置，不做"装没看见"。Agent 业务接第三方工具时，工具的行为同样纳入审计范围——披露案例里 Agent 把公开服务当免费基础设施用的行为，责任照样追到运营方头上。

十、成本与风险提示

披露中的数字（1.51 亿次交互、3,500 账户、2 亿次总量）来自实验室单方口径，具体归因存在争议，引用时保留这一保留意见。
审计脚本为演示代码，阈值与特征需按自身业务流量分布重新标定，直接套用会误伤正常用户。
Key 治理措施有运维成本：拆 Key、轮换、审计都会增加管理复杂度，小团队可以从"拆 Key + 预算熔断"两件最低成本的事做起。
只讨论合法接入、防护与合规治理，不提供任何攻击或滥用的实现细节。

总结

这期把一桩前沿实验室披露的蒸馏攻击事件，翻译成了 API 接入侧的三件事：Key 治理（按项目与环境拆分、轮换、回收、最小权限）、行为审计（提示词同源、时段异常、输入输出比畸形三个独立信号）、预算熔断（单 Key、单项目、全局三级触发，恢复走人工复核）。攻击者的手法在进化，平台的风控在加码，接入方能做的就是把自家的钥匙管好、把自家的流量看住、把损失的上限锁死。这套清单来自我在 4sapi（https://4sapi.com）维护多模型中转的日常治理实践。

欢迎在评论区聊聊各家的 Key 管理做法，以及有没有遇到过异常消耗的惊魂时刻。