IPIGuard: A Novel Tool-Dependency Graph-Based Defense Against Indirect Prompt Injection in LLM Agents (2025)

论文重点

本文提出了一种名为IPIGuard的全新防御范式，通过将LLM智能体的任务执行过程建模为工具依赖图（Tool Dependency Graph, TDG） 的遍历，从根本上阻断间接提示注入（IPI）攻击引发的恶意工具调用。实验表明，该方法在AgentDojo基准测试上实现了平均攻击成功率仅0.69%，同时保持了58.77%的实用准确率，在安全性与任务完成度之间取得了优于现有所有防御方案的平衡。

核心研究内容

问题定义

LLM智能体在真实世界应用中需要调用各类工具来获取和操作外部数据。然而，当智能体与不可信数据源（如公共网站）交互时，工具返回的内容中可能嵌入恶意指令——即间接提示注入攻击。这类攻击的现实威胁并非纸上谈兵：研究人员曾通过Google文档中注入的隐藏提示成功操控Gemini for Workspace发送欺诈邮件；攻击者还利用网页中嵌入的恶意文本，诱使OpenAI的ChatGPT Operator泄露敏感信息。

现有防御手段主要依赖高级提示策略或辅助检测模型，本质上仍依赖于对模型自身安全性的假设，缺乏对智能体行为的结构性约束。这意味着智能体在执行过程中仍可不受限制地调用任何工具，攻击者只需绕过模型的安全护栏即可触发恶意工具调用。

创新方法

IPIGuard的核心洞察在于：将动作规划与外部数据交互彻底解耦。传统范式中，智能体在每一轮根据当前状态动态生成工具调用，这使得一旦工具响应中包含恶意指令，后续步骤便极易被操控。IPIGuard则引入了一个独立的规划阶段，让智能体在执行任务之前先构建一个完整的工具依赖图（TDG），将整个任务所需的工具调用及其依赖关系预先定义清楚。

TDG是一个有向无环图（DAG），每个节点代表一个具体的工具调用（包括工具名称和参数），有向边表示节点间的数据依赖关系。节点根据参数是否已知分为两类：确定性节点（所有参数在规划阶段已确定）和待定节点（部分参数需从其他工具的输出中推断）。

然而，将规划与执行解耦会带来三个关键挑战：

1. 未知参数问题：许多工具的参数在规划阶段无法预知，必须依赖其他工具的执行结果。
2. 静态计划适应性不足：完全禁止执行期间新增工具调用会限制智能体的适应能力。
3. 任务工具重叠问题：当注入任务与原始任务使用相同的工具时，攻击者只需篡改参数即可完成攻击。

针对这三个挑战，IPIGuard分别设计了三种机制：

• 参数估计（Argument Estimation） ：按拓扑顺序遍历TDG，从执行上下文中获取依赖工具的输出，动态推断待定节点的未知参数。
• 节点扩展（Node Expansion） ：借鉴命令查询职责分离（CQRS）模式，将工具分为只读的“查询工具”和修改环境的“命令工具”。执行期间只允许新增查询工具调用，既能保证任务完成度，又不会引入安全风险。
• 虚假工具调用（Fake Tool Invocation） ：当遇到工具重叠场景时，不是直接更新参数，而是模拟一次工具调用并注入虚假响应到执行上下文中，让智能体专注于完成原始用户任务。

研究成果

在AgentDojo基准测试上，IPIGuard在六种不同LLM（包括GPT-4o、GPT-4o-mini、Claude 3.5 Sonnet、Qwen2.5-7B-Instruct、Qwen3-32B和OpenAI o4-mini）上进行了全面评估。

安全性能：在四种主流IPI攻击（Ignore Previous、InjecAgent、Tool Knowledge、Important Instruction）下，IPIGuard的攻击成功率从未超过1%，平均仅0.69%。相比之下，无防御基线为13.16%，Detector为4.43%。

实用性能：在无攻击场景下，IPIGuard的良性实用率（BU）达到67.01%，接近无防御基线的68.04%。在攻击场景下，其实用准确率（UA）为58.77%，显著优于Detector的26.50%。

消融研究：单独使用虚假工具调用可将ASR降至0.32%，单独使用节点扩展可将BU提升至64.95%，两者结合则达到最佳整体表现（BU 69.07%，UA 57.07%，ASR 0.64%）。

开销评估：相比无防御基线，IPIGuard的token使用量增加约两倍，但考虑到安全性的显著提升，这一代价在安全敏感场景中是值得的。

实际落地应用的可能性

IPIGuard的架构设计使其具备良好的落地可行性。首先，该方法不依赖特定模型，可适配不同LLM进行规划和执行。其次，其核心逻辑——规划阶段构建TDG、执行阶段按图遍历——可以模块化地集成到现有Agent框架中。作者已开源代码（https://github.com/Greysahy/jpiguard），为实际部署提供了参考实现。

对于银行转账、邮件发送、订票系统等涉及写操作的高风险场景，IPIGuard的结构性约束能够有效防止恶意指令触发危险操作。对于需要从外部数据源读取信息的场景，节点扩展机制保证了足够的灵活性。

技术细节

TDG的形式化定义

给定用户指令$\mathcal{I}$，智能体${\pi }_{\mathcal{A}}$通过一系列工具调用来完成任务：

T={t1(a1),t2(a2),…,tn(an)}\mathcal{T}=\{t^{1}(\mathbf{a}^{1}),t^{2}(\mathbf{a}^{2}),\ldots,t^{n}(\mathbf{a}^{n})\}T={t1(a1),t2(a2),…,tn(an)}

其中每次调用$t^i({\mathbf{a}}^i)$包含工具$t^i$及其参数${\mathbf{a}}^i$。工具$t^i$作用于当前环境状态${\mathcal{E}}_{i-1}$，产生更新后的状态：

$$t^i({\mathbf{a}}^i)\times {\mathcal{E}}_{i-1}\to {\mathcal{E}}_i$$

IPI攻击发生时，原本的工具调用序列被篡改：

$${\mathcal{T}}_u\to {\mathcal{T}}_{u^{\prime }},{\mathcal{T}}_{adv}\subseteq {\mathcal{T}}_{u^{\prime }}$$

其中${\mathcal{T}}_{adv}$是由注入指令触发的恶意工具调用序列。

TDG将上述过程建模为有向无环图$G=(V,E)$。每个节点$v\in V$代表一个工具调用，有向边$E(u,v)$表示节点$v$依赖于节点$u$的输出。

三种机制的核心逻辑

参数估计：对于待定节点，智能体从执行上下文中获取依赖节点的响应，推断并补全未知参数，将其转化为已解析节点（Resolved Node）后再执行。

节点扩展：执行期间，若智能体判断需要新增工具调用，系统会过滤出查询工具（只读操作），创建查询扩展节点（Query Expanded Node）并链接到当前节点。命令工具（写操作）则被严格禁止新增。

虚假工具调用：当检测到工具重叠时，系统不执行真实调用，而是注入模拟响应到上下文中，制造“指令已被处理”的假象，让智能体专注于原始任务。

规划提示模板

IPIGuard的规划阶段向LLM输入三类信息：（1）用户指令；（2）工具描述（名称和必需参数）；（3）系统上下文（用户画像和相关背景，如用户指定的可信文档内容）。LLM基于这些信息生成TDG的文本描述，包括每个节点的执行顺序。

研究设定

• 基准测试：AgentDojo，包含97个任务，覆盖Workspace、Slack、Travel、Banking四个域，共629个测试用例。该基准强调多轮交互场景，每个任务最多需执行18次工具调用。

• 测试模型：六种模型——GPT-4o、GPT-4o-mini、Claude 3.5 Sonnet（闭源非推理模型）；Qwen2.5-7B-Instruct（开源非推理模型）；Qwen3-32B、OpenAI o4-mini（推理模型）。

• 攻击类型：四种主流IPI攻击——Ignore Previous、InjecAgent、Tool Knowledge、Important Instruction。

• 基线方法：Detector、Tool Filter、Spotlight、Sandwich Prompting，以及无防御基线。

• 评估指标：Benign Utility（BU，无攻击时任务完成率）、Utility under Attack（UA，攻击场景下任务完成率）、Targeted Attack Success Rate（ASR，攻击者目标达成率）。

• 硬件配置：论文未明确列出具体硬件配置，但鉴于测试涉及GPT-4o、Claude 3.5 Sonnet等闭源模型的API调用，以及Qwen系列开源模型的本地部署，建议配备至少24GB显存的GPU（如RTX 3090/4090或A100）用于开源模型推理。

综合分析

范式转换的价值：IPIGuard最根本的贡献不在于提出了一种新的检测或过滤方法，而在于重新定义了LLM智能体应该如何执行任务。它将安全重心从“让模型更聪明地识别恶意指令”转移到“从执行架构上杜绝恶意调用的可能”。这种从模型中心化到执行中心化的范式转换，对于LLM安全领域具有启示意义——与其不断给模型打补丁，不如从系统设计层面约束行为边界。

三个设计决策的权衡：

• 参数估计解决了规划与执行解耦后的核心痛点，但其效果高度依赖LLM的推理能力。论文指出，使用更强的LLM进行规划可显著提升性能且成本增幅有限，这为实际部署提供了灵活的性价比优化空间。

• 节点扩展体现了IPIGuard并非“一刀切”的安全方案。通过区分查询工具和命令工具，它在安全性和实用性之间找到了一个合理的平衡点。不过，如何准确分类工具、如何防止攻击者将危险操作伪装成查询操作，仍需要工程上的审慎设计。

• 虚假工具调用是一个相当聪明的设计。它没有试图“教育”模型忽略恶意指令（这往往不可靠），而是通过模拟执行来满足模型的指令跟随倾向，引导其回到正轨。这种“顺着模型天性走”的思路，比对抗性训练更轻量、更可预测。

局限性与未来方向：论文坦诚指出，ASR未能完全归零的原因是虚假工具调用在极少数边界情况下可能失败。此外，Workspace场景下BU略低，源于对“基于工具响应执行具体操作”类任务的保守处理。这些都为后续研究指明了方向。

实践应用建议

1. 优先在写操作密集的场景部署：如果您的Agent涉及银行转账、邮件发送、订单修改等操作，IPIGuard的结构性约束能提供最强保护。对于纯信息检索类Agent，收益可能不那么显著。

2. 规划与执行可采用不同模型：论文验证了使用更强模型做规划、较弱模型做执行可优化性价比。在实际部署中，可以用GPT-4o或Claude 3.5 Sonnet生成TDG，用Qwen2.5-7B或GPT-4o-mini执行任务。

3. 工具分类需谨慎：节点扩展机制的有效性依赖于查询工具与命令工具的正确分类。建议在接入新工具时建立严格的分类审查流程，避免将具有副作用的操作误标为查询工具。

4. 监控虚假工具调用的触发频率：频繁触发虚假工具调用可能意味着存在持续的攻击尝试，也可能是工具重叠场景的常规表现。建立监控看板区分这两种情况，有助于及时调整策略。

5. 从简单场景开始逐步扩展：IPIGuard引入了一定的token开销（约两倍于无防御基线）。建议先在风险最高、任务复杂度适中的场景试点，积累运维经验后再推广到更复杂的任务流。

参考资料

• 原始论文：An, H., Zhang, J., Du, T., Zhou, C., Li, Q., Lin, T., & Ji, S. (2025). IPIGuard: A Novel Tool Dependency Graph-Based Defense Against Indirect Prompt Injection in LLM Agents. arXiv:2508.15310. https://arxiv.org/abs/2508.15310
• 官方代码仓库：https://github.com/Greysahy/jpiguard
• AgentDojo基准：https://agentdojo.spylab.ai