防止提示词注入的LLM代理设计模式

保护 LLM Agent 免受提示词注入的设计模式

这篇来自 IBM、Invariant Labs、ETH Zurich、Google 和 Microsoft 等机构 11 位作者的新论文是提示词注入和 LLM 安全文献的一项出色补充。

在这项研究中，我们描述了一些 LLM agent 的设计模式，这些模式可以显著降低提示词注入的风险。这些设计模式限制了 agent 的行为，明确防止它们执行任意任务。我们认为这些设计模式在 agent 的效用和安全性之间提供了一个有价值的权衡。

完整引用如下：Design Patterns for Securing LLM Agents against Prompt Injections (2025)，作者为 Luca Beurer-Kellner、Beat Buesser、Ana-Maria Creţu、Edoardo Debenedetti、Daniel Dobos、Daniel Fabian、Marc Fischer、David Froelicher、Kathrin Grosse、Daniel Naeff、Ezinwanne Ozoani、Andrew Paverd、Florian Tramèr 和 Václav Volhejn。

我很高兴看到这样的论文开始出现。我在四月份写过关于 Google DeepMind 的 Defeating Prompt Injections by Design 论文（即 CaMeL 论文），那是我见过的第一篇针对工具使用 LLM 系统（通常称为 "agents"）的提示词注入提出可信解决方案的论文。

这篇新论文对提示词注入进行了深入的解释，然后提出了六种设计模式来帮助防止它，其中包括 CaMeL 论文提出的模式。

问题的范围

Action-Selector 模式

Plan-Then-Execute 模式

LLM Map-Reduce 模式

Code-Then-Execute 模式

Context-Minimization 模式

这篇论文的作者清楚地理解了问题的范围：

只要 agent 及其防御措施都依赖于当前的语言模型类别，我们认为通用型 agent 不太可能提供有意义的、可靠的安全保证。

这引出了一个更有成效的问题：我们今天能够构建什么样的 agent，既能完成有用的工作，又能抵抗提示词注入攻击？在本节中，我们引入了一套 LLM agent 的设计模式，旨在缓解（如果不是完全消除）提示词注入攻击的风险。这些模式对 agent 施加了有意的约束，明确限制了它们执行任意任务的能力。

这是一种非常现实的方法。我们没有提示词注入的魔法解决方案，所以我们需要进行权衡。他们在这里做出的权衡是"限制 agent 执行任意任务的能力"。这不是一个受欢迎的权衡，但这在我看来给这篇论文增加了很多可信度。

这段话证明了他们完全理解了问题（重点标注我的）：

我们提出的设计模式遵循一个共同的指导原则：一旦 LLM agent 摄入了不可信的输入，它必须被约束，使得该输入不可能触发任何有后果的操作——即那些对系统或其环境产生负面副作用的操作。最少来说，这意味着受限制的 agent 不能调用可能破坏系统完整性或机密性的工具。此外，它们的输出不应该造成下游风险——如泄露敏感信息（例如，通过嵌入的链接）或操纵未来的 agent 行为（例如，对用户查询的有害响应）。

我对此的看法是，任何暴露于潜在恶意令牌的地方都会完全污染该提示的输出。任何能够偷偷注入令牌的攻击者应该被认为对接下来发生的事情有完全控制权——这意味着他们不仅控制 LLM 的文本输出，还控制 LLM 可能能够调用的任何工具调用。

让我们讨论他们的设计模式。

一种相对简单的模式使 agent 免受提示词注入——同时仍允许它们采取外部行动——是防止这些行动的任何反馈流回 agent。

Agent 可以触发工具，但无法接收或根据这些工具的响应采取行动。你不能读取电子邮件或检索网页，但你可以触发诸如"将用户发送到此网页"或"向用户显示此消息"之类的操作。

他们将这种模式总结为"LLM 调制开关语句"，这在我看来是准确的。

一种更宽松的方法是允许来自工具输出的反馈流回 agent，但防止工具输出影响 agent 做出的行动选择。

这里的想法是在任何暴露于不可信内容的机会之前提前规划工具调用。这允许更复杂的行动序列，同时不存在其中一个行动可能引入恶意指令的风险，然后在之后触发计划外的有害行动。

他们的示例将"把今天的日程发送给我的老板 John Doe"转换为 calendar.read() 工具调用，然后是 email.write(..., 'john.doe@company.com')。calendar.read() 的输出可能能够破坏发送的电子邮件的正文，但无法改变该电子邮件的收件人。

之前的模式仍然允许恶意指令影响发送给下一步的内容。Map-Reduce 模式涉及由协调器指导的 sub-agent，这些 agent 暴露于不可信的内容，其结果稍后被安全地聚合。

在他们的示例中，一个 agent 被要求找到包含本月发票的文件并将其发送给会计部门。每个文件由一个 sub-agent 处理，该 agent 返回一个布尔值，表示该文件是否相关。被判定为相关的文件随后被聚合并发送。

他们将其称为 map-reduce 模式，因为它反映了用于分布式计算的经典 map-reduce 框架。

我在这里得到了一次引用！我在 2023 年 4 月描述了用于构建能够抵抗提示词注入的 AI 助手的双 LLM 模式，它也影响了 CaMeL 论文。

他们描述了我的确切模式，甚至用这张图来说明它：

这里的关键思想是特权 LLM 协调被隔离的 LLM，避免任何暴露于不可信的内容。被隔离的 LLM 返回符号变量——例如代表总结网页的 $VAR1——特权 LLM 可以请求将其显示给用户，而不会自己暴露于该被污染的内容。

这是 DeepMind 的 CaMeL 论文描述的模式。它是我的双 LLM 模式的改进版本，其中特权 LLM 在自定义沙箱 DSL 中生成代码，该 DSL 指定应该调用哪些工具以及如何将其输出传递给彼此。

该 DSL 旨在启用完整的数据流分析，以便任何被污染的数据都可以被标记为这样的数据并在整个过程中进行跟踪。

为了防止某些用户提示词注入，agent 系统可以在多次交互中从上下文中删除不必要的内容。

例如，假设恶意用户向客服聊天机器人要求新车报价并试图向 agent 注入提示词来获得大幅折扣。系统可以确保 agent 首先将用户的请求转换为数据库查询（例如，查找最新优惠）。然后，在将结果返回给客户之前，用户的提示词从上下文中删除，从而防止提示词注入。

我对这个有点困惑，但我认为我理解它在说什么。如果用户的提示词被转换为 SQL 查询，该查询返回数据库中的原始数据，并且该数据以不可能包含原始提示词任何文本的方式返回，那么任何提示词注入渗透的机会都应该被消除。

论文的其余部分提供了十个案例研究来说明这些设计模式如何在实践中应用，每个案例研究都附有详细的威胁模型和潜在的缓解策略。

其中大多数都非常实用和详细。例如，SQL Agent 案例研究涉及一个 LLM，具有访问 SQL 数据库和编写及执行 Python 代码的工具，以帮助分析该数据。这是提示词注入的一个高度具有挑战性的环境，论文花了三页来探讨以负责任的方式构建它的模式。

以下是案例研究的完整列表。值得花时间研究任何与你所做工作相对应的：

Email & Calendar Assistant（电子邮件和日历助手）

Customer Service Chatbot（客服聊天机器人）

Resume Screening Assistant（简历筛选助手）

Medication Leaflet Chatbot（药物说明书聊天机器人）

Medical Diagnosis Chatbot（医疗诊断聊天机器人）

Software Engineering Agent（软件工程 Agent）

以下是该最后一个软件工程 Agent 案例研究中的一个有趣建议，关于如何安全地使用来自不可信外部文档的 API 信息：

我们能够考虑的最安全的设计是代码 agent 只通过严格格式化的接口与不可信的文档或代码交互（例如，代替看到任意的代码或文档，agent 只看到正式的 API 描述）。这可以通过用被隔离的 LLM 处理不可信数据来实现，该 LLM 被指示将数据转换为具有严格格式要求的 API 描述，以最小化提示词注入的风险（例如，方法名称限制在 30 个字符）。

效用：效用会降低，因为 agent 只能看到 API，不能看到自然语言描述或第三方代码的示例。

安全性：提示词注入必须能够在被格式化为 API 描述时幸存，如果格式要求足够严格，这不太可能。

我想知道允许最多 30 个字符的方法名称是否确实安全……真正富有创意的攻击者可能想到一个方法名称，如 run_rm_dash_rf_for_compliance()，即使在这些约束下也可能造成混乱。

我已经为提示词注入写了近三年，但我从未有耐心去尝试和制作关于这个主题的正式论文。看到这种质量的论文开始出现是一个巨大的宽慰。

提示词注入仍然是负责任地部署每个人都兴高采烈地构建的那种 agentic 系统的最大挑战。研究社区对这类问题的关注越多越好。

OpenAI 对 Hugging Face 的意外网络攻击是发生的科幻小说 - 2026 年 7 月 22 日

与 Claude Code 团队的 Cat 和 Thariq 的炉边谈话 - 2026 年 7 月 21 日

Kimi K3，以及我们仍然可以从鹈鹕基准学到什么 - 2026 年 7 月 16 日

这是 Design Patterns for Securing LLM Agents against Prompt Injections，由 Simon Willison 发布于 2025 年 6 月 13 日。

系列的一部分：提示词注入

OpenAI 的新音频模型，但我们能依赖它们多少？- 2025 年 3 月 20 日，下午 8:39

Model Context Protocol 存在提示词注入安全问题 - 2025 年 4 月 9 日，下午 12:59

CaMeL 为缓解提示词注入攻击提供了一个有希望的新方向 - 2025 年 4 月 11 日，下午 8:50

Design Patterns for Securing LLM Agents against Prompt Injections - 2025 年 6 月 13 日，下午 1:26

Google AI Agent 安全方法介绍 - 2025 年 6 月 15 日，上午 5:28

AI agent 的致命三角：私有数据、不可信内容和外部通信 - 2025 年 6 月 16 日，下午 1:20

Johann 之夏：提示词注入随处可见 - 2025 年 8 月 15 日，晚上 10:44

下一篇：Google AI Agent 安全方法介绍

上一篇：Comma v0.1 1T 和 2T - 在开放许可文本上训练的 7B LLM

赞助我每月 10 美元，获得该月最重要 LLM 发展的精选电子邮件摘要。

付费让我给你发更少的邮件！