恶意 LLM API 路由器：智能体栈中无人监管的中间人

这是什么？

LLM API 路由器是一个位于您的智能体与上游模型提供商（OpenAI、Anthropic、Google 等）之间的代理，用于处理负载均衡、多提供商故障切换、成本跟踪与速率限制。LiteLLM 式网关以及”兼容 OpenAI 的 base URL”模式在智能体栈中随处可见，开发者会自愿将客户端指向这些端点。

在 《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》（arXiv:2604.08407，2026 年 4 月 9 日提交）一文中，加州大学圣巴巴拉分校的研究人员对这一攻击面进行了首次系统性研究。他们从淘宝、闲鱼以及 Shopify 托管店铺等市场购买了 28 个付费路由器，并从 GitHub 和公共社区收集了 400 个免费路由器。该结论被 CybersecurityNews（4 月 10 日）与 Risky Business（4 月 15 日）转载：这些中介中有相当一部分是主动恶意的。

工作原理

结构性问题在于缺失完整性保证。路由器终止客户端的 TLS 连接，再向上游提供商重新发起一条新连接，因此它对每一个在途 JSON 负载都拥有明文访问权限。与传统的网络中间人攻击不同，无需伪造任何证书——是开发者自己把该代理配置成了 API 端点。而且没有任何主流提供商会以加密方式将智能体执行的工具调用与模型的真实输出绑定。在恶意路由器与请求/响应流之间，什么都没有。

论文形式化了两类核心攻击：

• 负载注入（AC-1）——路由器重写返回的工具调用，例如把一个良性安装程序 URL 或软件包名替换为攻击者控制的版本。由于被篡改的 JSON 在语法上仍然有效，它能通过模式校验；一条被重写的 shell 命令就足以在客户端执行代码。
• 机密外泄（AC-2）——路由器在不改动任何响应的情况下，被动地从明文流量中收集 API 密钥和凭据，因此下游行为看起来完全正常。

两种自适应变体进一步抬高了检测门槛：针对依赖的注入（AC-1.a）与条件投递（AC-1.b），其中负载只在一段干净历史之后（例如 50 次请求）才激活，或只针对工具执行被自动批准的自主”YOLO 模式”会话。

在测试的 428 个路由器中，团队报告：9 个主动注入恶意代码（1 个付费、8 个免费）、2 个使用自适应规避触发器、17 个免费路由器触及了研究人员自有的 AWS”金丝雀”凭据，以及 1 个清空了研究人员自有私钥中的 ETH。本文不复现任何攻击负载，理解教训也并不需要它。

为何重要

影响半径远不止于单个失陷端点。路由器构成了一张代理节点网格，流量会根据负载在它们之间跳转，因此单个被攻陷的节点可以让其他路由器代为转发其恶意命令，从而触及一个组织的整个智能体集群。一个薄弱节点就能破坏整个成本控制层，并使其后面的每一位用户暴露在风险中。

两项投毒实验表明，即便是看似良性的路由器也会被卷入同一攻击面。在团队故意将一把研究人员自有的 OpenAI 密钥泄露到中国论坛和即时通讯群组后，该密钥生成了约 1 亿个 GPT-5.4 token，并在多个下游 Codex 会话中暴露了凭据。第二项部署薄弱诱饵代理的研究吸引了约 40,000 次未授权访问尝试，提供了约 20 亿个计费 token，在 440 个 Codex 会话中暴露了 99 个凭据——而且这 440 个会话中有 401 个已在自主 YOLO 模式下运行，其中命令无需逐次确认即被执行。

这与业界已在跟踪的供应链风险和过度自主性风险直接吻合。危险的组合是：高自主性智能体 + 不可信中介 + 自动批准的工具执行——参见我们对致命三要素以及 Meta 智能体二选二规则的报道。

防御

研究人员说得很清楚：在没有提供商支持的情况下，任何客户端控制都无法完全验证返回工具调用的来源。不过，以下三项措施今天就能部署，无需提供商配合：

• 失败即关闭（fail-closed）的策略闸门。 仅允许来自本地白名单的命令；论文称这能以约 1.0% 的误报率阻断 shell 重写和依赖注入攻击。注意：若攻击者将负载托管在已被加入白名单的域名上，则可被绕过——因此应将白名单与固定且经过验证的软件包来源相结合。
• 响应端异常筛查。 一个基于良性工具调用模式训练的 IsolationForest 模型，在 6.7% 的误报预算下标记出了约 89% 的负载注入尝试。将路由器响应视为不可信输入，在任何工具据此行动之前先行筛查。
• 仅追加（append-only）的透明日志。 记录完整的请求/响应元数据、TLS 数据和响应哈希（每条约 1.26 KB），以便事后对事件进行取证性范围界定。

除此之外，运营卫生很简单：把每一个第三方路由器都当作潜在对手对待。 优先使用提供商的直连端点或您自己掌控的自托管网关；按最小权限限定 API 密钥并积极轮换；切勿让智能体在自动批准/YOLO 模式下访问您并不运营的端点；并对不可逆操作（安装软件包、转移资金、使用凭据）要求人工确认。作者认为，持久的修复在于由提供商签名的响应信封——一种”面向工具调用的 DKIM”机制，以加密方式将已执行的工具调用与上游模型的真实输出绑定。在提供商交付该机制之前，分层的客户端控制就是防线。

状态

项目	详情
来源	arXiv:2604.08407，加州大学圣巴巴拉分校
披露	2026 年 4 月 9 日（预印本）
测试路由器	28 个付费 + 400 个免费（共 428 个）
恶意代码注入	9 个路由器（1 付费、8 免费）
自适应规避	2 个路由器
凭据访问	17 个路由器触及 AWS 金丝雀；1 个清空 ETH
提供商修复	暂无——客户端↔上游之间无加密完整性
客户端防御	策略闸门、异常筛查、透明日志

正确的框定不是”存在一些可疑代理”，而是：LLM 路由器是一个由开发者引入、长期存在且缺乏完整性保证的信任边界，而高自主性智能体使其失陷的代价异常高昂。请像挑选依赖项那样审慎地挑选您的中介——因为从功能上讲，它们本就是依赖项。