一句话会拒绝，分几步就执行：工具型Agent的多轮安全风险

6 月 10 日，Northeastern University、Virtue AI、UC Berkeley、UIUC 等机构发布论文 《Unsafer in Many Turns: Benchmarking and Defending Multi-Turn Safety Risks in Tool-Using Agents》。

https://arxiv.org/pdf/2602.13379

这篇论文关注的不是传统意义上的单轮越狱，而是一个更贴近真实 Agent 落地的问题：当有害意图被拆成多轮任务，并通过工具调用、文件、数据库、浏览器状态、环境变量逐步累积时，Agent 的安全性会明显下降。

论文提出了多轮工具型 Agent 安全基准 MT-AgentRisk，并给出一种训练无关、工具无关的防御方法 ToolShield。实验结果显示，多轮场景下，模型的攻击成功率 ASR 平均上升 16%；引入 ToolShield 后，多轮攻击成功率平均下降 30%。

这句话可以概括论文的核心发现：

一句话直接说，Agent 可能会拒绝；拆成几步让它做，Agent 很可能一路执行。

从单轮拒绝到多轮执行：工具型 Agent 的能力越强，执行链路越长，安全缺口也越容易被放大。

Agent 的风险，已经从“说了什么”变成“做了什么”

传统大模型安全评测，最常见的方式是给模型一条有害请求，看它会不会拒绝。

比如用户直接提出一个危险操作，模型如果拒绝，就算安全；如果回答，就算不安全。这个逻辑在普通聊天模型里相对有效，因为模型的主要输出是文本。

但 Agent 不一样。

Agent 不只会回答问题，它会持续交互、读取上下文、调用工具、修改外部状态。它可能操作文件系统，访问数据库，控制浏览器，调用企业内部 API，甚至通过 MCP Server 连接各种业务系统。

这时，风险不一定出现在某一句话里。更常见的情况是：第一轮让 Agent 创建一个文件，第二轮让它写入一段内容，第三轮让它读取变量，第四轮让它调用工具执行某个动作。单独看每一步都不明显危险，组合起来却完成了原本会被拒绝的高风险任务。

论文指出，现有安全基准大多分成两类：一类评测多轮对话安全，但不涉及真实工具；另一类评测工具调用安全，但多是单轮任务。MT-AgentRisk 的定位，就是把“多轮有害意图分布”和“真实工具使用”放在一起评测。

这也是 Agent 安全和内容安全最大的差异：内容安全主要看输入和输出，Agent 安全必须看任务轨迹。

用户说了什么，只是第一层。Agent 实际调用了什么工具、传了什么参数、改了什么文件、污染了什么状态、产生了什么后续动作，才是更关键的安全对象。

MT-AgentRisk：把单轮有害任务转成多轮攻击链

论文构造了一个新的 benchmark：MT-AgentRisk。

它不是简单收集一批 jailbreak prompt，而是先从已有工具型 Agent 安全数据集中整理出 365 个单轮有害任务，然后基于作者提出的多轮攻击分类法，把这些任务系统性地转成多轮攻击序列。任务覆盖五类工具环境：Playwright-MCP、Terminal、Filesystem-MCP、PostgreSQL-MCP 和 Notion-MCP。其中 Playwright-MCP 又覆盖 GitLab、OwnCloud、Reddit、Shopping、Shopping Admin 等 Web 场景。

从任务分布看，MT-AgentRisk 的平均任务轮数是 3.19 轮，范围从 2 到 7 轮；其中 71% 的任务需要 3 到 4 轮完成。攻击转换方式中，Addition 占 69.6%，Decomposition 占 30.4%，覆盖论文分类法中的 8 个子类。

MT-AgentRisk 覆盖 365 个多轮工具任务，平均 3.19 轮，覆盖浏览器、终端、文件系统、数据库和 Notion 五类工具环境。

这里有一个值得注意的点：365 个任务的规模并不算特别大，但它的价值在结构设计。

作者真正想验证的是：一个原本在单轮中容易被识别的有害目标，一旦被拆散到多轮任务、工具调用和环境状态里，模型还能不能保持安全判断。

结果并不乐观。

MAT 分类法：有害意图如何被拆进多轮任务

这篇论文最重要的理论部分，是它提出的 MAT：Multi-Turn Attack Taxonomy，多轮攻击分类法。

MAT 的作用，是把一个单轮有害任务，转成一个多轮攻击序列。它从三个维度描述多轮攻击：

第一个维度是 Format，也就是有害目标如何被结构化。

一种是 Addition，附加层。原始有害任务本身没有被拆掉，但被套了一层间接结构。比如通过别名、映射、包装、文件、变量等方式，让危险意图看起来像普通操作。

另一种是 Decomposition，分解。原始有害任务被拆成多个子任务。每一步看起来都比较普通，但多轮执行后会重新组合成完整风险。

第二个维度是 Method，也就是具体怎么实现。

Addition 下面有 Mapping 和 Wrapping。Mapping 是把危险目标映射成其他名字、路径或符号引用；Wrapping 是把危险内容包进文件、条件结构、容器或其他载体里，后续再触发。

Decomposition 下面有 Composition 和 Identity。Composition 是把多个子任务显式拼接起来；Identity 是让多个子任务按顺序执行，通过连续状态变化累积风险。

第三个维度是 Target，也就是攻击操纵的对象。

一种是 Data Files，数据文件。危险内容被写入文件、脚本、参数、记录等显性数据对象里。

另一种是 Environment States，环境状态。危险内容被藏进 shell 历史、环境变量、运行时状态、浏览器状态、数据库状态、远程文档状态等更隐蔽的位置。论文强调，三层维度交叉后形成 8 类攻击子类型，并且这些转换保持了原始有害目标，只是改变了它在多轮任务中的呈现方式。

这部分非常适合拿来理解 Agent 安全的新攻击面。

很多企业现在做大模型安全，仍然主要围绕“输入文本有没有风险”“输出文本有没有风险”。但在 Agent 场景里，攻击者可以把真正的风险放到上下文之外：

可能在文件里，

可能在数据库里，

可能在浏览器页面里，

可能在工具返回值里，

可能在前几轮生成的中间状态里。

这意味着，安全系统如果只盯着用户当前这一句话，很容易漏掉完整任务链中的风险。

实验结论：所有模型到了多轮场景都会更不安全

论文评测了 6 个模型：GPT-5.2、Claude-4.5-Sonnet、Gemini-3-Flash、Seed-1.6、Qwen3-Coder、Deepseek-v3.2。所有模型都部署在 OpenHands 环境中，评估方式是 LLM-as-a-Judge，由 GPT-4.1 判断执行轨迹是完成、拒绝还是失败。作者还用规则评估和人工评估做了校验，LLM 判断与规则评估的一致率为 95.15%，与人工评估的一致率为 93.53%。

核心指标是 ASR，Attack Success Rate，攻击成功率。也就是：有害任务最终被 Agent 完成的比例。

结果很直接：从单轮变成多轮之后，所有模型的 ASR 都上升。

具体来看：

论文 Figure 6 显示，从单轮到多轮，攻击成功率在所有模型上都有上升，增幅从 Deepseek-v3.2 的 +8.8% 到 Claude-4.5-Sonnet 的 +27.1%。

从单轮到多轮，6 个模型的 ASR 全部上升，说明多轮任务链会系统性放大 Agent 安全风险。

这说明一个关键问题：

单轮安全对齐，不能自然泛化到多轮工具执行。

模型在单轮里可能知道某个最终目标危险，但当这个目标被拆成几步，模型更容易只判断当前动作是否合理，而没有持续追踪整体意图。Agent 在多轮任务里看起来像是在完成用户交代的正常工作，实际上已经被带到了一个危险执行链上。

能力强，不等于更安全

论文还有一个很重要的发现：模型能力和多轮 Agent 安全之间没有简单正相关关系。

作者观察到，GPT-5.2 和 Gemini-3-Flash 在一些能力指标上接近，但多轮安全表现存在明显差距；Deepseek-v3.2 在开源能力 benchmark 上表现很强，但在 MT-AgentRisk 中表现出较高的安全脆弱性。论文据此判断，GPT-5.2 的安全优势更可能来自专门的安全对齐投入，而不是单纯的能力 scaling。作者还指出，即使是带有扩展推理能力的模型，仍然会在多轮场景中出现 ASR 上升。

这个结论对企业很重要。

很多团队上 Agent 的时候，会默认认为：模型越强，Agent 越可靠；模型越聪明，安全性越好。

但工具型 Agent 的安全问题并不只是“模型是否理解语义”。它还涉及：

能不能跨轮次追踪目标；

能不能识别工具调用之间的组合风险；

能不能发现环境状态已经被污染；

能不能在局部正常、整体异常的任务链中及时停下来。

强模型更会执行任务，也可能更会执行危险任务。企业不能把模型能力当成安全能力。

最危险的地方：环境状态

在不同攻击类型里，论文发现 Decomposition × Env 的平均 ASR 最高，达到 73.7%；其次是 Addition × Data，平均 ASR 为 72.2%；Addition × Env 为 69.9%；Decomposition × Data 为 67.9%。作者认为，环境状态类攻击尤其危险，是因为现有安全机制更擅长检测有害内容，却不擅长追踪环境状态如何被操纵并最终触发风险。

不同攻击类型的 ASR 对比：Decomposition × Env 最高，说明“状态型风险”是工具 Agent 的核心盲区。

这其实是 Agent 安全里最值得关注的变化。

普通内容安全系统关心的是“文本里有没有危险内容”，Agent 安全还要关心“环境里有没有危险状态”。

举几个更贴近企业的例子：

用户第一轮让 Agent 保存一个配置文件，第二轮让它加载配置，第三轮让它调用内部 API。配置文件本身可能已经改变了后续工具调用的行为。

用户第一轮让 Agent 查询数据库，第二轮让它把结果写入临时表，第三轮让它基于临时表执行批量操作。风险可能不在 SQL 语句本身，而在中间状态被污染。

用户第一轮让 Agent 浏览一个网页，第二轮让它总结页面里的指令，第三轮让它根据“页面提示”执行操作。风险可能来自页面内容，而不是用户输入。

这类风险都不适合只用“输入分类器”解决。真正需要的是跨轮次的状态追踪、工具调用审计、环境变更检测和高危动作确认。

ToolShield：让 Agent 上岗前先做安全自测

针对多轮工具风险，论文提出了一个防御方法：ToolShield。

它的核心思路很简单：当 Agent 接入一个新工具时，先不要直接上线使用，而是让 Agent 自己围绕这个工具做安全探索。

ToolShield 有四个阶段。

第一步：Test Case Synthesis，测试用例生成。

Agent 读取工具文档，分析每个函数可能造成什么风险。对于高风险函数，生成单轮测试用例；对于组合型风险，进一步分析新工具和已有工具如何联动，生成多轮测试用例。

第二步：Simulated Execution，模拟执行。

Agent 在沙箱环境中执行这些测试用例，记录完整执行轨迹。轨迹包括 Agent 是拒绝、尝试，还是完成了任务，也包括完整工具调用链。

第三步：Experience Generation，经验生成。

Agent 分析执行轨迹，总结哪些行为模式是风险信号，哪些拒绝模式是有效的，哪些失败暴露了安全盲点。

第四步：Experience Update，经验更新。

Agent 把新的安全经验加入经验列表，或更新已有经验。部署时，这些经验会被注入 Agent 上下文，作为它识别工具滥用模式的安全知识。

ToolShield 四阶段流程：工具文档分析、测试用例生成、沙箱模拟执行、轨迹总结、经验更新。

ToolShield 的价值在于，它没有要求重新训练模型，也不绑定某一个固定工具。它把 Agent 的工具理解能力转化成安全经验：既然 Agent 能理解工具怎么用，也可以让它提前探索工具可能怎么被滥用。

从产品角度看，ToolShield 可以翻译成一句话：

新工具上线前，先让 Agent 在沙箱里红队自己。

ToolShield 的效果：有用，但不能神化

实验结果显示，ToolShield 在多轮场景中可以显著降低 ASR。不同模型上的 ASR 降幅在 18.6 到 49.9 个百分点之间，其中 Claude-4.5-Sonnet 的改善最大，从 72% 降到 22%。

ToolShield 在 6 个模型上均降低多轮攻击成功率，Claude-4.5-Sonnet 的 ASR 从 72% 降到 22%。

论文还把 ToolShield 和几种基线防御做了对比，包括 LlamaFirewall、Taxonomy Defense、ToolShield w/o simulation。结果显示，LlamaFirewall 平均只降低 3% ASR；完整 ToolShield 的效果明显更好，在 100 个随机采样多轮有害任务上，把 Claude-4.5-Sonnet 的 ASR 从 88% 降到 15%，把 Gemini-3-Flash 从 81% 降到 57%。作者认为，模拟执行和轨迹分析提供了更丰富的上下文，能帮助 Agent 更好理解工具风险模式。

ToolShield 与基线防御对比：单纯规则或抽象分类法不够，真实/模拟执行轨迹对识别多轮工具风险更关键。

论文还测了良性任务上的误拒问题。在 Claude-4.5-Sonnet 上，170 个良性任务中，ToolShield 前后的拒绝率都为 0%；良性任务成功率从 95.3% 轻微下降到 94.1%。与此同时，在 365 个有害任务上，成功率从 44.7% 降到 9.6%，拒绝率从 43.6% 提升到 87.1%。

这个结果说明 ToolShield 不是简单让模型变得更保守，而是让模型更能识别工具滥用模式。

但也要谨慎看待这个结论。170 个良性任务不能覆盖真实企业环境里的全部业务场景。企业落地时，仍然要关注误拒、误拦截、任务失败率和用户体验。

这篇论文对企业 Agent 安全有什么启发？

这篇论文的真正价值，不只是提出了一个 benchmark 或一个防御方法。它更重要的贡献，是把 Agent 安全的治理对象讲清楚了。

第一，安全检测要从单轮输入扩展到多轮轨迹。

很多风险单看当前输入是无害的，必须结合前几轮上下文、工具调用记录和状态变化才能判断。企业需要记录完整的 Agent 执行轨迹，而不只是保存对话文本。

第二，工具调用安全要关注状态变化。

文件是否被写入了敏感内容？数据库中间表是否被污染？浏览器页面是否注入了外部指令？环境变量、配置文件、缓存、历史记录是否改变了后续动作？这些状态变化要进入审计范围。

第三，新工具接入前要做自动化安全评测。

每接入一个 MCP Server、内部 API、数据库工具、RPA 工具，都应该先根据工具文档生成风险用例，在沙箱环境中跑一轮。ToolShield 提供的是一种可参考的自动化思路：工具文档分析、测试用例生成、模拟执行、轨迹总结、经验沉淀。

第四，安全经验要变成组织资产。

一次红队测试发现的风险，不应该只停留在报告里。它可以沉淀成安全经验库、工具调用策略、参数校验规则、审批策略、审计规则，供其他 Agent 复用。

第五，Tool Gateway 仍然是硬约束核心。

ToolShield 提升的是 Agent 的安全意识，但它本质上还是上下文注入型防御。企业不能只依赖模型“自觉”。高危工具仍然需要 Tool Gateway 做权限控制、参数校验、敏感动作审批、速率限制、数据脱敏、日志审计和回滚机制。

局限性

论文自己也承认了几个限制。

第一，它主要是黑盒评测，只观察模型输出和执行结果，无法分析模型内部状态和推理机制，因此不能解释某些攻击为什么在机制层面成功或失败。

第二，benchmark 只覆盖五类工具。虽然浏览器、终端、文件系统、数据库、Notion 已经比较有代表性，但仍然不能覆盖真实企业中的所有 MCP Server 和内部业务系统。

第三，ToolShield 依赖 Agent 自己生成测试用例和总结安全经验。弱模型生成的经验质量可能较低，这会限制防御效果。

除了论文作者提到的限制，我认为还要补充两点。

一是 上下文注入不等于强制执行。ToolShield 最终是把安全经验注入 Agent 上下文。模型是否稳定遵守，是否会被后续指令冲淡，是否会被上下文投毒覆盖，还需要更严格的对抗评测。

二是 benchmark 可能存在分类法偏置。MT-AgentRisk 的任务是基于 MAT 分类法转换出来的，ToolShield 对这类攻击有效，不代表它对所有真实未知攻击都有同样效果。

所以，ToolShield 更适合作为企业 Agent 安全体系中的一层：它可以用于工具上线前自测和安全经验沉淀，但不能替代权限控制、运行时拦截、人工审批和审计追责。

Agent 安全的核心，不再只是拒答

这篇论文最值得记住的一点是：Agent 的风险会沿着多轮任务链扩散。

单轮里会拒绝的事情，多轮里可能被拆解、包装、映射、延迟触发。危险不一定写在当前输入里，也可能藏在文件、变量、数据库、浏览器页面和工具返回值里。

因此，Agent 安全不能只看“模型有没有拒答”。更关键的问题是：

它有没有持续理解任务目标？

它有没有识别跨轮次组合风险？

它有没有追踪环境状态变化？

它有没有在高危工具调用前停下来？

它有没有把一次失败转化成下一次可复用的安全经验？

从这个角度看，MT-AgentRisk 和 ToolShield 给出的启发很明确：

Agent 安全正在从“单句内容审核”走向“多轮执行轨迹治理”。

这也是企业真正部署 Agent 时绕不开的一步。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。