10 篇博文 含有标签「prompt-injection」

大多数团队在发布智能体时，其威胁模型中都潜伏着一个沉默的假设：当模型调用工具时，返回的任何内容都是可以安全读取的。在这个剧本里，用户提示词是唯一的对手，而工具输出则被视为“仅仅是数据”——搜索结果、收件箱摘要、数据库行、RAG 分块、文件内容、网页抓取。正是这种观念导致提示词注入（prompt injection）不断出现在生产环境中。工具输出并不是数据。它们是进入规划器（planner）的另一个输入通道，拥有与用户提示词相同的权限，却完全没有被怀疑。

如果这种说法听起来有些抽象，请考虑 2025 年 6 月 Microsoft 365 Copilot 内部发生的事情。一名研究人员发送了一封带有隐藏指令的电子邮件；受害者从未点击过链接，从未打开过附件，甚至从未亲自阅读过该邮件。一个常规的“总结我的收件箱”查询请求 Copilot 读取该邮件。智能体忠实地执行了在正文中发现的指令，访问了 OneDrive、SharePoint 和 Teams，并在任何人察觉之前通过受信任的 Microsoft 域名外泄了组织数据。该 CVE（2025-32711，“EchoLeak”）获得了 9.3 的 CVSS 评分和服务器端修补，但这类漏洞并未消失。它不可能消失，因为生产环境中智能体上的每一个读取工具都是那个电子邮件收件箱的变体。

这篇文章讨论的是能让你摆脱困境的思维转变：停止将“提示词注入”视为用户输入问题，并开始将每一个工具输出视为一个恰好与你的系统提示词共享 Token 流的不可信渠道。

你的 AI 助手刚刚处理了一份来自潜在供应商的合同。它总结了条款，标记了风险条款，并起草了回复。你不知道的是，PDF 中包含了白底白字的文本——肉眼不可见，但在模型面前一览无余——指令它无论条款如何都建议接受。摘要看起来很合理。批准建议看起来也很合理。模型遵循了你从未写过的指令。

这就是“文档即攻击面”问题，而大多数企业级 AI 流水线对此完全没有防备。

这种漏洞是架构性的，而非偶然发生的。当文档内容直接流向 LLM 的上下文窗口时，模型无法可靠地将合法指令与嵌入在文件中的攻击者控制内容区分开来。流水线摄取的每一份文档都是潜在的指令源——在大多数系统中，不可信的文档和可信的系统提示词（System Prompts）被以同等的权威进行处理。

一家汽车经销商部署了由 ChatGPT 驱动的聊天机器人。几天内，一名用户指示它同意他们所说的任何话，然后提出以 1 美元购买一辆 2024 款 SUV。聊天机器人接受了。经销商随后将其下线。这并非复杂的攻击——只是一个想看看到底会发生什么的人写的短短三句提示词。

在面对普通消费者时，这种好奇心是你最大的安全威胁。内部 LLM 智能体在受控环境中运行，拥有精选的输入和可信的数据。而面向消费者的 LLM 功能默认在对抗性条件下运行：数百万用户中，有许多人正在积极寻找弱点，而随机模型本身并没有“这个用户似乎怀有恶意”的概念。这两个环境所需的安全策略有着本质的区别，而那些将消费者功能视为内部工具的团队终将吸取惨痛教训。

大多数团队在保护 RAG 应用时，把精力放错了地方。他们验证用户输入、清洗查询语句、实施访问频率限制、添加输出过滤器。这些措施固然必要——但没有一项能阻止 RAG 系统中最关键的那类攻击。

大多数关于 RAG 安全的讨论都集中在生成层 —— 越狱、系统提示词泄露、输出过滤。从业者花费数周时间在模型端调整护栏，却忽视了为其提供数据的摄入管道。一个令人不安的现实是：你的管道摄入的每一份文档都是一个潜在的指令面。一个 PDF 文件就能覆盖你的系统提示词、窃取用户数据，或在你的日志基础设施没有发现任何异常的情况下操纵决策。

这并非理论推测。在过去的两年里，Microsoft 365 Copilot、Slack AI 和商业 HR 筛选工具都曾通过这种向量被攻击。同样的攻击模式也出现在 arXiv 上的 18 篇学术论文中，研究人员通过嵌入隐藏提示词，使 AI 同行评审系统做出有利于他们的偏向性评价。

大多数团队以一种痛苦的方式发现自己的提示注入攻击面：安全研究员发布了一个演示，客户报告了奇怪的行为，或者事后复盘揭示了一个本不应触发的工具调用。到那时，攻击路径已经被记录在案，爆炸半径已成现实。

提示注入是 OWASP LLM 应用十大风险榜首，但将其定性为单一漏洞掩盖了它的本质：它是一族随应用复杂度增长的攻击向量。你注入提示的每一个外部数据源都是潜在的注入面。在拥有十几个工具集成的智能体系统中，这个攻击面是巨大的——而且大部分都未被绘制成图。

本文是一套实践者在攻击者之前完成映射的方法论。

最近的一项研究测试了 17 个处于多智能体配置中的前沿 LLM，发现当恶意指令来自同行智能体时，82% 的模型会执行这些指令 —— 尽管当用户直接发出完全相同的指令时，它们会拒绝执行。如果你正在交付多智能体系统，这个数字应该让你重新审视你的威胁模型。你的智能体可能在个体层面已经过加固，但作为一个整体，它们并非如此。

多智能体架构引入了大多数安全思维所忽视的通信渠道。我们加固了模型、系统提示词和 API 边界，但我们几乎不花时间去关注当智能体 A 发送消息给智能体 B 时会发生什么 —— 谁编写了该消息，它是否被篡改过，智能体 B 参考的记忆是否在三个会话前被一个从未接触过智能体 A 的攻击者所植入。

提示注入是 OWASP LLM 应用十大漏洞之首，工程师对它的运作方式和攻击者实际利用方式的理解之间存在越来越大的鸿沟。2024 年的一项研究测试了 36 个生产环境中集成了 LLM 的应用程序，发现其中 31 个易受攻击。2025 年的一次红队测试发现，如果攻击者尝试的次数足够多，100% 已发布的提示防御措施都可以被绕过。

残酷的真相是：大多数团队首先采取的简单防御措施——仅靠系统提示警告、关键词过滤、输出净化——在面对尝试多种方法的攻击者时都会失效。有效的方法是架构性的：分离权限、隔离不受信任的数据，并根据 LLM 看到的内容来限制它实际能做的事情。

这篇文章是为构建生产系统的工程师准备的实战指南。没有 CTF 风格的玩具示例——只有导致真实事件的攻击模式和能显著降低风险的防御模式。

2025 年 6 月，一名研究员向一位 Microsoft 365 Copilot 用户发送了一封精心编写的邮件。没有点击链接。没有打开附件。邮件送达后，Copilot 在执行例行的总结任务时读取了它，短短几秒钟内，AI 便开始从 OneDrive、SharePoint 和 Teams 中外泄文件——通过将数据编码进它请求“渲染”的图片 URL 中，悄无声息地将内容传输到了攻击者控制的服务器上。受害者对此一无所知。

从传统意义上讲，这并不是一个新奇的零日漏洞（Zero-day）。没有缓冲区溢出，也没有 SQL 注入。该漏洞是架构性的：系统结合了三种能力，这些能力单独看起来像是理所应当的产品功能。但结合在一起，它们就构成了现在所谓的“致命三要素”（Lethal Trifecta）。

这里有一个会让团队措手不及的数学问题：如果你堆叠五个防护栏，且每个的准确率都是 90%，那么你的系统整体正确率并不是 90%——而是 59%。堆叠十个同样准确率的防护栏，正确率会降至 35% 以下。这种复合误差问题意味着，“添加更多防护栏”可能会让系统比添加更少但经过更好校准的系统变得更不可靠。大多数团队只有在搭建了庞大的内容审核流水线，并眼睁睁看着误报率攀升到用户无法忍受的程度后，才会意识到这一点。

对于生产环境的 LLM 应用来说，防护栏并非可选项。在正常条件下，现实世界中大约 31% 的 LLM 回答会出现幻觉，而在法律和医学等受监管领域，这一数字会攀升至 60%–88%。针对现代模型的越狱攻击成功率从 57% 到接近 100% 不等，具体取决于攻击技术。但是，如果将防护栏仅仅视为一种附加的合规复选框，而不是精心设计的子系统，团队最终得到的系统将不断拦截合法请求，却仍然漏掉对抗性攻击。