文章总结： 论文提出ChainFuzzer灰盒测试框架，针对LLMAgent工作流级多工具漏洞进行自动化发现。研究通过工具链提取、提示修复和模糊测试三大模块，在20个流行应用中识别出365个漏洞，其中82.74%需多工具协同触发，证明传统单工具测试存在严重盲点。建议开发者需重视跨工具数据流的安全验证。 综合评分： 92 文章分类： 漏洞分析,渗透测试,安全工具,WEB安全,AI安全
论文研读与思考|ChainFuzzer：LLM Agent中面向工作流级别的多工具漏洞的灰盒模糊测试
Bian Bian
玄枢战队-Arcane Hub
2026年4月16日 18:38 美国
在小说阅读器读本章
去阅读
原文标题：ChainFuzzer: Greybox Fuzzing for Workflow-Level Multi-Tool Vulnerabilities in LLM Agents
原文作者：Jiangrong Wu, Zitong Yao, Yuhong Nan, Zibin Zheng
原文链接：https://arxiv.org/abs/2603.12614
一、研究背景、目标和方法
1.1 研究背景
LLM智能体早已不满足于简单的问答交互，而是演变为能够调用外部工具来自主完成复杂任务的自动化系统，其安全问题已经不再只体现在模型本身，而是越来越体现在由搜索、下载、文件写入、数据库访问、网络请求、代码执行等多个工具串联形成的完整工作流中。现代LLM智能体往往通过多步、多工具协作完成真实任务，这样的组合虽然显著增强了系统能力，但也让一个工具产生的结果，在后续步骤中变成另一个工具输入的跨工具数据流成为新的攻击面。
以往很多针对LLM Agent的安全测试仍然停留在单工具或单跳行为层面，典型思路是：给定一个恶意提示，观察某个工具调用是否直接触发不安全操作。作者认为这种做法会系统性低估真实风险。原因在于，多工具漏洞往往并不是在某一步骤上单独爆发，而是在若干中间状态、共享载体和跨工具依赖共同作用下，最终把不可信数据推进到高风险sink上。也就是说，若只分析某个工具是否单独危险，而忽视它与前后工具之间的依赖关系，就容易漏掉真正的工作流级漏洞。
1.2 研究目标
本研究面向真实部署环境中的多工具LLM Agent，构建一个能够自动发现、自动复现、并提供可审计证据的灰盒测试框架。作者希望解决三个关键问题。第一，如何在数量庞大、关系复杂的工具集合中，自动定位那些真正可能将不可信内容送入高风险操作的候选工具链；第二，如何让本身具有非确定性的LLM Agent稳定地执行指定工具链，而不是在不同运行中随机改变规划路径；第三，如何在模型自带防护机制（guardrail）会拒绝显式恶意载荷的情况下，仍然能够验证底层工具设计层面的真实弱点。
1.3 论文提出的关键方法
与单纯依赖提示工程或随机工具组合的工作不同，ChainFuzzer的关键价值在于，它把多工具漏洞明确表述为一种严格的source-to-sink数据传播问题。ChainFuzzer的核心流程由三个主要模块构成。模块A负责从高影响sink出发反向寻找上游候选工具链；模块B负责用基于运行轨迹的提示修复（TPS）把工具链转化为可稳定执行的有效提示；模块C负责在user-source或env-source注入点引入攻击载荷，并通过变异与oracle验证漏洞是否真正触发。
图1 ChainFuzzer总体工作流
二、具体方案设计与理论研究
2.1 问题定义与威胁模型
论文首先给出了多工具智能体的基本运行图景：LLM 作为规划器与控制器，在给定用户请求后决定下一步要调用哪个工具、如何绑定参数，以及如何基于前一步的输出继续完成后续子任务。从软件工程角度看，每个工具至少包含输入模式、输出对象和外部副作用三部分；而从安全角度看，这三部分共同决定了工具之间是否能够形成可利用的数据依赖。
作者把多工具依赖划分为两类。第一类是直接依赖，即后续工具直接消费前一工具输出的字段；第二类是间接依赖，即前一步把内容持久化到共享载体中，后续步骤再通过文件、数据库、缓存、索引等方式间接取回并继续使用。论文强调，真正危险的往往正是这类经过中间载体重新解释后的数据流。
在威胁模型上，ChainFuzzer假设攻击者不能直接修改智能体源代码、模型权重或工具实现，但可以通过两种现实边界影响输入：一是以恶意用户身份，通过自然语言提示直接操控远程智能体；二是通过不可信外部内容或共享载体，如网页、下载文件、数据库记录、检索文档等，让被智能体读取的数据在后续步骤中进入高风险操作。论文不考虑需要额外系统特权、开发者密钥或内部模型访问权限的攻击路径，而是专注于“工具本来就被赋予的权限”如何在工作流层面被组合利用。
图2 一个多工具工作流的示例
2.2 接收器相关工具链提取
模块A的设计思路非常清晰：与其在所有工具组合空间中盲目搜索，不如先盯住那些真正可能造成后果的高影响sink。为此，论文维护了一份候选sink API目录，并根据不同风险类型进行分类，覆盖命令执行（CMDi）、代码执行（CODEi）、服务器端请求伪造（SSRF）、模板注入（SSTI）和SQL注入（SQLi）五大类。例如subprocess.run、os.system会被标记为命令执行类sink；eval、exec属于代码执行类sink；urllib、requests、httpx、aiohttp等网络请求接口会被视为SSRF sink；jinja2.from_string、flask.render_template_string对应SSTI；数据库execute类接口对应SQLi。
仅仅枚举代码里出现了危险API还不够，作者进一步提出了严格的可达性规则：只有当某个sink调用的参数能够被工具入口输入影响时，该工具才会被认定为sink tool。实现上，系统从sink参数表达式出发向后回溯数据流，沿赋值链、变量中转和常见代码结构追踪其来源。这个约束非常重要，它主动排除了“虽然工具内部含有危险API，但调用参数是固定常量”的伪风险情形，从而把后续分析预算集中到真正可达的危险路径上。
在确定sink tool后，系统再执行后向链提取。从每个sink tool出发，ChainFuzzer依据两类静态规则构造工具依赖边：其一是直接依赖规则，当上游工具返回字段与下游参数在接口层面等价或包含时，就建立边；其二是间接依赖规则，当上游工具能够持久化内容、而下游工具能够读取或执行这些持久化内容时，也建立边。由于这种静态连接会故意偏向过近似，作者又引入了基于LLM的语义理解，对每一条候选链进行是否符合真实任务逻辑的语义筛选。
经过上述两步，模块A输出的是一组从不可信输入边界到高影响sink的可疑工作流候选链，每条链都会带有依赖类型标注以及关键数据传播位点说明。论文后续所有提示生成与漏洞验证，都建立在这套候选链之上。
2.3 工具链提示生成
即使候选工具链本身是合理的，LLM Agent也不一定会按研究者期望的顺序去执行。论文认为，这是多工具漏洞复现中最容易被低估的工程难点。LLM作为规划器具有显著的非确定性：相似提示在不同运行中可能选择不同工具、跳过某一步、错用某个字段，甚至因为缺少中间资源而提前失败。为此，ChainFuzzer设计了TPS。
首先，系统基于候选链和工具元数据生成一个seed prompt。这个初始提示把整条候选链包装成一个看似合理的用户任务请求。随后，系统执行当前提示并记录智能体的工作轨迹，论文将轨迹表示为一个五元组：
接着，TPS会继续分析为什么智能体没有按预期走完目标工具链，把实际轨迹与目标链进行比较，抽取导致偏离的提示级语义约束。论文总结的约束类型至少包括五类：缺失前置条件、参数绑定错误或不完整、格式/参数不匹配、权限确认门槛，以及 planner detour（即模型自己偏航到别的工具或跳过了必要步骤）。
拿到这些约束之后，prompt solver在尽量保留已有正确前缀的前提下，对prompt进行局部修补，而不是彻底重写。它会插入缺失步骤、强化先前被忽略的指令、澄清模糊指代、修复绑定关系，或者明确要求某个工具先创建必须资源。这个局部编辑而非整段重写的策略很重要，因为它减少了每一轮修补时引入新的不确定性。系统不断重复“执行—比较—抽取约束—局部修补”的闭环，直到工具链能够被稳定执行，或者达到预算上限。论文规定：若某提示能够在连续5次运行中都完整走通目标链，则被视为稳定有效的prompt。
2.4 模糊测试驱动的漏洞验证
模块C的任务是要在工作流级路径已经可达的前提下，进一步确认：不可信输入是否真的能穿过整条工具链，最终影响sink参数并造成安全后果。为此，ChainFuzzer先做注入点选择。其判断标准非常贴近真实攻击面：若链的第一步直接接受用户输入，如write_file或其它用户可控字段，那么优先测试user-source注入；若链条包含web_search、download、文件读取或数据库读取等利用外部内容的工具，则测试env-source注入。若两种入口都合理，系统会同时覆盖。
随后，系统根据sink类型实例化恶意载荷。对于CMDi，载荷是shell可执行命令；对于CODEi，是可以被解释执行的代码片段；对于SSRF，是面向内网、回环地址、链路本地地址或指定敏感端点的URL；对于SQLi，是能够改变查询逻辑的语句片段；对于SSTI，则是会触发模板求值的表达式。作者没有把载荷成功经过模型表达当作唯一标准，而是为不同sink设计了专用oracle：例如命令执行只要带有payload影响的命令执行API被触达即可；SSRF需要观察请求是否到达内部目标类；SQLi与SSTI则依赖结果异常、扩展结果集或渲染效果等证据。
论文尤其强调guardrail-aware fuzzing的必要性。现实中的模型guardrail往往会拒绝明显的恶意字符串，这会让研究者误以为系统没有风险，但实际上可能只是模型说不出危险内容，并不代表工具层面的设计就是安全的。因此，ChainFuzzer在direct payload被阻断时，会保留prompt不变，只对payload做反馈驱动变异。文中给出的变异策略包括三类：其一是shard，把恶意载荷拆成看似无害的片段，在后续步骤中重新拼接；其二是encode，采用base64、转义等方式，让下游工具或环境再解码；其三是perturb format，即改变引号、分隔符或布局形式，在不破坏工具语法要求的前提下弱化guardrail的显式拦截。经过反复变异与重新测试，系统才能较可靠地把底层多工具漏洞显露出来。
三、论文使用的研究方法及相关证明
3.1 实验对象、环境与研究问题设计
论文将评估对象设定为20个流行的开源多工具LLM Agent应用，共暴露 998个工具接口。数据集中的代表性项目包括openclaw、autogpt、langflow、langchain、ragflow、metagpt、llama_index、chatchat、vanna、dbgpt、superagi、agentscope、agentzero、bisheng、xagent、taskweaver、taskingai、langroid、griptape和lagent。作者选择这些项目的标准是：GitHub星标不少于2000，并且确实支持多工具协同工作流。这样的数据集覆盖了不同的agent框架、不同的部署形态和不同的工具生态，因而具有一定代表性。
实验环境方面，论文采用GPT-5.1作为被测agent运行时中的目标大模型，而ChainFuzzer自身的LLM相关模块由GPT-4o驱动；硬件平台是一台Apple M4 Max、36GB RAM的本地机器。
研究问题共分三类：RQ1关注整体漏洞发现效果与成本；RQ2关注各个核心模块是否在其预期职责上真正有效；RQ3则通过消融实验判断三大模块是否缺一不可。
表1 整体漏洞发现结果
| | | | | | | | | | | — | — | — | — | — | — | — | — | — | | 总应用数 | 受影响应用数 | 工具总数 | Sink tools | 候选工具链 | 有效 Prompt | 单工具漏洞 | 多工具漏洞 | 总漏洞数 | | 20 | 19 | 998 | 199 | 2388 | 2213 | 63 | 302 | 365 | | – | – | 49.9/应用 | 9.95/应用 | 119.4/应用 | 110.65/应用 | 3.15/应用 | 15.1/应用 | 18.25/应用 |
从整体结果看，ChainFuzzer最核心的结论有两点。第一，它最终在20个应用中找到了365个可复现漏洞，其中19个应用受到影响，说明工作流级多工具漏洞并不是偶发现象，而是当前智能体生态中的普遍问题。第二，在这365个漏洞中，有302个需要多工具执行才能触发，占比82.74%，单工具漏洞只有63个。也就是说，多工具漏洞比单工具漏洞多出4.79倍，这直接支撑了作者的中心论点：若仍沿用单工具测试范式，将会漏掉大多数现实世界中的工作流风险。
论文还进一步按注入来源和sink类型统计漏洞分布，结果显示user-source注入触发了225个漏洞，占61.64%；env-source注入触发140个，占38.36%。从sink类型看，CMDi共121个、CODEi79个、SSRF97个、SSTI23个、SQLi45个。
表2 按注入来源与Sink类型统计的漏洞分布
| | | | | | | | | — | — | — | — | — | — | — | | 注入来源 | CMDi | CODEi | SSRF | SSTI | SQLi | 合计 | | User-source | 82 | 53 | 44 | 17 | 29 | 225（61.64%） | | Env-source | 39 | 26 | 53 | 6 | 16 | 140（38.36%） | | Total | 121（33.15%） | 79（21.26%） | 97（26.57%） | 23（6.30%） | 45（12.33%） | 365 |
3.2 各模块有效性分析
为了证明系统不是恰巧跑得通，论文分别评估了三个模块。首先是工具链抽取精度。作者从20个应用中均匀抽样200条候选链，并对每条链上的每一条边做人工验证，检查接口字段、共享载体以及代码级数据流证据是否成立。结果显示，边级精度达到96.49%（714/740），严格链级精度达到91.50%（183/200）。这说明模块A抽取出来的并非大量语义牵强的工具组合，而是大多能够在逻辑上成立的真实工作流。
其次是TPS对提示有效性的提升。作者对同样200条链，先直接生成seed prompt，再在R=10的重复运行下测reachability，并另外统计5/5连续成功的stable prompt rate。未使用TPS时，链的可达率只有27.05%，稳定 prompt比例只有9.50%；经过TPS之后，两项指标分别升至95.45%和92.50%。
最后是guardrail-aware mutation对漏洞复现率的提升。作者从已确认的365个漏洞中按sink类型抽取100个样本（每类20个），比较初始载荷直接注入与变异后载荷注入两种策略的触发率。总触发率从18.20%提升到88.60%。对guardrail更敏感的CMDi和CODEi，提升幅度尤为显著，分别从10.00%升到86.00%、从7.00%升到82.00%。作者用这一结果证明：如果只看显式恶意提示是否被模型拦截，很容易误判系统风险；真正的验证应聚焦工具链中的数据传播与sink效果是否仍然可达。
表3 模块有效性评估结果
| | | | | | — | — | — | — | | 评估维度 | 基线/前态 | 增强后/结果 | 提升或结论 | | 工具链抽取：边精度 | – | 96.49%（714/740） | 候选边大多成立 | | 工具链抽取：严格链精度 | – | 91.50%（183/200） | 候选链整体可信 | | TPS：Reach (R=10) | 27.05% | 95.45% | +68.40% | | TPS：Stable prompt rate (5/5) | 9.50% | 92.50% | +83.00% | | Mutation：CMDi | 10.00% | 86.00% | +76% | | Mutation：CODEi | 7.00% | 82.00% | +75% | | Mutation：SSRF | 29.00% | 91.00% | +62% | | Mutation：SSTI | 24.00% | 94.00% | +70% | | Mutation：SQLi | 21.00% | 90.00% | +69% | | 总体 | 18.20% | 88.60% | +70.4% |
3.3 消融实验与关键解释
在消融实验中，作者分别去掉ChainExtraction、TPS与Mutation，观察最终已确认漏洞数和覆盖的sink类型数如何变化。结果非常有代表性：完整系统能确认365个漏洞，覆盖5类sink；去掉ChainExtraction后，漏洞数骤降到63，覆盖类型缩减到3类；去掉TPS后，漏洞数为96，覆盖类型为4类；去掉Mutation 后，漏洞数为132，覆盖类型虽然仍有5类，但确认实例数量明显减少。
这组结果可以非常直观地解释三大模块的分工。ChainExtraction决定了系统能否发现“真正存在跨工具数据流的风险路径”，因此一旦移除，多工具漏洞几乎被打掉大半；TPS决定了这些风险路径能否稳定地被智能体执行，因此它主要影响复现可达性；Mutation则主要决定在guardrail存在时，已经可达的漏洞究竟能被确认多少个，因此它更多影响确认数量，而不一定大幅改变sink类型覆盖范围。
表4 消融实验结果
| | | | | | — | — | — | — | | 系统变体 | 已确认漏洞数 | 相对完整系统变化 | 覆盖Sink类型数 | | ChainFuzzer（完整） | 365 | 0 | 5 | | w/o ChainExtraction | 63 | -302 | 3 | | w/o TPS | 96 | -269 | 4 | | w/o Mutation | 132 | -233 | 5 |
四、论文的创新点、未来方向及推广价值
4.1 论文的创新点与贡献
第一，论文把多工具漏洞明确建模为工作流级的source-to-sink数据传播问题，而不是把单个工具是否危险作为主要研究对象。
第二，ChainFuzzer在方法论上采用了非常工程化的三段式闭环：先用 sink反推候选链，再用TPS修补提示使链稳定可达，最后用变异绕过 guardrail完成漏洞验证。每一段都瞄准了现实世界LLM Agent测试中最常见的失败点，因此整体方案既具有研究新意，也具有较强的落地性。
第三，论文并未把模型guardrail视作终点防御，而是把它当作真实风险验证过程中的一个干扰因素，通过变异把语言层拒绝与工具层安全剥离开来。这个视角对于当前大量依赖guardrail的智能体系统很有启发意义。
4.2 局限性与未来工作
从外部有效性看，论文评估的是20个流行开源agent，已经比很多只测少量demo的工作更扎实，但仍然主要集中在开源生态、公开工具和可分析代码的场景。未来若扩展到闭源智能体平台、MCP工具生态、企业内嵌型agent，工具权限结构与状态共享方式会更加复杂，静态链抽取与轨迹验证机制都需要进一步增强。
从模型层面看，作者已经指出更强的LLM可能提高规划稳定性并降低幻觉。沿这一方向继续推进，不只是简单替换更强模型，还可以考虑专门训练安全测试型agent，让其对跨工具依赖、注入边界、payload变体和 sink-oracle有更强的专门能力，从而把ChainFuzzer从通用 LLM 驱动框架提升为面向agent 安全验证的专用智能测试系统。
4.3 研究的适用范围与推广价值
在推广价值上，ChainFuzzer的思想并不局限于本论文中的20个开源 agent。凡是存在“多工具协作+中间状态共享+高风险sink”的系统，都可以借鉴其分析思路。
从学术意义上讲，本文推动了LLM Agent安全研究从单工具测试继续向组合工作流验证方向演进；从工程意义上讲，它说明对智能体的安全测试不能只问模型会不会拒绝，更应该追问不可信数据最后能不能到达危险边界。这种观念转变，对后续的agent评测基准、红队框架和安全治理都有直接启发。
五、心得体会与思考
读完这篇论文，我最大的感受是：它真正抓住了当前LLM Agent安全中的结构性矛盾。很多系统看似把单个工具描述写得很安全，甚至在交互层加了不少guardrail，但一旦这些工具被放进一个会自行规划、会跨步骤复用结果的工作流里，风险边界就不再位于某个单独接口，而是位于整条数据传播路径上。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：玄枢战队-Arcane Hub Bian Bian《论文研读与思考|ChainFuzzer：LLM Agent中面向工作流级别的多工具漏洞的灰盒模糊测试》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论