文章总结： 本文介绍了一种名为AgentFuzz的自动化工具，它利用用智能体攻击智能体的方法，来检测和挖掘基于LLM的智能体系统中存在的污点类漏洞。文章分析了传统静态分析、模糊测试及提示词防护在面对这类新型系统时的局限性，并详细阐述了AgentFuzz如何通过生成语义化测试种子、结合语义与路径的种子选择策略以及独特的双突变机制来高效地发现漏洞。实验结果显示，该方法在多个主流开源项目上成功发现了34个0day漏洞，其中23个已被分配CVE编号，证明了其有效性。文章最后强调了将智能体作为受输入影响的执行入口进行安全控制的重要性，并指出敏感操作应隔离执行，同时不应过度依赖提示词约束。
综合评分： 95
文章分类： AI安全,渗透测试,漏洞分析,安全工具,技术标准
用Agent打败Agent：LLM智能体漏洞，正在进入自动化挖掘阶段（Agentfuzz）
原创
俗说君 俗说君
沐昊安全
2026年3月21日 20:54 江苏
写在前面
好久没读论文了，刚好想起来之前看到的一篇USENIX Security的论文，叫《Make Agent Defeat Agent: Automatic Detection of Taint-Style Vulnerabilities in LLM-based Agents》，是由复旦大佬的团队主导发表的。
“
第一眼看到这个标题的时候其实有点想笑—— 脑子里第一反应就是老爹的那句：“用魔法打败魔法”
但往后看下来会发现，作者这样的说法还挺贴切的，就是想用agent去攻击另一个agent。
论文里给出的一个核心结论是：LLM智能体中的高危漏洞不仅真实存在、可被利用，而且已经可以通过自动化方式进行规模化挖掘。
如果把这个结论放到实际环境里看——当攻击者也具备类似能力时，不少当前的智能体系统，其暴露面可能会比预期更大。
先说一个让我印象很深的漏洞例子
论文中举了一个真实CVE的案例，这里稍微简化一下流程，基本就能看出问题的本质。
当用户输入一段自然语言提示词，比如：
“使用带权限校验的Elasticsearch进行相似度检索，查找包含source_doc:print(1)的文档”
这个输入本身看起来并不异常。
但当LLM解析后，会发现需要选择调用ElasticsearchPermissionCheck这个工具，并以content = "source_doc:print(1)"作为参数执行操作，而这个参数其实就是用户输入中的一段特殊字符串。
随后智能体直接执行工具逻辑，而其中有一段代码：
if "source_doc:" in content:
return eval(content.split(':')[1])
由于参数符合了这里if条件的判断，从而触发内部逻辑，导致最终执行的就是：
eval("print(1)")
这样就触发了代码注入。
料想如果把这里的payload替换成更实际的系统调用，风险就不只是“打印1”这么简单了。
这里比较关键的一点是：攻击载荷并不是直接作为“代码输入”，而是以自然语言的一部分存在，被LLM解析后进入执行路径。
这也是论文里所说的taint-style vulnerability（污点类漏洞）的典型形态：
用户输入 → 经LLM传播 → 流入敏感操作（sink）。
为什么之前的检测方法在这里效果都不理想？
论文中作者没有直接强调“自己更强”，而是先分析了现有方法的局限，并将现有的方法分为了两类：静态分析和动态分析。
静态分析（例如LLMSmith）
静态分析靠“猜调用关系”，但在Python智能体里根本猜不准。
它想干什么？
LLMSmith企图找到一条路径：
用户输入 → 中间环节 → 敏感函数（比如eval），然后报出来“这里有漏洞”。
为什么不好
- 智能体里很多调用是运行时才决定的 比如代码里写的是tools.get(tool_name).run()，工具名是字符串，运行时才确定。静态分析只能看到“有个方法被调用了”，但不知道具体调的是谁——调用链断了。
- 判断不了“参数能不能被用户控制” 它看到eval(something)，但不知道这个something是不是来自用户提示词。很多情况是写死的字符串，但静态分析分不清，只能“宁可错杀一千”，导致大量假阳性。
- 不懂自然语言语义 它只看代码，不看提示词。就算找到一条调用链，也不知道“什么样的提示词才能触发这个链”。你让它报漏洞，它报不出来；你让它别报，它乱报。
最终结果：论文里LLMSmith报了332个假阳性，才命中10个真漏洞。精度不到3%，基本没法用。
传统Fuzz：它不会“说人话”
Fuzz本来是干嘛的？
- 不断乱改输入（比如改几个字符），看能不能把程序搞崩
但问题来了：
智能体的输入是自然语言 不是JSON、不是二进制、不是固定格式
你如果这样乱改：
请帮我查天气 → 请帮我查天x气%$#
这样LLM直接就懵了，根本不会触发任何逻辑
所以本质问题是：
“
传统Fuzz不会生成“有意义的句子”，更别说触发特定功能
只靠Prompt防护：等于用规则对抗规则
很多人会这样做：
在系统提示词里写：
- “不要执行危险操作”
- “不要运行代码”
听起来合理，但问题是：
攻击本身也是用“语言”来的（提示词注入）
换句话说：
“
你用一句话去限制另一句话，本质上是对抗不了的
攻击者只要稍微绕一下：
- 改表达方式
- 加上下文
- 诱导模型
规则就失效了
“
一句话总结:静态分析看不懂动态路径，Fuzz不会生成有效语义，Prompt防护又挡不住语言攻击——这三种方法在LLM智能体场景下，都踩在了“语义”这个盲区上。
AgentFuzz在做的事情，本质上是“让Fuzz理解语义”
这篇论文的核心贡献，不只是发现漏洞，而是提出了一种更适配智能体的漏洞挖掘方式。
可以理解为：把传统定向灰盒Fuzz(DGF)扩展到“语义空间”里。
作者根据所面临的几大挑战分别给出了相应的解决方案：
1. 用LLM生成“能触发组件”的测试种子
“
如何生成特定功能的自然语言种子？
传统Fuzz生成的是随机输入，而AgentFuzz的做法是：
- 从漏洞点（如
eval）反向分析调用链（sink调用链提取） - 利用类名/方法名中的语义信息（例如
calculator → eval） - 结合one-shot示例和CoT，引导LLM生成提示词
例如生成：
“
“请用计算器组件计算表达式：3*(4+5)”
这样可以更稳定地触发目标组件，而不是盲目尝试。
2. 种子选择：不仅看路径，也看语义
“
如何在Fuzz的过程中优先处理高质量种子以提高Fuzz的效率？
在选择哪些输入继续突变时，AgentFuzz没有只依赖“距离漏洞点有多近”进行选择，而是引入了多维评估：
- 语义匹配程度：由LLM结合执行轨迹评估
- 距离匹配度：与目标sink的路径距离
- 对重复路径的惩罚
这种“语义 + 路径”的组合，比单纯依赖代码距离更适合智能体这种动态执行环境。
3. 双突变机制：分别处理“语义问题”和“约束问题”
“
如何有效对种子进行变异以触发污点式漏洞？
这是我个人觉得比较关键的一点。
很多情况下，提示词已经触发了正确组件，但由于参数不满足代码条件，执行路径无法继续向下。
AgentFuzz在这里做了拆分处理：
功能变异器（语义层）
当提示词语义不够准确时，利用易受攻击组件的调用链优化种子的自然语言语义，有助于缓解间接调用问题，并生成能有效调用具有所需功能组件的提示词。
参数变异器（约束层）
精准破解代码里的条件约束，再把满足约束的内容，无缝嵌回测试提示词的对应位置，既不破坏语义，又能让载荷流到漏洞点。
大致流程：
- 先找 “卡点”：通过符号执行，定位代码里拦住载荷的条件（比如论文里的content必须包含source_doc:），明确要满足什么规则才能走到漏洞处；
- 再解 “卡点”：用 Z3 求解器，算出能满足这个条件的具体参数值（比如直接生成source_doc:xxx这种格式）；
- 最后 “嵌回去”：用最长公共子串匹配，精准找到提示词里的「数据部分」，只把求解出的内容替换 / 插入进去，不动提示词的动作描述，保证 LLM 还能看懂、能触发目标组件。
例如当约束要求包含source_doc:时，就在对应位置补充这一结构。
这种“语义和约束分开处理”的方式，在工程上会更容易控制。
实验结果：可以认为是范式上的变化
论文在20个主流开源智能体上进行了测试（包括AutoGPT、LangFlow、DB-GPT等）。
结果大致是：
- 发现34个0day漏洞
- 涉及14个项目
- 在实验设置下达到100% precision（未观察到假阳性）
- 平均约121.8分钟发现一个漏洞
- 其中已有23个漏洞被分配CVE编号
和LLMSmith对比时，可以看到明显差距，但更值得关注的是：
这种方法更接近于范式上的变化，而不仅仅是性能提升。
一个值得注意的细节：漏洞往往需要“组合利用”
论文中有一个点我觉得容易被忽略，但其实很关键：
- 一部分漏洞需要结合prompt injection才能触发
- 还有一部分需要结合sandbox escape才能完整利用
这说明在实际攻击中，很可能不是单一漏洞，而是：
“
语言层攻击 + 传统漏洞利用 的组合
从这个角度看，LLM智能体更像是一个“复合攻击面”。
我的一些理解（不完全等同于论文结论）
这里是我读完之后的一些判断，不完全是论文原话。
1. 智能体正在变成“可被间接驱动的执行入口”
当系统具备：
- 自然语言输入
- 工具调用能力
- 代码/数据访问能力
如果缺少边界控制，就可能演变成一个“可被输入影响执行行为”的入口。
2. 安全问题正在从“模型”转向“系统”
相比早期关注的模型越狱、幻觉等问题，这类漏洞更接近传统安全里的数据流问题：
“
如何保证输入在经过处理后，不会变成危险操作的参数
这本质上是系统设计问题，而不是模型本身的问题。
3. 漏洞挖掘正在进入“自动化对抗”阶段
AgentFuzz的意义在于：用具备语义理解能力的系统去发现另一个系统的漏洞。
如果这一思路被进一步工程化，漏洞发现的效率很可能会持续提升。
总结
其实也不能算总结，只是一些比较实际的点：
1. 不要默认LLM输出是安全的更合理的做法是，把它当作“可能受输入影响的数据”，在进入敏感操作前进行校验。
2. 敏感操作尽量隔离执行包括代码执行、系统命令、数据库操作等，建议放在受限环境中运行，并控制权限和资源。
3. Prompt约束可以有，但不要依赖它更像是一层辅助过滤，而不是安全边界。
这篇论文给我的一个直接感受是：
“
LLM智能体的漏洞，不再只是“能不能被发现”，而是“能多快、以什么规模被发现”。
当这一点发生变化时，安全本身的优先级，也需要跟着调整。
“
论文原文：https://zenodo.org/records/15590097
开源代码：https://github.com/LFYSec/AgentFuzz
z3solver入门手册：https://zhuanlan.zhihu.com/p/1970166511667750864
符号执行：https://blog.csdn.net/qq_44889099/article/details/134327165
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：沐昊安全 俗说君 俗说君《用Agent打败Agent：LLM智能体漏洞，正在进入自动化挖掘阶段（Agentfuzz）》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论