提示注入不是提示问题：RAG管道的信任边界缺失

检索增强生成（RAG）应用将检索到的文本与指令拼接后一起送入模型。当这段检索文本由攻击者编写时，模型就在同一通道里同时收到了攻击者提供的指令和运营者提供的指令。从那一刻起，任何提示措辞都不再构成边界——攻击者的文本与其检索上下文享有同等权威。这不是一个可以通过改提示词解决的问题，而是一个系统设计层面的信任边界缺陷。

缺失的那条边界

在传统应用中，来自不可信来源的数据会被解析、验证和引用，它不会变成可执行内容。SQL注入之所以变得可控，是因为查询与数据被分离开来，而这种分离依赖数据库强制的机制，而非开发者记住的规范。

语言模型默认没有这种等价隔离。它的输入是一个token流，指令与内容在语法上无法区分。上下文窗口中的任何文本都可能影响模型行为，一份刻意写入指令的文档，和一份恰好提到指令的文档，在模型看来并无本质区别。

这一根本原因决定了：把安全寄托在提示词的措辞上，是把边界放在了错误的位置。真正需要建立的是类似“查询与数据分离”的强制机制，而不是依赖模型“理解”哪些内容可信。

SQL注入的防护核心在于预编译语句（Prepared Statement）和参数化查询：数据库驱动将SQL语句结构与用户输入数据作为两次独立的传输与解析过程处理，数据部分被严格绑定为字面量，永远不会被解析为SQL语法。这种隔离由数据库引擎强制执行，不依赖开发者是否「记得」转义。语言模型则完全不同——它没有语法层面的指令/数据区分机制，所有输入被平铺为同一个token序列，模型通过注意力机制在整个上下文窗口中建立关联，无法从架构上标记某段文本「仅作数据、不可执行」。这意味着RAG管道无法照搬参数化查询的方案，只能通过外部控制（权限约束、输出校验）来补偿这一架构性缺失。

风险暴露在哪里

原文给出了一个关键判断：风险与应用在模型输出之后能做什么成正比。

只读检索：可逆但严重

一个在语料库上做问答的检索系统，可能泄露用户有权访问的内容，或返回错误信息。这类风险严重，但通常可逆——影响停留在信息层面，不会直接触发外部动作。

工具访问：不可逆的动作

接入工具的系统性质不同。如果模型能调用API、发送消息、写入数据库或执行代码，那么一条被执行的注入指令，就是以应用权限和用户会话身份采取的实际动作。这个动作可能删除数据、发出邮件或调用付费接口，后果往往不可逆。

两类系统之间的差距是一个设计决策，而这个决策常常在“顺手加个工具”的便利中被隐式做出。很多团队在添加工具时只考虑了功能覆盖，却没有同步评估权限边界。

降低暴露面的控制手段

原文给出了若干控制措施，它们的共同逻辑是缩小成功注入的后果，而非阻止注入发生。

把检索内容当作数据对待

用模型被训练为视为不可信的结构包裹检索内容，并把指令排除在该结构之外。这有帮助，但不解决问题——对抗性内容下的行为是概率性的。任何声称“这样就不会被注入”的方案都值得怀疑。

「用模型被训练为视为不可信的结构包裹检索内容」通常指在检索文本外包一层特殊分隔标记（如XML标签、特殊token或系统提示中声明的边界符），让模型在训练分布上倾向于将标记内内容视为参考资料而非指令。但这种方法本质上仍是「概率性软边界」：攻击者可以在包裹内容中构造与边界符相似的模式、利用模型对嵌套结构的理解偏差，或通过改写绕过训练时见过的模式。业界已有多项研究证明，仅靠分隔符或系统提示加固，在自适应攻击面前防护率会显著下降。因此它只能作为纵深防御的一层，不能替代权限模型这类硬约束。

约束工具权限

每个工具都应具备满足用例的最窄权限，并限定在当前用户范围内，而非应用的服务身份。注入指令只能造成工具权限允许范围内的损害。这是整个防护体系中最关键的一环——权限模型是唯一能实际压缩风险的地方。

「服务身份」指的是应用后端以自身凭据调用下游API的模式，此时所有用户共享同一套高权限凭证；一旦模型被注入操纵，攻击者就能以应用的全量权限行事。「用户范围限定」则要求工具调用携带当前终端用户的身份令牌（如OAuth delegated token），使下游系统按该用户的实际权限做授权判定。这类似于数据库的行级安全（Row-Level Security）：即使查询语句被篡改，数据库仍会按当前会话主体的权限过滤结果。实践上还应对工具做能力最小化——例如只读工具不授予写权限、发邮件工具限定收件人白名单、数据库工具限定表与操作类型，从而把单次注入的可达损害压缩到业务可接受的范围内。

对后果性动作要求确认

改变状态、发送数据或产生费用的动作，应要求人工决策或独立的二次校验。这个确认是模型无法自行跨越的边界。把不可逆操作交给人类确认，本质上是把信任边界外部化。

按模式校验输出

在执行前校验工具调用是否符合预期结构，不匹配则拒绝。这能捕获乱码输出和部分重定向尝试。这类校验的成本低、收益明确，应当成为默认实践。

限制运行时出口

检索管道很少需要任意互联网地址。限制其网络访问，可以在模型被操纵时限制数据外泄。这一措施与工具权限约束形成互补：一个管“能做什么”，一个管“能发到哪里”。

检测很弱，所以要为遏制而设计

原文做出了一个务实判断：没有可靠的注入检测器，因为承载面和攻击本身是同一通道。过滤器能抓住已知模式，却会在改写面前失效。

因此，依赖检测注入的设计是脆弱的，依赖限制成功注入影响的设计才是持久的。这与内存破坏的防护思路一致：你无法证明漏洞利用永远不会发生，所以你要限定损害范围并检测尝试行为。

日志记录的重点也需要调整——记录模型用工具做了什么，而不只是它说了什么。一次工具调用及其参数、用户会话、以及它之前检索到的文档，这些记录回答了事件调查的核心问题，且往往是唯一可用的证据。

「承载面和攻击本身是同一通道」是说：注入攻击的载荷就是自然语言文本，而模型的本职工作正是理解和遵循自然语言。任何检测器都必须在同一token流中判断「这段文本是数据还是指令」，而这恰是模型架构本身无法可靠区分的问题。基于模式匹配的过滤器只能覆盖已知攻击串，攻击者通过同义改写、编码混淆、多语言转换或分片拼接即可绕过。这与内存安全领域的现实类似：地址空间布局随机化（ASLR）和栈保护（Stack Canary）并不能阻止所有漏洞利用，但能显著提高利用难度并限制影响；而日志与异常行为检测则用于事后发现和响应。将这一思路迁移到RAG，意味着把工程投入从「阻止注入」转向「限定注入成功后的损害半径」与「保证可审计」。

设计评审该问的问题

对每一个具备工具访问的AI功能，评审时应问：如果检索内容由攻击者编写，模型能采取的用户不会察觉的最坏动作是什么？

这个答案就是风险本身，而工具权限模型是唯一能降低它的地方。把这个问题固化进设计评审流程，比任何提示词加固都更有价值。