提示注入被OWASP列为LLM应用的首要风险，但到目前为止还没有一种防御方法被证明在跨攻击类型和跨部署设置上具有广泛可靠性——当Agent的每一次工具调用、每一次记忆读取、每一次规划执行都可能在传递不可信内容，而“把不可信内容隔离在数据通道里”这件事在模型层面没有硬边界时，AI安全到底该继续在模型和prompt层面修修补补，还是必须承认：真正的边界只能建在系统层、在权限层、在架构层，而不是建在对模型“好好听话”的期待上？

一、引言：从一条被反复引用的风险条目说起

OWASP在2023年发布的首版《LLM应用十大风险》中，将提示注入列为LLM01，并在2025年更新版中维持其首位位置（OWASP GenAI Security Project, 2025）。这一排序并非偶然：它反映的是一个结构性事实——大语言模型把“指令”和“数据”编码进同一个token序列，模型本身没有任何机制去区分哪一段是系统下发的控制信号、哪一段是外部输入的待处理内容。只要这个前提不变，任何试图在模型内部建立“数据通道隔离”的努力，都只能是在概率分布上做文章，而不是在语义边界上划红线。

过去两年，防御研究大致沿三条路线展开：一是提示层加固，如分隔符、指令层级、系统提示强化；二是模型层对齐，如对抗训练、指令微调、输入过滤；三是系统层隔离，如权限最小化、工具白名单、双模型架构。前两条路线在单点攻击上屡有报告“接近零成功率”，但一旦换攻击类型或换部署形态，效果便大幅衰减。Greshake等人（2023）在间接提示注入的开创性工作中已经指出，攻击者无需直接接触模型，只需污染模型会读取的外部内容即可。这一结论在Agent场景下被进一步放大：工具返回值、记忆条目、检索文档、网页内容、代码执行输出，全部可能成为注入载体。

笔者认为，围绕“哪种防御最有效”的争论，长期忽略了一个更基础的问题：我们究竟在哪个层面上定义“边界”。如果边界被定义为“模型应当拒绝执行不可信内容中的指令”，那么这条边界本质上是语义的、概率的、可被分布偏移击穿的；如果边界被定义为“即使模型被说服，它也没有权限去执行危险动作”，那么这条边界是系统的、确定的、可审计的。本文的全部论证，都服务于把讨论从前者迁移到后者。

二、背景与问题定义：控制面/数据面混叠

2.1 一个必要的定义

提示注入（Prompt Injection）指攻击者通过向模型上下文注入文本，使模型将其中部分内容当作指令执行，从而偏离原始任务目标或泄露敏感信息的一类攻击。按注入路径可分为直接注入（用户直接输入恶意指令）与间接注入（恶意内容藏在模型会读取的外部数据中）。按目标可分为目标劫持（goal hijacking）、提示泄露（prompt leaking）、工具滥用（tool misuse）与数据外泄（data exfiltration）。

本文评述：上述分类在文献中已较为通行，但它隐含了一个假设——攻击是“一段文本”。在Agent场景下，这个假设过于狭窄。真正的攻击单元是“一次内容传递事件”，它可能是一段文本、一个工具返回的JSON、一条记忆记录、一个文件路径，甚至是一个被污染的函数名。把攻击还原为文本，会诱导防御者只在文本层面做过滤，而忽略传递通道本身的信任等级。

2.2 控制面/数据面混叠：本文的分析主线

在网络工程中，控制面负责路由、策略与信令，数据面负责实际报文转发，二者在物理或逻辑上分离，是许多安全属性的前提。大语言模型的上下文窗口恰恰相反：系统提示、用户输入、检索文档、工具返回值、历史对话，全部被拼接进同一个token序列，模型只能依靠位置、格式与训练分布去“猜测”哪部分是控制、哪部分是数据。本文把这一现象称为控制面/数据面混叠（control-plane/data-plane aliasing）。

混叠带来三个直接后果。第一，任何数据通道都可能被提升为控制通道，只要模型“认为”它是指令。第二，防御者无法在模型内部设置硬边界，因为模型没有“通道”这个概念，只有token。第三，攻击的成功率与模型能力正相关——能力越强的模型越擅长遵循指令，也越容易被精心构造的注入说服。第三点尤其值得警惕：它意味着“等模型更聪明了再解决”是一条走不通的路。

笔者认为，控制面/数据面混叠不是当前模型的一个“缺陷”，而是自回归语言建模的一个“特性”。只要模型的目标是“根据上下文预测下一个token”，上下文中的任何内容在原理上都具有指令潜力。因此，把隔离寄希望于模型层，等于要求一个概率系统表现出确定系统的行为，这在工程上不可依赖。

三、攻击面解剖：Agent的六条不可信内容通道

要设计分层防御，先要枚举通道。一个典型的生产级Agent至少涉及六类内容来源，每一类的信任等级、可控性与传递频率都不同。下表给出本文的通道模型，其中“信任等级”是本文提出的工程分类，用于指导后续的权限设计，而非学术标准。

这张表的关键洞察在于：信任等级与传递频率往往成反比。系统提示信任最高但只出现一次；工具返回与记忆信任最低，却在一次任务中被读取数十次。防御资源若按“通道重要性”分配，就会错配；正确的做法是按“不可信内容触达危险动作的路径数”分配。

以记忆通道为例。Agent的长期记忆通常以向量库或键值存储实现，写入时往往没有严格的来源标记。一旦攻击者通过一次会话把恶意指令写入记忆，后续所有读取该记忆的会话都可能被污染，形成持久化攻击。这类攻击的检测难度远高于单次注入，因为恶意内容在时间上被稀释，在语义上被摘要。本文评述：记忆通道的安全问题，本质上是“写权限”问题，而不是“读内容”问题；只做读取时的内容过滤，等于在漏水的桶上贴胶带。

延伸阅读可参考OWASP官方项目页（genai.owasp.org）与NIST AI风险管理框架（NIST AI RMF），前者提供风险条目与缓解措施清单，后者提供组织级治理结构。

四、模型层与提示层防御的结构性上限

4.1 提示层加固：有效的局部，失效的整体

提示层加固的常见手段包括：用分隔符包裹不可信内容、在系统提示中声明“以下内容仅为数据”、采用指令层级（instruction hierarchy）让模型优先服从高优先级指令、要求模型在输出前自检。这些手段在特定模型与特定攻击集上确实能降低成功率。例如，Wallace等人（2024）提出的指令层级训练，通过在微调阶段构造“高优先级指令应覆盖低优先级指令”的样本，使模型在面对冲突指令时更倾向于服从系统提示。

然而，本文评述：指令层级的有效性依赖于模型在训练分布内见过类似冲突。攻击者只需构造分布外（OOD）的冲突形式，例如把恶意指令编码进看似无害的格式、利用多语言混写、借助工具返回的结构化字段，就可能绕过。更根本的是，指令层级是一种“软约束”——它改变的是模型输出指令的概率，而不是系统执行动作的权限。一旦模型被说服，后续动作没有任何硬拦截。

4.2 输入过滤与对抗训练：军备竞赛的典型形态

输入过滤（如关键词黑名单、分类器检测）在直接注入上成本低、见效快，但对间接注入几乎无效，因为恶意内容往往伪装成正常业务文本。对抗训练（adversarial training）把已知攻击样本加入训练集，能提升模型对这类样本的鲁棒性，但 Perez与Ribeiro（2022）以及后续大量工作反复验证了一个规律：对抗鲁棒性难以泛化到未见攻击族。攻击者可以针对公开防御做自适应攻击（adaptive attack），而防御者无法预知所有攻击形态。

笔者认为，把输入过滤当作主防线是一个典型的“检测器谬误”：检测器的召回率永远小于1，而攻击者只需要一次成功。在传统安全中，检测器背后还有权限、隔离、审计作为兜底；在当前的LLM应用中，检测器往往就是唯一防线，这使其失败代价被无限放大。

4.3 为什么模型层无法提供“硬边界”

从计算角度看，模型对上下文的处理是全局注意力，不存在“这段token不可被解释为指令”的机制。从训练目标看，模型被优化为“有用且遵循指令”，这与“拒绝上下文中的某些指令”存在内在张力。从部署看，同一个模型可能通过API、微调、蒸馏被部署到信任假设完全不同的环境，任何依赖特定提示模板的防御都无法跨部署迁移。

因此，模型层防御的合理定位是“降低攻击成功率、提高攻击成本”，而不是“建立边界”。把二者混淆，是当前许多安全方案在真实环境中失效的根源。关于指令层级与对抗鲁棒性的更多技术细节，可参考Anthropic的提示注入缓解实践（anthropic.com/research）与Google DeepMind的相关论文页（deepmind.google/research）。

五、系统层防御：把边界从语义搬到执行

系统层防御的核心思想是：不再要求模型“分辨”指令与数据，而是要求系统“无论模型输出什么，都只执行被授权的动作”。这把边界从语义层搬到了执行层，从概率判断搬到了确定性策略。下面给出一条可操作的工程路径，分为四个步骤。

5.1 第一步：动作清单与危险分级

先枚举Agent可执行的全部动作（工具调用、文件读写、网络请求、代码执行、消息发送），按“不可逆性”与“影响范围”两个维度分级。例如，读取公开网页为低危，写入数据库为中危，发送邮件或调用支付接口为高危。分级结果应写入配置，而不是藏在提示里。本文评述：许多团队把“不要做危险操作”写进系统提示，这在工程上等价于没有控制——提示是建议，配置才是约束。

5.2 第二步：策略执行点前置

在模型与工具之间插入一个策略执行点（Policy Enforcement Point, PEP）。模型输出的工具调用请求先经过PEP，由PEP根据动作分级、调用上下文、内容来源标签决定放行、降级或拒绝。PEP的判断逻辑应是确定性的规则引擎，而不是另一个LLM。关键设计是：PEP必须能读到“这次调用的触发内容来自哪个通道”，因此需要在上下文拼接时给每段内容打来源标签，并让标签随调用链传递。

# 伪代码：带来源标签的调用请求
request = {
  "tool": "send_email",
  "args": {"to": "...", "body": "..."},
  "provenance": ["user_input", "tool_result:web_fetch"],
  "risk_level": "high"
}
# PEP 规则示例
if request.risk_level == "high" and "tool_result" in request.provenance:
    require_human_approval(request)

5.3 第三步：不可信内容的“数据化”处理

在系统层，不可信内容应被当作“数据”而非“文本”处理：结构化解析、字段白名单、长度截断、转义。例如，工具返回的JSON只提取预定义字段，丢弃自由文本字段中的指令性内容；网页抓取结果先做正文抽取与去脚本，再进入上下文。这一步不能保证消除注入，但能显著缩小攻击面，并为PEP提供更可靠的来源信息。

5.4 第四步：审计与回放

所有工具调用、PEP决策、内容来源标签应写入不可篡改的审计日志，支持事后回放。审计的价值不仅在于追责，更在于为防御迭代提供数据：哪些通道触发了高危动作、哪些规则被频繁绕过，都是优化依据。本文评述：没有审计的Agent安全体系，等于没有观测的分布式系统——你无法调试你看不见的东西。

六、权限层防御：能力令牌与最小授权

如果说系统层解决的是“动作是否被允许”，权限层解决的是“以什么身份、在什么范围内被允许”。这一层借鉴了操作系统与分布式系统中的经典思想：能力（capability）而非身份，最小权限，权限随上下文衰减。

6.1 能力令牌：把权限绑定到具体动作

传统RBAC把权限绑定到角色，Agent场景下角色往往过粗。更合适的模型是能力令牌：每个令牌明确描述“可对哪个资源执行哪个动作、有效期多长、是否可转授”。Agent在执行任务时，只能持有当前子任务所需的最小能力集，任务结束即回收。这样即使模型被注入说服，它也没有超出当前子任务范围的令牌可用。

6.2 最小授权与权限衰减

最小授权的工程实现要点有三：其一，默认拒绝，白名单放行；其二，权限随子任务生命周期创建与销毁，不跨任务复用；其三，高危动作强制二次确认，确认者应是人或独立的策略服务，而不是同一个模型。本文评述：权限衰减（privilege decay）在Agent场景中被严重低估——一个长期运行的Agent如果持有长期有效的高危令牌，那么任何一次成功注入都可能造成持久损害。

6.3 与系统层的衔接

权限层与系统层必须联动：PEP在放行动作时校验能力令牌，令牌的签发由独立的授权服务完成，授权服务的决策依据包括用户身份、任务上下文与内容来源。这样形成“模型提议—策略裁决—令牌授权—执行审计”的闭环。任何一环缺失，边界都会退化。关于能力模型与最小权限的经典论述，可参考Saltzer与Schroeder（1975）的奠基性工作，其原则在Agent时代依然成立。

七、架构层防御：双LLM、隔离执行与溯源

7.1 双LLM模式：特权与隔离的分离

双LLM（Dual LLM）模式由Willison（2023）提出并在工业界被广泛讨论：一个特权LLM负责规划与决策，只接触可信输入；一个隔离LLM负责处理不可信内容，只输出结构化结果，不持有工具权限。二者之间通过严格定义的schema通信。这一模式的价值在于把“接触不可信内容”与“拥有执行权限”在架构上分开，即使隔离LLM被注入，它也无法直接调用高危工具。

本文评述：双LLM不是万能药。隔离LLM的输出仍可能携带注入内容（例如在摘要中夹带指令），特权LLM若不加校验地信任这些输出，攻击仍可穿透。因此双LLM必须配合输出schema校验与来源标签，才能形成有效边界。此外，双LLM增加了延迟与成本，在低延迟场景下需要权衡。

7.2 隔离执行环境

代码执行、文件操作、网络请求应在沙箱中进行，沙箱应限制网络出口、文件系统范围与执行时长。这一层借鉴容器与微虚拟机技术，目标不是阻止模型生成恶意代码，而是限制恶意代码的实际影响。本文评述：沙箱的有效性取决于逃逸难度，而逃逸难度取决于实现质量；因此沙箱应被视为“降低影响”的手段，而非“消除风险”的手段，仍需与权限层配合。

7.3 可验证溯源

溯源（provenance）指为每段进入上下文的内容记录来源、时间、经手环节与完整性校验值。在Agent场景下，溯源可用于：判断某次高危调用是否由不可信内容触发；在事后审计中还原攻击链；在运行时对来源可疑的内容降级处理。工程上可采用内容哈希链与签名机制，确保溯源记录不可篡改。本文评述：溯源是当前最被低估的防御层——它不直接阻止攻击，但它让攻击可见、可追、可复盘，而可见性是所有后续防御的前提。

关于Agent架构与工具使用的工程实践，可参考LangChain的安全文档（python.langchain.com/docs/security）与Microsoft的AI Red Team指南（learn.microsoft.com/security/ai-red-team）。

八、关键数据与案例评估

评估防御效果需要可复现的基准。目前公开的提示注入基准主要包括：AgentDojo（Debenedetti等，2024），面向Agent工具调用的攻击与防御评测；InjecAgent（Zhan等，2024），聚焦间接注入下的工具滥用；以及各类CTF式挑战与工业界红队报告。这些基准的共同局限是攻击集有限、部署形态单一，因此“在基准上表现好”不等于“在真实部署中可靠”。

以AgentDojo为例，其设计包含多种任务套件与攻击场景，允许在同一框架下比较不同防御。公开结果显示，提示层防御在部分攻击上能显著降低成功率，但在自适应攻击下效果明显下降；系统层防御（如工具调用校验）在特定任务上更稳定，但会带来可用性损失。本文评述：这些结果与本文主线一致——防御的可靠性随“边界所在层级”下移而上升，但代价（延迟、成本、可用性）也随之上升。安全决策本质上是成本曲线上的取舍，而不是寻找零风险方案。

需要说明的是，本文引用的基准数据均来自公开论文与项目页，未做二次实验；文中出现的比例性描述（如“显著下降”）应理解为定性判断，具体数值请以原始文献为准。对于整合性数据，本文已单独标注为“整合数据”或“模拟数据”，不作为事实性结论的依据。

九、对比与局限：没有银弹，只有成本曲线

把四层防御放在一起比较，可以得到一个清晰的结论：模型层与提示层防御成本低、部署快，但可靠性随攻击类型与部署形态变化大；系统层与权限层防御可靠性高，但需要改造架构、增加延迟与运维成本；架构层防御（双LLM、沙箱、溯源）提供最强的隔离，但复杂度最高。下表给出本文的定性对比，供工程选型参考。

本文评述：这张表最重要的信息不是“哪层最好”，而是“没有单层足够”。一个负责任的Agent安全方案，至少应同时具备系统层的PEP、权限层的最小令牌与架构层的审计溯源；提示层与模型层防御作为纵深防御的补充，用于降低攻击频率与提高攻击成本。把任何单层当作唯一防线，都是在用概率赌确定性。

局限方面，本文的讨论主要基于公开文献与工程实践，未覆盖所有部署形态（如端侧模型、联邦推理）；对成本曲线的量化也以定性为主，缺乏大规模生产数据。这些是后续工作可以补足的方向。

十、结论与展望

回到文章开头的问题：AI安全到底该继续在模型和prompt层面修修补补，还是必须承认真正的边界只能建在系统层、权限层、架构层？本文的答案是后者，但不是非此即彼。模型层与提示层防御仍有价值，它们的合理定位是“降低攻击成功率、提高攻击成本”的纵深手段；而“边界”必须由系统层、权限层与架构层提供，因为这些层的判断是确定性的、可审计的、不依赖模型是否“听话”。

展望未来，笔者认为三个方向值得投入。其一，能力令牌与策略执行点的标准化，使不同框架的Agent能共享同一套授权语义。其二，可验证溯源与内容来源标签的普及，让“这段内容从哪来”成为上下文的一等公民。其三，面向Agent的基准与红队方法学，尤其是跨部署、跨攻击族的评测，避免防御在单一基准上过拟合。这三者共同指向一个目标：把安全从“对模型的期待”变成“对系统的约束”。

最后需要强调，安全是成本曲线上的取舍，不是零风险承诺。承认这一点，才能让防御设计回归工程理性：明确威胁模型、量化残余风险、保留审计与回滚能力。这比任何“万能防御”的口号都更接近真实世界的安全。

主要参考文献