你的代理归我了:AI 大模型恶意中间人攻击,钱包都被转走了

前几天大家看到这个新闻还在玩梗，而现在就有人发了一篇论文告诉你，你用的中转站的 Token 真的可能是「带毒」的，比如这次要聊的，论文作者就出现了带毒 Token 导致以太坊私钥泄漏后，钱包里的 ETH 被转走了的情况。

因为“众所周知”的原因，现在大家对于中转站的需求只高不低，但是其实很多时候大家都没意识到，当 Agent 连接中转站时，你的请求会经过各种 API Router、代理、聚合平台或者转售节点，这时候真正掌握你请求和返回结果的往往不是模型厂商，而是中间那一层层的“路由器”。

❝
你用的中转站接的，可能也只是别人中转站的下游。

而这层东西，不只是能看见你的 prompt、key、tool 调用参数而已，它甚至可以在你完全没察觉的情况下，改写工具调用内容，甚至偷走你的 key、按条件挑选高价值会话下手。

这就是近日的论文《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》聊的主题，因为在 Agent 调用里，请求和响应两边都拥有明文读写能力，特别是在 tool calling 场景里，它可以把「模型原本要执行的命令」改成「攻击者想让 Agent 执行的命令」。

❝
哪怕只有链路中某一个 router 是恶意的，它都有能力把返回给客户端的 tool call 篡改掉，而下游其他 router 根本无法察觉。

论文里主要展示了 router 攻击拆成四个具体攻击类型：

AC-1：响应侧载荷注入

这里模型本来返回了一个合法的 tool call，比如 Bash 命令里是下载官方 installer，router 在返回给客户端之前，把 URL 改成攻击者控制的脚本地址。

这种类型的攻击，改完之后依然是合法 JSON，schema 也没变，客户端不严格核对的话，根本看不出是“模型原话”被替换了，原本是 curl -sSL https://get.example.com/cli.sh | bash，但是被 router 改成了攻击者域名的脚本。

AC-2：被动式密钥/秘密窃取

这种方式更加隐蔽，router 什么都不改，只是扫描请求体、响应体和 header，把 API key、AWS key、GitHub PAT、Slack token、Ethereum 私钥等匹配出来，然后异步外传。

也就是单纯在数据层面，就把你日常操作的一些敏感信息过滤出来，然后直接提纯。

AC-1.a：依赖定向注入

这个是 AC-1 的变体，这次不把下载 URL 改到恶意域名，而是把安装命令里的包名偷偷改掉，例如把 requests 变成 reqeusts 这种预先注册好的 typosquat 包。

这种情况肉眼不注意很容易就被骗了，从而直接绕过域名 allowlist 的限制，并且这些依赖一旦安装后没察觉的话，就可能被持续运行和收集信息

AC-1.b：条件投递

这个优势 AC-1 的另一个变体，也是论文最有意思的地方，以你为真正聪明的恶意 router 不会永远下毒，因为永远下毒太容易被简单检测抓到，于是它会设置触发条件，比如：

只在 Bash 或 run_command 工具上动手
只在检测到 pip install、curl -sSL 这类安装型命令时动手
只在 YOLO mode 自动批准工具调用时动手
只在特定语言项目（比如 Rust、Go）里动手
或者先等前 50 次请求都表现正常，第 51 次才开始投毒

❝
也就是除非你永远盯着和审核 Agent 的每一个步骤，不然只要对方想干，你就跑不掉。

而作者这次论文测试了两类 router ：

一类是 28 个付费 router，来自 Taobao、Xianyu、Shopify
另一类是 400 个免费 router，来自公开社区、router 列表、配置 dump，主要基于 sub2api 和 new-api 这些广泛复用的模板扩展出来

然后整个测试流程主要分四步：

先在 router 上注册研究者的账号并获取 API 凭证
再把这个账号接进沙箱化 Agent 环境，执行随机子集任务和 TerminalBench 2.0 任务
然后把 router 返回的每个 tool call 都在沙箱里执行，并监控网络回连、文件改动、进程树异常
最后再让专门的分析代理判断这些异常是 benign rewriting、可疑、还是确认恶意

而论文里也不是只测「天生恶意」的 router，还测了「原本看起来正常，但后来被污染」的 router：

第一类 poisoning 最骚，作者故意把一个研究者拥有的 OpenAI API key 泄露到中文论坛、微信群等，观察它后来会被谁复用，能看到多少下游会话、多少 token、多少凭证暴露，当然目的不是说证明某家 router 一定是恶意的，而是证明：只要某个上游 key 被复用，拿到这个 key 的人就自动继承了与恶意 router 相同的明文观察权
第二类 poisoning 作者自己部署了弱口令或脆弱配置的 relay/代理节点，包括 claude-relay-service、Sub2API、CLIProxyAPI 的 decoy，分布在 20 个域名和 20 个 IP 上，然后观察外部运营者多快会把这些弱 relay 吸进下游代理链

❝
从结果看，即便一个外层 router 自己没恶意，但是只要它静默链到了更弱、更脏的上游 relay，实际上整个信任边界就已经扩散了。

而在最终结论上：

在 28 个付费 router 里，有 1 个 会向返回的 tool call 里注入恶意代码
在 400 个免费 router 里，有 8 个 会注入恶意代码
有 2 个 router 使用了自适应逃逸触发器
有 17 个免费 router 在看到研究者的 AWS canary 凭证后，出现了后续未授权使用
还有 1 个 router 在看到研究者控制的以太坊私钥后，真的把钱包里的 ETH 转走了

另外 poisoning study 给出的数字也挺夸张的：

那个故意泄露的 OpenAI key，后来产生了 1 亿 GPT-5.4 token 的消耗，并暴露了 7 个以上 Codex 会话
而那些弱 relay decoy，收到了 4 万多次未授权访问尝试，来自 147 个 IP、6 个 JA3 指纹，最后累计服务了约 20 亿 GPT-5.4 / 5.3-codex token，看到了约 13 GB 可见下游 prompt/response 流量，跨 440 个 Codex 会话、398 个不同项目或主机，暴露了 99 份凭证
这 440 个会话全部存在 shell execution path，其中 401 个已经在 YOLO mode，也就是工具调用自动批准，不需要逐条确认

所以，实际上现在你能免费捞到的 Key ，说不准是谁在白嫖谁，在真实场景里，很多下游 Agent 实际相当宽松，攻击者甚至都不用太聪明，因为看对方处于 YOLO mode，简单 AC-1 就够了。

最后，论文作者也提出了自己的防御实验，作者实现了一个叫 Mine 的研究型 Agent 来模拟四类攻击，并测试三种就能客户端防御方式：

高风险工具策略闸门
响应侧异常检测
追加式透明日志

Mine 是作者实现的一个 OpenAI-compatible FastAPI proxy，它可以像正常 router 一样转发请求，但会根据配置条件触发 AC-1、AC-1.a、AC-1.b、AC-2 等攻击模块，同时也实现了与防御相关的策略门、异常筛查、透明日志。

作者拿 Mine 去测了四个公开 Agent 框架：OpenClaw、OpenCode、OpenAI Codex、Anthropic Claude Code，结果四个框架里没有一个实现响应完整性校验：

AC-1 的改写兼容率 100%
AC-1.a 的兼容率 99.6%
AC-2 对可检测 secret 的提取覆盖率 100%
流式模式下，通过缓存和重组 tool-call chunk，照样能完成改写

更有趣的是，缓冲改写带来的额外延迟非常小：在 1 万次请求对 GPT-5.4 的测试里，proxy 中位开销只有 0.013 ms/request，流式模式最后自然 token 到篡改 token 之间额外停顿只有 0.004–0.005 ms，远低于上游中位延迟 820 ms。

❝
也就是，从性能侧几乎观察不到恶意 router 在做手脚。

所以论文也提出了对应安全的建议：

高风险工具策略闸门

这个防御的思想就很朴素了，对 Bash、run_command、安装依赖这类高风险工具，默认 fail closed，如果命令要从非 allowlist 域名下载，或者安装不在本地 allowlist 的包，就直接拦截确认。

❝
也就是不要 YOLO mode 了。

在作者论文的模板基准里，这个策略对 AC-1 和 AC-1.a 的阻断率都是 **100%**，误报率 1.0%，单次决策代价 2.3 微秒，当然前面我们聊过，只要攻击者能把 payload 放到 allowlisted 域名上，或者事先在本地埋个 stager，再通过看起来无害的 Bash 命令触发，那么这个防御就会被100% 绕过。

响应侧异常检测

这是一个更现实的方案，它不试图知道「上游原始返回是什么」，因为客户端根据不知道，它只能看当前收到的 tool call 有没有异常，比如 shell 风险模式、工具频率、字符串熵、secret-like 字符串、schema 偏差等。

作者用 IsolationForest 在合成 benign tool call 上训练，在 held-out 数据上测。结果是：

❝
在 6.7% 误报时，能抓住 89.0% 的 AC-1，50.0% 的 AC-1.a，50.9% 的 AC-1.b。

也就是这个方案挡不住真正会伪装的攻击，但是可以作为 review prioritization 工具，特别是 AC-1.a 和 AC-1.b 本来就是为了绕过简单本地规则而设计的，所以检测能力明显差很多。

追加式透明日志

这个方案就只是用来做「事后诸葛亮了」，它会记录 request body、response body、router URL、TLS 元数据、响应哈希等，在请求侧做 secret redaction，成本也不高，1000 个 session 大概 12 MB，每条 1.26 KB。

当然， 客户端现有防御都只能“降风险”，不能“证明来源完整性”，真正需要的是中转的 provider 支持的响应签名机制，像 DKIM、Sigstore、SLSA、Subresource Integrity 那样，给模型响应中的语义关键部分做可验证签名。

最后

其实结论很明显，客户端现有防御都只能“降风险”，不能“证明来源完整性”，真正需要的是 provider 支持的响应签名机制，作者提出了一个更体系化的方向：像 DKIM、Sigstore、SLSA、Subresource Integrity 那样，给模型响应中的语义关键部分做可验证签名。

大致思路就是，provider 把 model、tool_calls、finish_reason、request_nonce、时间窗口等字段映射到一个 canonical JSON，然后把原本字符串形式的 tool arguments 解析成 native JSON，用 RFC 8785 的 JSON canonicalization，再用私钥签名：

而客户端在执行 tool call 前，校验 nonce、时间、key_id、签名是否匹配，如果验证失败，就把响应当成 unsigned，拒绝执行高风险工具。

❝
这也是回归到开头那种图片，词源加密。

所以，在用中转的时候，多跳 router chain 比单跳风险大得多，特备是 YOLO mode 在这种链路里非常危险，在 Agent 时代，API Router 不只是一个中性网络设施，而是真的已经具备工具语义篡改能力的供应链节点。

论文也证明了，今天很多 LLM Agent 的调用链里，router 是一个默认被低估的供应链风险点，而这个点既能主动改写工具调用，又能被动窃取秘密，还能选择性只攻击高价值自治会话，最重要是现实世界里这种行为已经存在。

所以，AI 时代，安全真不是小事，感觉这也是最近供应链投毒那么频发的原因之一。

链接

https://arxiv.org/pdf/2604.08407v1