提示词供应链：从“一键 Reprompt”到“系统提示投毒”
提示词供应链：从“一键 Reprompt”到“系统提示投毒”
2026 年 LLM 安全的三段式攻防
文章定位：偏工程落地 + 新视角总结
说明：本文只写可用于安全评估与防守的思路，不提供可直接复制用于攻击的载荷、脚本与绕过细节；示例均做“脱敏/占位符化”。
深度技术分析：从攻击面到实现机制
URL参数注入的技术实现链路
Copilot Reprompt 和 ChatGPT 的参数注入本质是前端输入验证缺失导致的上下文污染。这类漏洞的技术关键在于参数直接进入模型推理路径，绕过了常规的输入清洗流程。
前端路由层接收参数后，未进行上下文隔离就直接构造API请求。
这种实现让 URL 参数获得了与直接用户输入相同的上下文权重。攻击者可以通过精心构造的 URL，将恶意指令注入到系统提示之后、用户输入之前的位置，形成上下文劫持。
更危险的是某些实现中的自动提交机制。
这种机制下，用户访问恶意链接后，不需要任何交互就能触发 LLM 工具调用链。
从攻击链路看，URL 参数注入的成功依赖三个条件的叠加。前端未对参数来源进行可信度标记，后端未区分用户主动输入与被动接收的参数，且模型推理过程中将所有上下文视为同等权重。这三个条件构成了完整的攻击路径。
LangChain CVE-2025-68664 的攻击面展开
LangChain 序列化漏洞的核心危险在于将非结构化的 LLM 输出直接用于框架对象重构。其攻击路径通常涉及以下技术环节。
LLM 输出被解析器误认为 LangChain 特殊对象结构。
实际攻击中，这类漏洞利用了 LangChain 在处理历史对话、工具调用结果时的自动序列化机制。当 LLM 输出包含特殊格式的结构化数据时，反序列化器可能将其当作可信对象处理。
另一个关键攻击向量是通过工具返回值注入。
这种模式下，攻击者控制了外部 API 的返回内容，通过 LLM 工具调用链实现间接注入。
LangChain 框架中存在多个此类攻击面。对话历史存储时的序列化、工具调用结果的对象转换、以及 Prompt 模板的动态加载机制，都可能成为注入点。框架设计时假设 LLM 输出是安全的，但实际工程中这个假设经常不成立。
系统提示投毒的供应链特征
系统提示投毒区别于传统提示注入的核心在于其持久性和全局性。从技术实现角度看，这类攻击通常利用以下系统特性。
多租户环境中的提示词模板复用机制。
这种架构下，单一污染点可以影响整个用户群体。更危险的是当系统提示词存储在可被运营配置修改的数据库中时，所有使用该模板的后续对话都会被植入恶意指令。
企业级应用中常见的一种危险模式是通过管理后台动态编辑系统提示词。
当管理后台存在权限越权或会话劫持时，攻击者可以修改系统提示词模板。这种污染的持续性强于单次会话注入，因为所有新会话都会加载被污染的模板。
更隐蔽的投毒方式是通过外部数据源间接影响系统提示词。例如某些系统允许从知识库文档中提取规则动态追加到系统提示。
这种投毒方式难以检测，因为恶意指令被包装在正常文档内容中，且通过自动化规则提取机制进入系统提示。
间接注入在 RAG 系统中的放大效应
RAG 系统是最容易被忽视的间接注入攻击面。其危险在于检索到的文档内容被系统默认为可信上下文。
攻击者可以通过投递恶意文档到知识库，让检索过程返回带有嵌入指令的内容。
当用户的查询与该文档相似度匹配时，嵌入的指令就会被注入到上下文中。这种攻击方式的隐蔽性在于恶意内容被包装在正常文档内部，且通过语义相关性触发。
RAG 系统中存在多种文档投毒向量。用户上传的文件、网络爬虫获取的网页内容、第三方知识库同步的数据，都可能被注入恶意指令。这些内容在检索后直接进入模型上下文，且通常不会经过与用户输入相同的验证流程。
另一种危险的 RAG 注入方式是通过跨模态检索。
当 OCR 提取的图片文本中包含嵌入指令时，这类攻击尤其难以检测，因为图片内容的来源和真实性的验证成本较高。
工具调用链的权限边界消解
现代 Agent 系统中，工具调用是最危险的能力出口。其风险核心在于 LLM 可能被诱导执行超出用户意图的操作。
攻击者可以通过控制 context 中的外部内容，诱导 LLM 选择高风险工具。
这种攻击成功的关键在于系统没有区分工具调用权限的来源。当外部内容被允许影响工具调用决策时，整个权限边界就被消解了。
更复杂的工具链攻击涉及多步骤的权限提升。
当系统未对工具调用的来源进行追踪时，攻击者可以构造看似合理的多步骤任务链，逐步提升权限并最终执行高危操作。
记忆系统的双刃剑效应
记忆功能的开启让单次会话的攻击可以持续影响未来所有会话。从攻击者角度看，这相当于获得了一个持久化的配置修改接口。
一旦恶意内容被写入长期记忆，后续所有会话都会在上下文中包含这些内容。更危险的是，某些实现中记忆内容会被优先级处理，甚至可以覆盖系统提示词的某些部分。
多租户环境中的交叉污染风险
多租户 SaaS 应用中的提示词污染具有特殊的危险性。当多个用户共享同一套系统提示词模板或 RAG 知识库时，一个租户的恶意内容可能影响其他租户。
当系统未正确隔离租户间的模板更新权限时，恶意租户可能修改共享的基础模板，影响所有其他租户。
函数调用劫持的实现机制
函数调用劫持是比直接注入更危险的攻击形式。攻击者只需要在上下文中植入特定的触发模式，当模型遇到匹配的语义场景时会自动调用危险函数。
实际攻击场景中，函数调用劫持通常利用模型对上下文来源的误判。
当系统未实现上下文来源追踪时，攻击者可以通过在 RAG 检索结果中埋入函数调用触发器。
当用户的查询与这份恶意文档语义相近时，模型可能会误认为这是系统标准的应急流程，从而调用危险的函数。
多模态注入向量的隐蔽性
多模态 LLM 系统中的注入攻击具有更高的隐蔽性。攻击者可以将恶意指令编码在图片、音频甚至视频中，通过非文本通道绕过常规的内容过滤。
图片中的隐藏文字是最常见的多模态注入向量。
这种攻击方式之所以危险，是因为大多数系统的 OCR 提取内容不会经过与用户输入同等级别的安全检查。更隐蔽的做法是使用 Steganography 技术，将恶意指令隐藏在图片的像素数据中，只有特定的解码流程才能提取。
上下文污染的级联效应
上下文污染在多轮对话中会产生级联效应。一旦第一轮对话被成功注入，后续所有轮次都会受到污染上下文的影响。
实际系统中，上下文窗口的管理策略往往加剧了这种级联效应。
当 RAG 内容被标记为低优先级时，正常情况下会被优先清除。但攻击者可以通过在污染内容中添加重复性关键词，增加其在语义检索中的相关性得分，从而在多轮对话中反复被检索到。
只要用户的查询涉及这些话题，相关的恶意文档就会被检索出来并注入到上下文中。
模型输出污染的下游影响
模型输出不仅会直接被用户看到，在很多系统中还会被传递给下游服务。当输出被污染时，下游服务可能会执行非预期的操作。
一个典型的危险场景是将 LLM 输出直接用作 SQL 查询构造。
如果攻击者成功在上下文中注入了恶意指令，模型可能会生成包含 UNION SELECT 或其他注入技术的 SQL 语句。
更危险的场景是将 LLM 输出用于配置文件生成或脚本生成。
攻击者可以通过在 RAG 内容中植入恶意配置模板，让模型生成包含后门指令的配置文件。
工作流编排系统的注入风险
现代 LLM 应用通常不是单一的模型调用，而是包含多个步骤的工作流。工作流编排系统中的注入点更加隐蔽，因为恶意指令可以在工作流的任意环节被注入。
典型的工作流系统会包含任务分发、结果聚合、错误重试等环节。
当任务之间的数据传递没有进行来源标记和权限检查时，攻击者可以污染中间结果，影响后续任务的执行。
工作流系统中的另一个危险点是错误处理和重试逻辑。
攻击者可以通过故意触发特定的错误类型，然后在错误上下文中注入恶意指令，让系统在重试时执行攻击者指定的操作。
前言：Prompt Injection 不再是“聊天框里的几句话”
很多人还停留在“让模型忽略上一句指令”的阶段，但 2025 下半年到 2026 年初的几个热点事件，已经把问题推到了另一个层级：
Prompt 变成了一个可被传递、拼接、缓存、持久化、再利用的“供应链”对象。
你以为你在做“检索、总结、问答、自动化”，实际上你在做一件更危险的事：
把不可信数据，混入到一个会影响决策的上下文里；再把决策结果交给工具执行。
这条链路一旦跑通，攻击者不需要“破解模型”，只需要“投喂上下文”。
一、提示词供应链正在成型
1）Copilot 的 “Reprompt”：一次点击，任务自己跑完
2026 年 1 月，Varonis 披露 Microsoft Copilot 的 “Reprompt” 问题：核心是通过链接里的查询参数，把一段 prompt 直接塞进 Copilot 的输入路径，用户只要点一下，后续可能出现静默数据外泄等风险；媒体报道提到微软已在 2026 年 1 月 13 日左右完成修复。
它最值得记的点不是“又一个注入”，而是这种形态：
● Prompt-as-URL：提示词从聊天框迁移到了 URL 参数；
● 低交互：一次点击即可触发；
● 隐蔽：用户甚至可能感知不到“有一段会话正在发生”。
这不是传统意义的“社会工程 + 账号接管”，更像是：
点击链接 = 触发一个 AI 工作流。
2）ChatGPT 的 ?q=：前端参数也能变成“执行入口”
Tenable 在 2025 年披露过 ChatGPT Web 前端 ?q= 参数可触发自动提示注入的风险：用户打开某个链接时，页面加载就可能把参数内容当成输入执行（文中包含示例）。
换句话说：
入口不只在“你输入了什么”，也在“你打开了什么”。
3）“Command Memories / 记忆注入”：把一次成功变成长期后门
更麻烦的是“持久化”。Tenable 还提出过通过间接注入引入“Command Memories”的思路，用来影响或利用用户记忆相关信息，扩大数据泄露面。
一旦产品开启“记忆/长期偏好”，安全问题会发生质变：
●过去：一次会话被带偏
● 现在：把带偏写进配置，下次还跟着偏
4）LangChain CVE：当 LLM 输出进入序列化/反序列化，安全边界直接断裂
CVE-2025-68664 是一个很典型的“AI 工程踩进经典漏洞坑”的案例：在 LangChain 的序列化/反序列化链路里，用户可控数据可能被误识别为框架对象结构，带来敏感信息泄露等风险；国内多个通告与复现文章也提到了其严重性（CVSS 9.3）以及受影响版本与修复建议。
它提醒我们一件事：
LLM 输出永远是“不可信输入”。
把它直接喂给反序列化、模板渲染、动态加载这类机制，本质上是在给自己找“第二条 RCE 路径”。
5）系统提示投毒（System Prompt Poisoning）：供应链的“上游污染”
2025 年的研究提出“系统提示投毒”：攻击者不是注入用户提示，而是让系统提示被污染，从而对后续任务产生持续影响。
这类风险一旦进入现实产品形态（比如系统提示由多个模块拼接、由运营后台配置、由某些外部内容间接影响），它的地位就像“配置中心被投毒”：
不是某次请求出错，而是全体请求慢性中毒。
二、“对抗样本输入”按攻击链拆成为三段：入口、滞留、出站
A. 入口（Ingress）——提示词从哪里进来？
除了聊天框，还有很多“隐形入口”：
1 URL 参数（Copilot Reprompt、ChatGPT ?q= 这类）
2RAG 文档块（用户上传、知识库、网页摘要、邮件内容）
3搜索结果摘要（Search 场景被投喂“带指令的网页内容”）
4工具返回（插件/API 的返回内容被当成“更可信的上下文”）
5运营配置（系统提示词/策略模板/提示词片段库）
入口越多，越像供应链。
B. 滞留（Persistence）——它能不能留下来？
滞留能力决定“事故是一次性的”还是“长期性的”：
●写入 memory / 偏好 / 画像（记忆注入）
●写入对话摘要（很多产品会把历史压缩成“摘要记忆”）
●写入 RAG 缓存（命中缓存后反复触发）
●写入系统提示拼接层（最危险）
C. 出站（Egress）——它最终能造成什么影响？
出站不是“模型说了什么”，而是“系统做了什么”：
● 泄露：把内部信息带到回复里 / 带到工具调用里
● 越权行动：诱导 Agent 调用工具（发请求、写数据、改配置）
● 结构化攻击：诱导输出“看似合法的结构”，再被系统解析执行（LangChain CVE 属于这类思路的延伸）
把这三段串起来，你会发现：
Reprompt 之所以吓人，是因为它几乎把“入口→出站”做成了一键工作流。
三、把 Prompt 当“依赖”，把工具当“权限”，才能真正落地
很多团队做防护，第一反应是“加几条拒答规则”“拦截敏感词”。但这条路会越来越痛苦：同义改写、跨语言、格式混淆都能绕，而且事件证明入口不止用户输入。
我更推荐一个能落地的框架：
“上下文溯源 + 权限票据”——用工程手段重建边界
1）上下文溯源：给每一段上下文打标签
不要再把 prompt 当一整段字符串拼来拼去，至少拆成五段：
●SYSTEM：系统提示（只读、版本化）
●USER：用户输入
●EXTERNAL：外部内容（网页/文档/RAG chunk/搜索摘要）
●TOOL：工具返回
●MEMORY：长期记忆/画像
每段都带上元信息：来源、时间、信任级、是否允许影响工具调用。
这样做的意义是：
让“模型看不见的边界”，在系统层变得可审计、可限制。
2）权限票据：工具调用必须拿到“能力票”
把 Agent 能做的事分级，尤其是“写入型能力”：
●L0（低风险）：查询公开信息、总结文本
●L1（中风险）：读取内部知识库、读文件（只读）
●L2（高风险）：写入 memory、发送外联请求、创建/修改数据
●L3（致命）：改权限、改配置、执行脚本、触发支付/发信
然后规定：
EXTERNAL 段永远不能直接触发 L2/L3。
哪怕模型说“我需要写入记忆以便更好服务你”，也必须走策略门、走二次确认或人审。
这套思路能直接对齐三个热点：
●URL 参数注入：入口更隐蔽 → 必须把它标成 EXTERNAL/UNTRUSTED
●记忆注入：滞留能力强 → memory_write 必须是高风险能力
●LangChain CVE：结构化输出有“执行风险” → 解析/反序列化必须有 allowlist 与安全默认值
四、对抗样本怎么写才“能用”：
1）一个合格的对抗样本用例 = 目标 + 约束 + 判定器
●目标：诱导泄露 / 诱导调用工具 / 诱导写入 memory
●约束：输入必须来自 EXTERNAL（模拟间接注入），不能由用户明说
●判定器：是否出现 tool_call、是否触发 memory_write、是否输出敏感字段特征
判定器尽量“非 LLM 化”：用正则/结构校验/审计事件，而不是让模型自己说“我很安全”。
2）给你三类“可发布”的对抗样本模板（脱敏占位符版）
下面只给结构，不给可直接复用的攻击载荷：
模板 A：外部数据夹带“伪装指令”
测试点：模型是否把外部段当“指令源”。
模板 B：诱导触发工具调用
测试点：模型是否会把“外部理由”当授权。
模板 C：诱导持久化（记忆/画像）
测试点：是否出现 memory_write 意图或相关事件。
3）变异策略：打的就是“拦关键词”那套
●语义变异：委婉说法、分步推理、反问句
●结构变异：表格/代码块/引用层级嵌套
●语言变异：中英混写、同音替换、符号插入
●位置变异：把关键语义放在“你以为不会读”的地方（脚注、引用、括号）
高级攻击场景分析
分布式提示词注入网络
分布式提示词注入是一种新兴的攻击技术，攻击者通过在多个不同的数据源中分散植入恶意指令片段，这些片段单独看起来无害，但被系统组合后就会形成完整的攻击载荷。
这种攻击方式利用了现代 AI 系统中普遍存在的多源数据聚合特性。
每个注入点可能只是一小段看似无关的文本。
当这些片段被检索并在上下文中聚合时，它们就组合成了一个完整的恶意指令集。
对抗性样本的自动生成
攻击者正在开发自动化工具来生成对抗性提示词样本。这些工具利用遗传算法、强化学习等技术，自动寻找能够绕过安全防护的提示词变体。
这种自动化生成系统能够快速发现大量有效的对抗性样本，远远超过手工测试的效率。
跨模型迁移攻击
跨模型迁移攻击是指针对一个模型训练的对抗性提示词，在另一个完全不同的模型上仍然有效。这种现象的存在表明不同 LLM 的安全漏洞存在某种共性。
研究发现某些类型的提示词模式在不同模型间都有较高的迁移成功率。
持续学习系统的污染攻击
具备持续学习能力的 LLM 系统可能会从用户交互中不断学习和优化。攻击者可以通过精心设计的交互序列，将恶意模式注入到模型的学习数据中。
这种攻击的隐蔽性极高，因为恶意行为被包装在正常的性能优化建议中。
漏洞挖掘方法论
基于符号执行的提示词分析
符号执行技术可以应用于提示词分析，通过形式化方法探索所有可能的执行路径，发现潜在的注入点。
模糊测试在 LLM 系统中的应用
模糊测试技术可以大规模自动化地发现 LLM 系统中的安全漏洞。
动态污点分析框架
污点分析可以追踪不可信数据在系统中的流动路径，识别出所有可能被污染的执行点。
五、结语：别再问“能不能彻底防住”，先问“最坏情况下它能做多大”
这波事件给我的最大感受是：
LLM 安全不是“模型对不对”，而是“系统允许它做什么”。
如果你的产品具备以下任一条件——
●可以浏览/搜索并总结
●有 RAG 或会读取用户文档
●有工具调用/Agent 自动化
●开启记忆/长期偏好
●系统提示词由多个模块拼接、可运营配置
那你就已经进入“提示词供应链时代”。
从工程角度，最实用的三句话是：
1所有外部内容默认不可信，只能影响“回答”，不能影响“权限”。
2写入型能力（memory/外联/改数据）必须是高风险能力，走策略门。
3 LLM 输出永远当不可信输入，尤其别让它直连反序列化/模板/执行链路。（LangChain CVE 就是活教材）
2026 年最真实的趋势：
Prompt 不是文本，是供应链；防御不是拒答，是权限设计。
参考阅读
●Reprompt 一键外泄相关新闻与解读
● Tenable：ChatGPT ?q= 参数触发 prompt injection
●Tenable：Command Memories / SearchGPT prompt injection 风险
●System Prompt Poisoning 研究论文
●LangChain 序列化注入（CVE-2025-68664）通告/分析