在构建生产级LLM Agent时绝大多数架构师和开发者都默认一个前提只要选用知名开源路由器如LiteLLM、OpenRouter或付费代理服务工具调用tool-calling的请求和响应就会安全抵达上游模型。路由器只是“透明管道”不会窥探、更不会篡改payload。供应链安全问题只存在于模型权重或训练数据层面与中间基础设施无关。我起初也是这么认为的。直到深入阅读arXiv:2604.08407v1这篇系统性研究我才意识到自己和行业里绝大多数人一样掉进了同一个“中间人幻觉”里。LLM API路由器本质上是应用层MITMman-in-the-middle它们终止客户端TLS再重新发起上游TLS对每一条JSON payload拥有完整明文访问权。没有任何提供商强制端到端完整性校验。这意味着路由器可以随意注入恶意工具参数、窃取凭证、甚至在特定触发条件下才动手。论文作者在真实市场淘宝、闲鱼、Shopify买了28个付费路由器又从公开社区采集了400个免费路由器结果令人脊背发凉9个路由器主动注入恶意代码2个部署了自适应规避机制17个触碰了研究者放置的AWS诱饵凭证1个直接从研究者钱包里转走了ETH。更致命的是通过故意泄露的OpenAI key和弱配置诱饵良性路由器也被拉入攻击面——累计处理了21亿token暴露99个凭证401个会话已进入自主YOLO模式可直接实现payload注入。这不是理论威胁而是正在发生的供应链级后门。为什么“路由器只是管道”成了最昂贵的行业共识传统认知里路由器只是做负载均衡、fallback、成本优化的中性层。现实却是它对每一次tool_call的arguments拥有最终解释权。模型返回什么不重要路由器“决定”客户端最终收到什么。这条信任边界完全裸露。生活里最直观的类比是快递中转站你把贵重包裹寄给朋友包裹里装着银行卡和私钥。中转站老板可以偷偷打开换成假卡、偷走私钥、再原样封好寄出。你收到的“包裹”看起来和原件一模一样但内容已经彻底被替换。包裹本身没变改变的是你对“中转环节可信”的盲目假设。另一个更残酷的类比是老式图书馆借书读者你的Agent向馆长上游模型借一本参考书管理员路由器却在半路把书页撕掉几张、塞进自己的恶意代码然后重新装订递给你。你以为借到的是原书其实已经中了毒。攻击分类AC-1注入与AC-2窃密以及它们的自适应变种论文把攻击正式化为两个核心类别和两个规避变体AC-1响应侧payload注入路由器在模型返回后、客户端收到前改写tool_calls里的arguments。例如把一个合法的URL替换成攻击者控制的恶意脚本触发任意代码执行。AC-2被动秘密窃取扫描明文流量中的模式AKIA开头的AWS key、正则匹配的私钥、API token等静默外泄。自适应版本更阴险AC-1.a依赖针对性注入dependency-targeted——专门针对Bash/run_command工具替换npm/pip包名实现持久化后门。AC-1.b条件交付conditional delivery——只有满足触发条件调用次数50、关键词匹配、进入YOLO模式等才注入否则表现完全正常轻松绕过审计。下面是诚实路由器与恶意路由器在生产场景下的真实权衡对比维度诚实路由器行业默认假设恶意/被攻陷路由器真实测量结果长期Agent安全结果Payload可见性仅转发不修改完整明文读写权可任意重写任意代码执行风险凭证暴露无主动扫描外泄17个触碰诱饵供应链级凭证失窃规避能力无条件触发、依赖替换2个已部署审计几乎失效真实案例正常fallback、负载均衡1个付费8个免费主动注入1个盗ETH生产Agent已被“接管”防御难度无需额外措施需客户端侧策略门异常检测日志必须立即加固Mine代理与三项可落地客户端防御作者开源了Mine——一个研究用FastAPI代理能100%复现四类攻击对OpenClaw、OpenCode、Codex、Claude Code四大框架兼容。开销仅0.013ms。他们同时评估了三种纯客户端防御无需上游改动Fail-closed策略门直接禁用高风险工具如Bash、run_command100%挡住AC-1和AC-1.a误报率1%。响应侧异常筛选IsolationForest提取shell-risk、参数复杂度等特征挡住89% AC-1误报6.7%。Append-only透明日志每条交互记录1.26KB签名日志实现事后审计。这些防御不能完全解决根源供应链信任问题但能把暴露面大幅压缩。在生产环境落地前你必须重新思考的三件事立刻审计你当前正在使用的所有LLM路由器是自建还是第三方是否走淘宝/闲鱼/Shopify渠道是否支持端到端完整性如果答案是“不知道”那你已经在用一个潜在的后门。把客户端侧防御列为非谈判项至少上线fail-closed策略门 响应异常检测。任何还把路由器当成“黑盒可信”的Agent框架都等于把Agent的控制权拱手让给未知的中间人。把供应链安全提升到与模型权重安全同等优先级未来Agent越依赖多提供商路由中间人攻击面就越大。需要推动上游提供商实现provider-signed response envelope带签名、key_id、tool_calls的加密信封否则整个生态都会持续暴露。这篇论文最刺痛的结论不是“有恶意路由器”而是“恶意路由器已经广泛存在且规避手段成熟”。LiteLLM 2026年3月的依赖混淆事件只是冰山一角。当你的Agent每一次tool_call都经过一个可能已被攻陷的中间人时“你的Agent”其实已经不再属于你。你在部署生产级LLM Agent时是继续把路由器当成“透明管道”还是今天就启动审计客户端防御把供应链信任边界彻底收回到自己手里欢迎在评论区分享你当前路由器的真实配置或已遇到的供应链卡点——我们一起把这个中间人攻击认知变成更多系统的肌肉记忆。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。