Prompt Injection 防御：隔离不可信上下文的最小复现

Prompt Injection 防御：隔离不可信上下文的最小复现

复现价值与目标：先问"谁有权发指令"

Prompt Injection（提示注入）与普通错误答案不同。攻击目标不是让模型偶尔答错，而是让低信任内容获得本不具备的控制权。直接注入来自当前用户输入；间接注入藏在搜索结果、PDF、代码注释、工具返回或长期记忆里。若系统把"总结这封邮件"和邮件正文拼成一个字符串，模型看到的都是 token，应用却期待它自动理解前者可信、后者不可信，这个期待本身没有形成可执行的安全边界。

本次目标有四个：给每段输入标注来源与信任级别；证明可伪造的 XML 式分隔符不能约束一个仍会扫描整串文本的执行器；让动作只能由可信任务派生；把"模型提议"与"系统执行"拆开，用确定性网关检查工具名、参数和授权范围。实验只覆盖一个微型动作语法，重点是测试数据流，而不是收集攻击咒语。

威胁模型与核心思想：数据能影响答案，不能铸造权限

设可信任务为 T T T，外部记录为 D D D，规划器为 P P P，工具执行器为 E E E。脆弱系统通常计算：

a = P ( T ∥ D ) , y = E ( a ) a=P(T\\Vert D),\\qquad y=E(a) a=P(T∥D),y=E(a)

其中 ∥ \Vert ∥ 表示字符串拼接， a a a 是候选动作。只要 P P P 把 D D D 中的命令当真，数据就进入控制流。结构化设计改成：

c = Mint ⁡ ( T ) , a = P ( T ; D ) , y = E ( a ) iff a ⪯ c c=\\operatorname{Mint}(T),\\quad a=P(T;D),\\quad y=E(a)\\ \\text{iff}\\ a\\preceq c c=Mint(T),a=P(T;D),y=E(a) iff a⪯c

c c c 是仅由可信任务铸造的 capability（能力令牌），包含允许的工具和参数； a ⪯ c a\preceq c a⪯c 表示动作不超出该能力。实现中可把一批请求表示为 trust.shape=[B,S]： B B B 是样本数， S S S 是输入片段数，每个位置记录 trusted 或 untrusted。真正重要的不是这个张量名字，而是来源标签在检索、规划、参数组装、日志和执行阶段都不丢失。

"隔离"也有层级。Spotlighting 用持续的来源标记强化模型对外部文本的区分；Instruction Hierarchy 通过训练让模型优先服从高权限指令；StruQ 将 prompt 与 data 作为结构化查询的两个部分，并配合保留 token、前端过滤和专门训练；CaMeL 更进一步，从可信查询抽取控制流和数据流，并在工具调用处施加 capability 策略。这些路线都比一句"不要听文档里的话"更强，但只有应用侧权限检查能把模型失误限制在可控后果内。

官方论文与代码阅读路线

第一站读 Greshake 等人的论文与 llm-security 仓库。论文先定义"攻击由被检索数据送达"的威胁，仓库的 scenarios/ 展示网页、邮件、代码补全和持久记忆等攻击面。阅读时不要把演示 payload 当成通用成功率；应画出来源、进入上下文的路径、模型可见秘密、可调用工具与最终副作用。

第二站读 Spotlighting 和 OpenAI 的 Instruction Hierarchy。前者的核心是对不可信文本做来源变换，后者显式定义不同权限指令冲突时的优先关系。论文报告：Spotlighting 在其 GPT 系列实验中将攻击成功率从超过 50% 降至低于 2%；这只是特定模型、攻击集和协议下的结果，不能直接写成所有系统的保证。Instruction Hierarchy 同样属于模型行为训练，不应替代应用授权。

第三站读 StruQ 论文第 4 节，再看官方仓库的 struq.py、train.py、test.py 与 run.py。关键不是复制字符串模板，而是理解两件事：分隔符使用攻击者无法直接产生的保留 token，前端还要过滤伪造标记；模型则通过 structured instruction tuning 学会只执行 prompt 部分的指令。普通 <DATA> 标签仍是普通文本，没有专门训练和不可伪造编码时不能等价替代 StruQ。

第四站读 AgentDojo。NeurIPS 2024 论文提供 97 个现实任务和 629 个安全测试案例，官方命令可组合 suite、user task、attack 与 tool_filter defense。复现实验要同时报告 benign utility（无攻击任务完成率）和 attack success，而不是靠一律拒绝获得"安全"。最后读 CaMeL 的 src/camel/、tests/ 与复现命令，重点跟踪控制流提取、值的来源、策略回放及工具调用检查；仓库明确声明它是研究制品、可能含 bug 且未必完全安全，这个警告也应保留在复现报告里。

最小实验：三条管线与四类攻击

code/minimal_isolation_gateway.py 不调用模型。它故意实现一个脆弱解析器：只要混合字符串中出现 ACTION::工具::目标，就执行最后一条动作。六个固定案例包含两个正常任务，以及四类攻击：未授权收件人、伪造闭合分隔符、已授权工具的参数替换、伪造控制 token。正常任务之一明确授权给研究员邮箱发送摘要，用来检查防御是否误伤功能。

plain-concat 直接拼接任务与记录；delimiter-only 加上 <TASK> 和 <DATA>，但执行器仍扫描整串；isolated-gateway 只从可信任务生成动作，并要求动作来源、工具名和目标与 capability 完全一致。不可信记录仍可参与摘要，只是不能铸造动作权限。

本次 CPU smoke test 的输出为：直接拼接和仅分隔符两组攻击成功率均为 1.000，四个攻击案例全部产生未授权副作用；隔离网关为 0.000，同时两项无攻击任务的 benign utility 均为 1.000。隔离组执行了两次合法邮件动作：一次来自正常任务，一次是在参数替换攻击存在时仍坚持发送给用户授权的目标。语法检查与断言均通过。

这些数字是人为构造解析器上的确定性协议测试，不是 LLM、StruQ、AgentDojo 或 CaMeL 的复现分数。它们只证明：若执行器仍从不可信串提取命令，换一层标签没有改变信任关系；若权限只能由可信输入生成，toy 攻击无法直接形成副作用。

评测协议：安全与可用性必须成对报告

攻击成功率定义为 A S R = N u n a u t h o r i z e d / N a t t a c k ASR=N_{unauthorized}/N_{attack} ASR=Nunauthorized/Nattack，其中分子是实际发生未授权副作用的攻击样本数；不能只用模型输出中是否出现某个词代替系统状态。正常任务完成率 U = N c o r r e c t / N b e n i g n U=N_{correct}/N_{benign} U=Ncorrect/Nbenign 用来识别"全部拒绝"的伪防御。还应报告合法工具调用通过率、越权参数拦截率、人工确认率、额外延迟和 token 成本。

基线应逐层增加而非只比较"无防御"和完整系统：系统提示提醒、普通分隔符、内容净化、来源标记、注入分类器、工具过滤、参数级授权、人工确认分别单跑，再做组合消融。这样才能区分模型是否真的忽略了恶意指令，还是攻击虽影响文本输出却被执行层截断。对于随机模型，同一攻击至少重复多次；若只挑一次成功或失败的截图，既不能估计方差，也无法比较防御代价。

数据集至少分四层。第一层是直接冲突和分隔符伪造；第二层是编码、错拼、长上下文与多轮持久化；第三层让攻击和正常业务语义相似，测误报；第四层进入真实代理环境，检查邮件、网盘、银行或代码工具的最终状态。每条样本保存可信任务、原始不可信内容、来源、预期动作集合、真实调用轨迹、最终状态与版本哈希。攻击与防御应在同一任务上配对，随机种子和解码参数固定，多次采样给置信区间。

授权网关必须位于模型之外。对 send_email(to, body)，策略不能只检查工具名，还要检查 to 是否来自用户明确给定的收件人，body 是否允许包含从私有源读取的数据，以及该动作是否需要确认。只读检索、写文件、发送消息和删除资源应拥有不同能力；默认拒绝未知工具、额外参数和跨租户标识。日志要记录策略输入与拒绝原因，但不得把秘密或攻击内容原样扩散到新的上下文。

失败分析：先查边界断在哪里

若 <DATA> 防御仍失败，先看模型或解析器是否把标签当成普通文本，以及攻击者能否在数据中写出同样的闭合标签。若输入过滤看似有效，加入 Unicode、HTML 注释、间接引用和语义改写；关键词召回率高不代表遇到新攻击仍稳健。若独立检测器放行攻击，记住检测器本身也是模型时同样可能被注入，不能授予它执行权限。

若工具名正确但目标被替换，问题通常在参数 provenance：系统只验证了 schema，没有验证值从哪里来。若模型未调用工具却泄露秘密，检查 Markdown 图片、URL、引用和富文本渲染是否形成外带通道。若当前轮安全、下一轮失守，检查记忆写入、摘要缓存与向量库是否把恶意指令持久化。若防御 ASR 很低但 utility 也崩溃，说明可能只是过度拒答；应按风险分级，把人工确认集中在不可逆或跨边界动作。

最重要的反例是"可信任务本身含糊"。用户说"处理所有紧急邮件"并未定义可发送对象、金额或删除范围，系统无法凭空铸造正确 capability。此时应追问或缩小到只读预览，而不是让模型猜权限。作者推断：研究重点应从寻找万能提示词转向证明哪些信息流可达哪些副作用，并用系统状态验证保证。

后续科研问题

一是如何自动从自然语言任务提取最小 capability，同时避免把含糊意图过度授权；二是来源标签经过摘要、重排和多代理通信后怎样保持；三是结构化训练能否对未见语言、模态和长上下文攻击泛化；四是如何构造同时测攻击、自适应防御和正常任务效用的动态基准；五是 taint tracking 与隐私类型系统能否覆盖间接数据外带；六是在人类确认预算固定时，怎样优化风险覆盖而不是简单增加弹窗。

总结

Prompt Injection 的根因不是缺少一句更强的警告，而是指令和数据共享表示后，低信任文本可能进入高权限控制流。可靠复现应把威胁模型落到来源、动作和最终状态：先用结构化输入保留边界，再让模型只提出候选计划，最后由最小权限网关检查工具、参数、数据流与确认要求。本文脚本验证了这个程序化差异，也明确保留真实模型的未知性。隔离不保证模型永不受骗，但能让"受骗"更难直接变成不可逆副作用。

参考资料

检索日期：2026-09-04。以下均为论文、会议页面、研究机构页面、官方代码或安全项目文档；模型行为、在线榜单与仓库接口可能变化，使用时待人工核验。

• Kai Greshake 等，2023，Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection 与官方演示仓库
• Keegan Hines 等，2024，Defending Against Indirect Prompt Injection Attacks With Spotlighting（Microsoft Research）
• Eric Wallace 等，2024，The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions（OpenAI）
• Sizhe Chen 等，2025，StruQ: Defending Against Prompt Injection with Structured Queries（USENIX Security） 与官方实现
• Edoardo Debenedetti 等，2024，AgentDojo（NeurIPS Datasets and Benchmarks） 与官方仓库
• Edoardo Debenedetti 等，2025，Defeating Prompt Injections by Design（CaMeL） 与Google Research 复现仓库
• OWASP，LLM Prompt Injection Prevention Cheat Sheet