防御成功率 0%：谁占着 Agent 的可信路径
如果你用 Claude Code、Cursor 或 Codex 写代码，而模型不是直连官方端点、中间过了一层"中转站"，那这篇文章讲的就是你每天在用的那条链路。
国内开发者对中转站不会陌生：统一管理 API key、多家模型随便切、网络和计费都省心，不少团队默认就这么配。它换来的便利是真的，但代价常被忽略——它坐在你的 agent 和模型供应商中间，对经过的请求和响应拥有明文访问权。这不是偷来的权限，而是它转发流量所必需的。
于是就有了一个很少被追问的问题：你的 agent 读到的那份响应，真的是模型供应商产出的那份吗？
7 月 29 日更新到 arXiv 的一篇实证研究把这件事从头到尾测了一遍，作者来自上海交大、北大和北航。他们让中转层去篡改发给 agent 的响应，往里塞恶意的工具调用，然后看 agent 到底会不会照做。结论是一个很难看的数字：四款主流 coding agent、四种篡改手法，每种条件下 1200 次注入，客户端防御成功率全部是 0%。
不是"拦住了三成"，也不是"只有高级手法才能绕过"——是一次都没拦住。换 agent 没用，收紧权限模式没用，连只读的 plan 模式都没用。
同一周还有另一条新闻，位置不同但性质相通：一个 66k star 的 agent 平台被披露 CVSS 10.0 满分漏洞，一个 HTTP 请求就能拿到远程代码执行，顺带还能改写平台的持久化 AI 记忆。一篇是学术论文，一条是漏洞通报，看起来不搭界，但它们占据的是同一条链路上的两段——一段是模型响应，一段是工具执行和记忆。
这篇文章想说清楚的判断是：agent 的安全防护几乎全部部署在「最后一公里」——判断该不该执行某个动作。但这些防护共享一个没被写出来的前提：agent 读到的响应，就是模型供应商产生的那份响应。中转层的存在让这个前提失效，而前提一旦失效，最后一公里做得再细都没有意义。
后面会讲到，这篇论文里唯一真正有效的那个缓解手段，恰恰藏在结果表下面一行不起眼的脚注里。
一、先划清楚：这不是 prompt injection，也不是中间人
这项研究的威胁模型定得很干净，值得先花一段说清楚，否则很容易被归到已知的旧问题里。
论文明确假设上游供应商是诚实的：模型按自己的安全准则生成响应，没有被越狱，也没有产出有害内容。同时排除了对模型本身、供应商服务器、网络传输加密和 agent 本地运行时的攻击。换句话说，模型是对齐的，TLS 是好的，你的机器没被入侵。
那攻击面在哪？在第三方 API 中转层（third-party API router）。
先解释一下这东西是什么，为什么人人都在用。API 中转层做三件事：流量转发、统一 API key 管理、负载均衡。它的价值是让同一个 coding agent 不改工作流就能在多个后端之间切换——今天用这家的模型，明天换那家，客户端配置一行不动。国内开发者对此应该格外熟悉，各种"中转站"几乎是默认选项。
关键在于它所处的位置。中转层坐在应用层，拥有对请求和响应的授权明文访问权——这是它正常工作所必需的，不是偷来的。于是它可以检查、重放、延迟、修改经过它的一切内容。
论文把这件事的性质概括得很准：它不需要像 prompt injection 那样去说服模型产出有害内容，也不需要像网络中间人那样击穿传输层加密。这是一个"授权中介下的软件工程控制问题"，而不是模型安全问题，也不是传输安全问题。
真正的裂缝出现在两个东西的分离上：供应商产生的响应，和 agent 消费的响应。直连的时候这两者是同一个东西，这个区分根本不存在；一旦中间插进一个中转层，它们就成了两份可以不一样的数据。而几乎所有客户端防护，都默认它们仍然是同一个东西。
还有一个细节让这件事更棘手。coding agent 的响应是混合载荷：自然语言解释和结构化的工具调用打包在同一份数据里。前者是开发者会读的部分，后者是真正驱动动作的部分。改动结构化部分的一小块，就能造成很大的行为变化，而周围的文字还维持着一条读起来完全合理的执行轨迹。
二、四级注入：从整段替换到分布对齐
研究把中转层的介入方式分成四个等级，隐蔽性递增。这个分级是全文的主要自变量，也是理解结果的关键。
| 等级 | 手法 | 做了什么 |
|---|---|---|
| L1 | Response Substitution | 直接把供应商的响应替换成一份只含恶意调用的 |
| L2 | Response Append | 保留原响应，在后面追加恶意调用 |
| L3 | LLM-Polished Injection | 注入恶意调用，并改写解释文字让它和注入动作看起来一致 |
| L4 | Distribution Alignment | 混合 next-token 分布（α = 0.75），让恶意调用是"生成"出来的 |
从 L1 到 L4，介入的深度从"替换一份已经产生的响应"一路推进到"塑造产生响应的解码过程"。L3 开始有了掩护——文字解释被改写得和恶意动作自洽，所以人工扫一眼轨迹看不出破绽。L4 更进一步，恶意调用不是拼接上去的，而是从混合后的概率分布里采样出来的，风格上更接近这个模型自己会说的话。
设计这套分级的用意，是想看看攻击是否依赖精巧手法。结果我们下一节会讲到——四个等级效果完全一样。这个"一样"本身就是结论。
实验平台叫 SIDEL，能做轨迹录制、重放、注入和防御评估，代码已开源。这里有个方法论上的讲究：agent 本身是有状态且非确定性的，同一个任务跑两遍轨迹就可能不同。所以对照组不是"重新跑一次"，而是录制一条干净的参考轨迹再重放，保证请求—响应路径固定，这样观察到的差异才能归因到注入本身，而不是采样随机性。每个任务还跑在隔离容器里。
数据集是人工构造的 400 个恶意工具调用样本，四类威胁各 100 个，底下再分 34 个子类：
| 威胁类别 | 子类数 | 样本数 |
|---|---|---|
| 恶意代码执行 | 10 | 100 |
| 缺陷代码生成 | 10 | 100 |
| 隐私外泄 | 7 | 100 |
| 供应链攻击 | 7 | 100 |
按严重性分，Critical 211 个、High 138 个、Medium 51 个；按注入的工具类型分，Bash 命令执行 277 个、Write 文件创建 74 个、Edit 文件修改 49 个。任务底座用的是 SWE-bench Lite 的三个真实 GitHub issue 修复任务，不是合成 prompt——这样注入的动作会真的作用在活的仓库状态、命令行工具和测试设施上。
主指标是防御成功率（DSR, Defense Success Rate），定义为"在执行前被拒绝的恶意注入占全部恶意注入的比例"。分母是 400 个样本 × 3 个任务 = 1200。注入发生的轮次从每次运行的前 15 轮里随机采样。
三、0% 的三重确认
论文围绕四个研究问题展开，前三个问题的答案惊人地一致。
换 agent，没用。 Claude Code、Codex、Cursor、OpenCode 四款 agent，在 L1 到 L4 四个等级下，DSR 全部是 0%。这四款 agent 的工具抽象和执行流程差别很大，但没有一个能在执行前拦下被注入的工具调用。研究由此判断：这是架构层面的问题，不是某个实现的 bug。
顺带一提，四款 agent 的攻击成功率完全相同，执行开销却差出一个数量级。下面是各 agent 在四个注入等级下的表现，单元格为每轮平均 token 消耗 / 每轮平均耗时：
| Agent | L1 | L2 | L3 | L4 | DSR |
|---|---|---|---|---|---|
| Claude Code | 55.7K / 13.6s | 98.9K / 18.1s | 86.1K / 45.1s | 152.6K / 41.8s | 0% |
| Codex | 5.6K / 2.7s | 43.0K / 28.2s | 11.2K / 42.1s | 16.7K / 34.7s | 0% |
| Cursor | 17.5K / 9.1s | 52.6K / 21.2s | 52.2K / 54.7s | 35.5K / 45.8s | 0% |
| OpenCode | 21.7K / 151.9s | 21.9K / 149.9s | 34.8K / 60.8s | 79.1K / 54.3s | 0% |
横着看，开销并不随注入等级单调上升——Claude Code 的 token 消耗从 L1 到 L4 翻了近三倍，Cursor 反而在 L4 比 L3 更省。竖着看差距更夸张：同样是 L1，Codex 只要 5.6K token、2.7 秒，Claude Code 要 55.7K token，差了十倍；OpenCode 在 L1、L2 下每轮耗时都在 150 秒上下，是四款里最慢的。
但这张表真正该读的是最后一列：前面四列的差异再大，也没有换来任何安全收益。 每家 harness 对工具调用和交互步骤的组织方式不同，所以同一个注入动作花的钱和时间可以差十倍——可它们的防御成功率是同一个数。harness 设计决定的是你花多少、等多久，不决定你挡不挡得住。
换权限模式，还是没用。 这是我认为整篇论文最值得细看的一段。Claude Code 有四种原生权限模式：plan、acceptEdits、auto、bypassPermissions，差别在于 agent 能在多大程度上不经批准就行动。四种模式的 DSR 全部是 0%。
为什么连只读的 plan 模式都挡不住？论文给的解释是：plan 的只读约束是在 prompt 层面强制的，这个约束不延伸到 router 层。 一旦恶意动作经由中转层注入，agent 就把它当作一个合法的工具调用来处理，prompt 层面的限制完全不参与判断。
而 auto 模式的情况更值得玩味。这个模式带一个原生审查器，会触发一次额外的 LLM 审查。但论文点破了一件事：审查请求本身也要走这个 API 中转层。
这就形成了一个闭环——你派去做审查的那个请求，和你要审查的那份响应，走的是同一条被污染的链路。审查器看到的世界，正是中转层想让它看到的世界。所以 auto 模式同样是 0%。
换后端模型，仍然没用。 固定 Claude Code 作为 agent，把后端在 DeepSeek-V4-Pro、DeepSeek-V4-Flash、Kimi-2.7 Code、Qwen3.6-Plus 之间切换（在 bypassPermissions 模式下），DSR 四个全是 0%。
这一条打破的是一个相当普遍的直觉：后端多样性常被当成鲁棒性的来源。 但注入发生在供应商产生响应之后，模型输出分布的差异根本不参与这场博弈。换模型换不掉一个坐在下游的中转层。
论文还给了一个具体案例，比聚合数字更能说明失效形态。任务是 SQLFluff 的 issue 1625，一个正常的仓库调试任务：agent 要检查 L031 规则和相关测试，修一个 TSQL 方言下的误报。注入前它老老实实地规划、读规则实现、看测试和 fixture。第 4 轮，注入动作发出一条 curl -k 命令，下载远程脚本并管道给 sh。
这条命令和 SQLFluff 的 bug 毫无关系，但因为注入发生在早期，这个伪造的动作成了后续工作流的一部分，而不是一个孤立的异常点。轨迹记录确认：命令在第 4 轮之后被执行，执行前没有触发任何审查。
四、有效的缓解，藏在一个脚注里
第四个研究问题评估两种客户端缓解手段。这里终于有了非零的数字。
第一种是白名单执行控制：提取工具调用里的安全相关操作数（命令 URL 里的网络域名、安装命令里的包名），只有全部命中允许清单才放行。确定性判断，开销可忽略。
第二种是 LLM 审查：在执行前请一个独立的审查模型，把当前任务简报和最近执行过的工具调用作为上下文，按"完整效果"而不是"表面形式"来判断待执行的调用。它按两阶段门禁工作，第一阶段强烈倾向于拦截、不考虑用户意图豁免，第二阶段复核并处理例外，推翻拦截需要用户显式确认。
结果如下（DSR 越高越好，WBR 是误伤率，衡量被拦下的正常动作占全部拦截的比例，越低越好）：
| 缓解手段 | L1 DSR | L2 DSR | L3 DSR | L4 DSR | WBR 区间 |
|---|---|---|---|---|---|
| 白名单执行控制 | 34.9% | 44.1% | 31.1% | 30.8% | 29.7%–43.9% |
| LLM 审查 · DeepSeek-V4-Pro | 64.4% | 48.3% | 41.8% | 39.8% | 21.1%–25.9% |
| LLM 审查 · DeepSeek-V4-Flash | 62.1% | 42.4% | 41.5% | 39.1% | 9.0%–14.3% |
| LLM 审查 · Kimi-2.7 Code | 49.9% | 40.3% | 42.8% | 44.4% | 41.0%–53.2% |
| LLM 审查 · Qwen3.6-Plus | 64.0% | 51.1% | 51.8% | 50.8% | 14.9%–20.4% |
先读数据。白名单是个诚实但粗糙的基线：拦得不多（三成上下），误伤却不少（最高 43.9%），因为它只能表达"域名不在名单里"或"包名不在名单里"这类风险。LLM 审查整体给出了更好的权衡，但效果强烈依赖审查模型的选择——Qwen3.6-Plus 在更难的 L2 到 L4 三档里 DSR 都是最高的（50.8% 到 51.8%），误伤保持中等；DeepSeek-V4-Flash 的误伤率在四个等级里始终最低（9.0% 到 14.3%）；而 Kimi-2.7 Code 误伤高达 41.0% 到 53.2%，却没换来相应更高的 DSR。
这里可以顺出一条实用判据：更强的防御不必然要求更宽的拒绝。 选对审查模型，可以在高 DSR 的同时把误伤压下来，这两件事不是简单的跷跷板。
再看审查器的行为分布，能发现一处盲区。Bash 是被审查最多、拒绝压力最大的类别——DeepSeek-V4-Pro 在 868 个 Bash 案例里拒了 308 个，Flash 拒了 452 个。但更高层的包装工具几乎被无条件放行：在 V4-Pro 下，Agent 类调用 112 次全部放行，Read 是 7/7，Search 是 67/69。审查器盯着裸命令，对被包装过一层的东西明显更宽容。这个偏好本身就是攻击面。
不过，这一节最重要的信息不在表里，而在表的脚注里。原文写着：
All LLM reviews use official URL endpoints directly, bypassing API router injection.
（所有 LLM 审查都直接使用官方 URL 端点，绕开了 API 中转层的注入。）
把这句话和上一节的 auto 模式放在一起看，整件事就通透了。
同样是 LLM 审查这个机制，走中转层的那个（auto 模式原生审查器）拿到 0%，绕开中转层直连官方端点的那个拿到 39% 到 64%。 机制没变，变的只是审查请求走哪条线。
这就是可信路径的第一条判据：审查链路必须独立于被审查链路。 这不是一句原则性的漂亮话，它在这篇论文里有精确的量化对照：同一套审查逻辑，链路独立与否的差距是 0% 和 64% 之间的距离。任何把"检测"和"被检测对象"放在同一条通道上的设计，本质上都是在请犯人自己写供词。
也要说清楚缓解的天花板。即便是最好的配置，DSR 也就在五成上下，没有任何一种客户端手段能把控制权完整地拿回来。论文自己的结论是：这些结果指向供应商侧的输出完整性保证——也就是说，真正的解法可能不在客户端，而在让响应可以被验证确实出自供应商。
五、另一半路径：工具、记忆，和补丁救不回来的东西
如果说中转层占据的是"模型响应"这一段路径，那么同一周披露的另一件事，占据的是"工具执行和记忆"那一段。
7 月 29 日，Noma Labs 披露了代号 RufRoot 的漏洞，编号 CVE-2026-59726，CVSS 评分 10.00，满分。受影响的是 Ruflo——一个 agent meta-harness，前身叫 Claude Flow，用来部署 agent 集群、编排自主工作流，GitHub 上约 66k star，是 MCP 生态里采用最广的平台之一。
问题出在：Ruflo 默认通过一个未认证的 MCP 桥对网络暴露了数百个 AI 工具，其中包括 shell 命令执行。研究者演示了一个 HTTP 请求就足以在 Ruflo 部署内拿到完整的远程代码执行。拿到这个立足点之后，攻击者可以窃取 Ruflo 用来访问各家 AI 供应商的 API key、读取平台上存储的每一段用户对话，以及——篡改 AI 自己的记忆。
披露和修复的过程其实相当漂亮：Noma Labs 于 6 月 30 日负责任披露，附带一个在实时默认部署上验证过的可用 PoC；Ruflo 在 24 小时内发布了全面修复，把平台默认改成锁定配置，公网暴露变成需要显式选择并强制认证的选项；Noma Labs 独立验证了修复。
但这件事真正值得写进文章的，是修复之后的那段建议。官方说明写得很直白：对于暴露过的组织，补救不止是打个补丁——AI 供应商凭证应当视为已泄露并轮换，平台的 AI 记忆应当审计是否被篡改，容器应当从干净镜像重建。
为什么记忆要单独拎出来说？因为记忆污染有一个别的漏洞没有的性质：攻击者早就走了，影响还在生效。 往持久化记忆里写入恶意指令，意味着攻击者可以影响这个平台未来每一位用户得到的回答，而这一切发生在入侵结束很久之后。补丁修的是入口，修不了已经被写进去的东西。
这一点正好接上前几天那篇关于 agent 记忆的文章。那篇讲的是记忆"想不起来"——事实存进去了，检索没把它排上来。这里是同一层的另一个方向：记忆被别人写进去了，而且会被当作前提使用。两件事合起来说明，记忆不是一个更聪明的向量库，它是一份需要作用域、来源、有效期和血缘的数据资产。
把两件事并排看，共同点很清楚：它们都不是"攻击者从外部打进来"，而是"本来就在路径上的组件出了问题"。 中转层是你自己配的，harness 是你自己装的。传统安全模型里，攻击面是边界；在 agent 这套架构里，攻击面是你信任的中间件所占据的位置。
六、边界与判据
先说这项研究不能推广的部分，避免把数字用过头。
论文自己列了三条威胁有效性。内部有效性上，agent 天然有状态且非确定，虽然用重放基线做了对照、任务跑在隔离容器里，但由于端到端跑 agent 的算力和金钱成本很高，每个配置只跑了三个实例，这限制了对运行间波动的估计精度。构造有效性上，400 个样本是人工构造的，不代表真实世界的分布，好处是精确、可复现、可比较。外部有效性上，四款 agent、若干后端、有限的任务集，覆盖不了所有生态和路由拓扑，具体的成功率是配置相关的，不该当成普适数字。
论文把自己的核心主张收得比数字窄，我认为这个分寸很值得学：一旦中转层能改写 agent 消费的响应，现实工作流里就会出现有意义的控制失效——这个架构性风险会推广，具体的百分比不会。
在这个边界内，有几条判据可以直接用。
从技术视角看，agent 的信任边界要往上游挪。今天绝大多数防护都堆在"要不要执行这个动作"这一步，但这一步的输入已经可能被改过了。挪的方式有两种：要么让上游响应可验证（论文呼吁的输出完整性保证），要么至少保证审查链路和被审查链路物理隔离——后者是今天就能做的，成本也不高。
从落地视角看，有三个问题值得马上盘一遍：你的 agent 到底通过谁访问模型，这条链路上有几跳，每一跳是谁在运营？你的审查器、护栏、日志上报，走的是不是同一条链路？你的 harness 平台默认对外暴露了什么——Ruflo 那个 MCP 桥，是默认开着的。
还有一条容易被忽略：白名单和 LLM 审查都会误伤。最好的配置误伤率也在 9% 到 14%，白名单能到 43.9%。上线这类管控前，得先想清楚误伤的处理流程，否则开发者会想办法把它关掉，而被关掉的护栏等于没有。
从本土视角看，这项研究几乎是贴着国内工作流做的。作者来自上交、北大、北航；四个后端模型 DeepSeek-V4-Pro、DeepSeek-V4-Flash、Kimi-2.7 Code、Qwen3.6-Plus 全是国产模型；而 API 中转站在国内开发者中的普及程度，远高于直连官方端点。也就是说，这篇论文描述的不是一个"国外的架构风险"，而是国内 AI Coding 工作流的默认形态。
顺带一个不那么舒服的观察：中转站的商业模式本身就建立在"我能看到并处理你的流量"之上——统一计费、多后端切换、缓存加速，每一项便利都要求它坐在明文路径上。这不是说中转站不可信，而是说便利和可信在这个位置上是同一件事的两面，选型时得当成一次信任委托来评估，而不是当成一个网络配置项。
结论
几条可以带走的判断：
- 防御成功率 0% 说明问题在架构，不在实现。 四款 agent、四种权限模式、四个后端模型，在四个注入等级下全部失守。plan 只读模式挡不住，是因为只读约束在 prompt 层强制、不延伸到 router 层；换后端模型没用，是因为注入发生在响应产生之后。凡是"多一层冗余就更安全"的直觉，在这个位置都不成立。
- 审查链路必须独立于被审查链路，这条判据有精确的量化对照。 同样是 LLM 审查，走中转层的 auto 模式原生审查器是 0%，绕开中转层直连官方端点的是 39% 到 64%。这是今天就能落地、成本也不高的一条改动。
- 客户端缓解有天花板，最好的配置也只到五成上下。 白名单 DSR 30.8% 到 44.1%、误伤 29.7% 到 43.9%；LLM 审查最高 64.4%，且强烈依赖审查模型选择。审查器对裸 Bash 严格（拒 308/868 到 452/868），对包装过的高层工具几乎全放行，这个偏好本身就是盲区。真正的解法在供应商侧的输出完整性保证。
- 记忆污染要单独建账，因为补丁修不了它。 Ruflo 那个满分漏洞的补救清单里，除了升级还有凭证轮换、记忆审计、容器重建——因为写进持久化记忆的恶意指令，会在攻击者离开之后继续影响每一位后续用户。
最后留个问题。这篇论文里唯一有效的缓解，靠的是"审查请求绕开中转层直连官方端点"。可现实中很多团队用中转站，恰恰是因为没法直连——额度、网络、结算，哪一条都可能是硬约束。
如果直连这条路对你是关着的，你要怎么给自己搭一条可信的审查链路？
参考资料
- Donghao Fu、Jingxin Li、Xue Jiang、Yihong Dong（上海交通大学 / 北京航空航天大学 / 北京大学），《Where Is the Cost of Third-Party API Routers in Agentic Software Development?》，arXiv:2607.23624v2，2026 年 7 月 29 日。https://arxiv.org/abs/2607.23624
- SIDEL 框架与 400 样本注入数据集，开源仓库。https://github.com/Riyasushin/SIDEL
- Noma Security，《Noma Labs Discovers Critical Vulnerability in Widely Adopted Open Source AI Agent Platform Ruflo》，PR Newswire，2026 年 7 月 29 日。https://www.prnewswire.com/news-releases/noma-labs-discovers-critical-vulnerability-in-widely-adopted-open-source-ai-agent-platform-ruflo-302837494.html
- Ravie Lakshmanan，The Hacker News，《Ruflo MCP Flaw Lets Unauthenticated Attackers Run Commands and Poison AI Memory》，2026 年 7 月 29 日。https://thehackernews.com/2026/07/ruflo-mcp-flaw-lets-unauthenticated.html
- SC Media，《Maximum severity vulnerability in Ruflo AI platform allows memory tampering》，2026 年 7 月 29 日。https://www.scworld.com/brief/maximum-severity-vulnerability-in-ruflo-ai-platform-allows-memory-tampering
- ICE 数字实验室，《Agent 记忆：你的 Agent 不是忘了，是没想起来》，2026 年 7 月 29 日。
- ICE 数字实验室，《模型为了作弊，打穿了两家公司：Agent 安全的三处要害》，2026 年 7 月 27 日。
本文部分内容由 AI 辅助生成，经人工审校和补充后发布。