[论文学习]面向提示注入防御的LLM智能体设计模式

Design Patterns for Securing LLM Agents against Prompt Injections論文重點由Luca Beurer-Kellner等14位作者联合完成系统性地提出了六种用于构建LLM智能体的设计模式旨在为提示注入攻击提供可证明的防御能力。核心观点是与其试图构建无所不能的通用智能体并寄希望于启发式检测不如有意识地限制智能体的能力边界通过系统级隔离设计在安全性与实用性之间取得可量化的平衡。核心研究內容問題定義提示注入攻击是LLM智能体面临的最严峻安全威胁之一。当智能体被授予工具调用权限或需要处理敏感信息时攻击者可以通过在用户输入或第三方数据中嵌入恶意指令操纵模型执行未授权操作。现有防御手段可分为三类LLM层面的防御如提示工程、对抗训练缺乏理论保证用户层面的防御如人工确认严重损害自动化体验系统层面的隔离机制虽有前景但缺乏系统化的设计指导。本文的核心问题是在当前的LLM技术条件下我们能构建什么样的智能体既能完成有用工作又能对提示注入具备可验证的抵抗力創新方法作者跳出“让模型变得更鲁棒”的传统思路提出了一条截然不同的路径通过系统架构设计从根本上限制攻击面。其核心原则是一旦LLM智能体摄入了不可信输入就必须被约束到不可能让该输入触发任何具有负面影响的后果性动作。基于这一原则论文提出了六种可组合的设计模式按安全强度从低到高排列Action-Selector Pattern动作选择器模式智能体仅作为“翻译器”将自然语言请求映射到预定义的有限动作集合。动作执行结果不反馈给智能体使其对提示注入天然免疫。这是最严格的模式适合客服机器人等场景。Plan-Then-Execute Pattern计划-执行模式智能体在接受用户指令后先制定一个固定的工具调用计划然后执行该计划。工具返回的不可信数据不能影响智能体后续的动作选择相当于实现了“控制流完整性”保护。但该模式无法防止用户输入本身携带的注入。LLM Map-Reduce PatternLLM Map-Reduce模式将任务分解为“映射”和“归约”两个阶段。隔离的子智能体分别处理独立的第三方数据片段每个子智能体被严格限制如只能输出布尔值即使被注入也无法造成危害。Dual LLM Pattern双LLM模式区分特权LLM有工具访问权限但不处理不可信数据和隔离LLM处理不可信数据但无工具权限。隔离LLM的输出以符号引用的形式返回特权LLM只能按引用操作而无法直接解引用内容从而彻底阻断注入路径。Code-Then-Execute Pattern代码-执行模式智能体编写正式的计算机程序来解决任务程序可调用工具和生成子LLM实例。程序编写完成后在不可信数据上执行将“规划”与“执行”彻底分离。Context-Minimization Pattern上下文最小化模式在多轮交互中主动移除不必要的上下文内容。例如将用户请求转化为数据库查询后在执行返回前移除原始用户提示防止注入影响后续响应。研究成果论文通过十个跨领域的案例研究验证了这些设计模式的有效性涵盖操作系统助手、SQL智能体、邮件日历助手、客服机器人、预订助手、产品推荐、简历筛选、医疗问答、诊断聊天机器人及软件工程智能体。每个案例均从“朴素实现→应用设计模式→安全性与实用性权衡”三个层次进行分析。核心发现包括通用智能体在可预见的未来难以提供可靠的安全保证因为LLM本身的对抗鲁棒性问题经过十余年研究仍未解决通过有意识地限制智能体的任务范围可以在不严重损害实用性的前提下获得可证明的安全性设计模式可以组合使用不同场景需要不同的安全-效用权衡策略。實際落地應用的可能性这些设计模式并非理论构想而是可直接投入生产实践的架构指南。例如客服机器人可直接采用Action-Selector模式将用户请求映射到固定的操作集合文件处理智能体可采用Map-Reduce模式让隔离的子LLM逐文件处理控制器仅基于结构化结果做决策需要复杂推理的场景可采用Dual LLM或Code-Then-Execute模式在保持灵活性的同时隔离不可信数据。论文作者来自ETH Zurich、Google、Microsoft、IBM等机构案例均基于真实应用场景具有高度的工程参考价值。技術細節设计模式的核心机制符号引用机制Symbolic References是Dual LLM模式的关键技术。隔离LLM处理不可信文本后不直接返回内容而是将结果存储在特殊变量中如$VAR。特权LLM可以按符号操作这些变量如调用send.email($VAR)但无法解引用查看其内容。真正的解引用由非LLM的“编排器”Orchestrator在函数调用时完成。这一机制从根本上杜绝了注入内容进入特权LLM上下文的可能性。控制流完整性Control-Flow Integrity是Plan-Then-Execute模式的理论基础。智能体在执行前“承诺”一个固定的工具调用序列后续任何来自不可信数据的输入都无法改变这一序列。这类似于传统安全领域的控制流完整性保护——即使数据被污染控制流保持不变。安全保证的形式化描述论文给出的安全保证可形式化表述为设智能体的动作空间为 (A)不可信输入为 (x)系统提示为 (s)。在未应用设计模式时[\text{Action}(x) \subseteq A \quad \text{攻击者可诱导任意动作}]应用Action-Selector模式后[\text{Action}(x) \subseteq A_{\text{pred}} \subset A \quad \text{动作被限制在预定义子集}]应用Plan-Then-Execute模式后[\text{Plan}(s) P, \quad \text{Execute}(P, x) \text{ 不改变 } P \quad \text{计划固定执行不受注入影响}]案例技术细节OS Assistant以操作系统助手为例朴素实现直接给LLM访问完整Shell的权限 → 任意文件可注入指令执行任意代码Action-Selector硬编码预定义命令集合 → 完全免疫注入但丧失灵活性Plan-Then-ExecuteLLM承诺固定的命令序列 → 防止执行计划外命令但命令参数仍可被操控Dual LLM/Map-Reduce控制器调度隔离的子LLM逐文件处理子LLM输出被约束为布尔值或预定义类别 → 单个恶意文件最多影响该文件的处理结果。案例技术细节SQL AgentSQL智能体案例展示了模式的组合应用数据库内容应被视为不可信输入源采用Code-Then-Execute模式生成SQL查询和Python分析代码后执行避免LLM直接处理查询结果配合Action-SandboxingPython代码执行必须在沙箱环境中进行防止恶意代码危害生产环境配合Ask-The-User模式在关键操作前寻求用户确认。研究設定实验设计论文未采用传统的量化实验如攻击成功率对比而是采用了案例研究法针对十个真实应用场景逐一分析“朴素实现→应用设计模式→安全性与效用权衡”的设计空间。每个案例均明确定义应用场景与功能需求威胁模型攻击者可控制哪些输入、攻击目标是什么多种设计方案及其安全-效用权衡硬件/软件配置论文为架构层面的研究不依赖特定硬件配置。软件层面涉及LLM不特定于某一模型设计模式适用于任意指令调优的LLM工具接口智能体通过Agent Computer Interfaces与外部系统交互编排器Orchestrator非LLM的传统软件组件负责工具调用调度和符号引用解引用沙箱环境用于隔离代码执行。綜合分析核心洞见从“模型安全”到“系统安全”本文最根本的贡献在于范式转换它将提示注入从“模型鲁棒性问题”重新定义为“系统架构问题”。作者敏锐地指出经过十余年研究对抗性样本在计算机视觉领域仍是未解难题寄望于LLM本身对提示注入具备鲁棒性是不现实的。真正的出路在于系统级设计——即使底层模型可以被任意操纵整个智能体系统仍然保持安全。这一洞见具有深远意义。它意味着安全研究者不应将全部精力投入“如何让模型不被骗”而应思考“如何设计系统让模型被骗了也没事”——后者是一个工程可解的问题。安全性-实用性权衡的量化视角论文的价值不仅在于提出了设计模式更在于系统性地分析了每种模式的安全性与实用性权衡。从Action-Selector最安全、最不灵活到Code-Then-Execute较灵活、安全性依赖于实现质量形成了一个完整的设计光谱。开发者可以根据具体场景的安全需求选择适当的模式而非在“完全不安全”和“完全不能用”之间二选一。与现有工作的对比现有防御手段多为启发式——输入输出过滤器、对抗训练、异常检测等。这些方法“提高了攻击门槛”但无法提供任何保证。相比之下本文的设计模式提供的安全保证是架构层面的不是因为模型“学会”了拒绝注入而是因为系统设计使得注入在结构上不可能触发危险动作。局限性与待解决问题论文未回避设计模式的局限性Action-Selector将大部分工作推给了预定义动作的设计可能丧失LLM的灵活优势Plan-Then-Execute无法防止注入操控工具调用参数如将邮件发送给攻击者Map-Reduce要求任务可分解为独立的子任务并非所有场景都适用Dual LLM的符号引用机制增加了系统复杂度。此外论文明确指出这些设计模式不能解决用户输入本身的注入问题——如果用户是恶意的Context-Minimization模式只能部分缓解。實踐應用应用决策指南场景特征推荐模式理由动作空间有限、可预先枚举如客服机器人Action-Selector完全免疫注入实现简单任务可预先规划、无需根据中间结果调整Plan-Then-Execute控制流完整性保证需处理大量独立数据片段如文件批量处理Map-Reduce隔离单点故障并行处理需处理不可信文本但保持高灵活性Dual LLM符号引用彻底隔离注入复杂任务需生成代码执行Code-Then-Execute规划与执行分离多轮对话场景Context-Minimization配合其他模式使用落地实践建议从威胁建模开始明确攻击者可控制哪些输入用户输入第三方数据数据库内容以及攻击者可能的目标数据泄露代码执行权限提升。默认采用最小权限原则智能体的工具访问权限应严格限于完成任务所必需的最小集合。组合使用设计模式如SQL Agent案例所示可同时采用Code-Then-Execute隔离数据与LLM、Action-Sandboxing隔离代码执行和Ask-The-User人工确认关键操作。区分可信与不可信数据流核心原则是——特权组件永不处理不可信数据处理不可信数据的组件永不拥有特权。将“最佳实践”作为基线论文附录A中提到的通用最佳实践如沙箱执行、用户确认等应作为所有LLM智能体的基线安全措施。參考資料來源原始论文: https://arxiv.org/abs/2506.08837PDF全文: https://arxiv.org/pdf/2506.08837作者: Luca Beurer-Kellner, Daniel Dobos, Kathrin Grosse, Beat Buesser, Daniel Fabian, Daniel Naeff, Ana-Maria Crefu, Marc Fischer, Ezinwanne Ozoani, Vaclav Volhejn, Andrew Paverd, Florian Tramer, Edoardo Debenedetti, David Froelicher