论文

相同字节,不同权威:聊天模板提示注入中的保留 token 表示

相同字节,不同权威:聊天模板提示注入中的保留 token 表示

Prompt injection 针对 LLM agent 的攻击,在注入指令被包进模型自身的 chat template 时显著增强。伪造的模板标记如 <|imstart| 可以以单个 reserved control token 或一串普通 subword token 到达模型,两者解码出的文本完全相同;而 tokenization 在服务端运行,因此由防御方而非攻击方决定模型收到哪一种。 作者借此衡量注入指令的「权威性」有多少来自 reserved token 的学得表示。把伪造标记编码为 subword(文本固定,并控制额外 token 数带来的干扰),在 InjecAgent 基准上使四个 open-weight 家族中三个的攻击成功率下降 39 至 66 个百分点,该差距在 AgentDojo 的多轮 agent 任务中同样成立。Qwen3-8B 上差距仅 8 点,因为缺少 reserved id 时模型仍能靠推理从文本识别出伪造轮次;抑制 reasoning block 后差距扩大到 50。 机制层面,权威性寄居于标记位置上的单个学得向量:标记的 subword 向量均值无法复现它,最近普通 token 的向量即可在 Llama-3.1 上恢复攻击,而搜索非 reserved 标记的自适应攻击者能在四个家族中的三个找到此类 embedding 邻居。在所有 base 与 instruction-tuned 配对中,instruction tuning 都强化了模型对 reserved marker 的偏好。 标准缓解手段——把 special token 编码为普通 subword 的 tokenizer 选项——只对配置声明为 special 的 token 生效。因此 67 个 tokenizer 配置中的 33 个(覆盖 Hugging Face 下载量前 400 的聊天模型中的 255 个)里,agent 用以读取不可信工具输出的工具协议 token 原封不动,该通道上的差距依然存在。

论文精读

TL;DR 注入指令若以 chat template 保留 token 形式编码,LLM 代理更易遵循;本文量化了保留 token 学到的表示本身带来的权威性,发现仅靠文本不够,且现有 tokenizer 缓解方案常失效。

问题

问题背景

LLM Agent 依赖聊天模板(chat template)解析多轮对话与工具调用,模板中的保留 token(如 <|im_start|>)作为控制信号分隔角色与内容。攻击者可注入伪造的模板标记,使模型误认为后续内容为系统指令,从而劫持 Agent 行为。

现有方法局限

现有防御主要分为三类:基于文本的指令/数据分离(如提示词加固、输出过滤)、tokenizer 层的特殊 token 重编码为普通子词、以及对抗训练。但前两者忽略了一个关键事实:保留 token 的向量表示本身承载了“权威”。同一段字节序列,以保留 token 形式编码与以普通子词序列编码,模型响应差异巨大。防御者通常在文本层面将伪造标记重编码为子词,但只对配置中声明为 special 的 token 生效。论文统计 67 个不同 tokenizer 配置中,33 个配置下的工具协议 token(如 <tool_call>)未被声明为 special,导致覆盖缺口。此前有研究因未控制额外 token 数量或未分离推理过程,得出重编码无效的结论,也是方法局限之一。

为什么这个问题难/重要

技术挑战在于:模型在指令调优阶段将单个保留 token 的嵌入向量学习为强控制信号,其效果无法由子词向量的均值或最近普通 token 替代。攻击者可通过改变 tokenization 路径(强制保留 token 或拆分为子词)绕过文本检测,而最终字节完全相同,传统签名检测失效。业界关注度源于 Agent 生产环境的爆发:工具调用、多轮交互、代码执行等场景普遍使用聊天模板,提示注入已成为现实威胁。

行业类比

这类似于 Web 安全中的解析器差异攻击,即同一段 URL 编码在不同组件(WAF、后端、浏览器)中解析结果不同,攻击者利用解析路径差异绕过防护;此处则是同一字节串在模型 tokenizer 与嵌入空间中的不同表示路径,导致权限差异。

核心洞察

  • 同一字节串因 tokenization 不同而承载不同 authority:伪造 chat template 标记如 `<|im_start|>` 作为单个 reserved token 输入时,注入成功率显著高于拆成普通 subword 序列(InjecAgent 上差距达 39–66 pp)。这个角度把 prompt injection 从文本语义问题转向 tokenizer 与 embedding 层问题,区别于只看字符串内容的防御,解释了为何文本过滤难以消除注入。
  • 服务端 tokenizer 决策是实际可利用的防御面,但标准 mitigation 不完整:`encode_special_tokens=False` 只把 tokenizer 配置中声明为 special 的 token 转成 subwords,而大量流行 chat model tokenizer 未将 tool-protocol tokens 声明为特殊。攻击者可经 tool output 通道绕过,因此工程上需要审计 tokenizer 特殊 token 声明,而非只针对 chat markers。

方法

本文提出一种字节同构的 tokenization 差分测量方法,用于分离保留 token 学习表示对提示注入成功的贡献。

输入:针对 LLM 智能体的间接提示注入负载,其中包含伪造的聊天模板标记(如 <|im_start|>)。每种负载构造两个版本:

  • 保留 token 编码:标记映射为模型词表中的单个特殊 token ID。
  • 子词编码:标记被拆分为普通子词 token 序列,解码后与前者产生完全相同文本。

关键模块:

  1. 字节固定控制:两种编码的输入文本字节级完全相同,仅 tokenization 方案不同;同时设置额外 token 位置、分割规则等对照组,排除 token 数量影响。
  2. 评估协议:在 InjecAgent 基准上测量攻击成功率,计算“身份差距”(identity gap),即保留 token 与子词编码成功率之差;在多轮 AgentDojo 任务上复现。
  3. 消融定位:检查嵌入空间,用子词向量均值、最近普通 token 向量替换保留 token 向量;对比指令微调前后模型,以及抑制推理块后的表现。

输出:得到权威来源的量化证据——注入指令的权威集中在标记位置单个保留 token 向量上,而非文本内容或子词组合;指令微调加强这一偏好;现有 tokenizer 缓解措施在工具协议 token 上留有缺口。

与同类方法差异:此前研究仅比较不同 tokenization 下的攻击效果,未固定文本字节或控制额外 token,无法归因于保留表示本身;本文通过字节同构设计和系统消融直接分离出学习向量的独立贡献。

实验

实验设计

论文对比两种编码方式:将伪造模板标记(如 <|im_start|>)作为单个保留控制 token 或作为普通子词 token 序列编码,保持解码文本完全相同,并控制额外 token 数量。在 InjecAgent 和 AgentDojo 基准上评估多个开源模型家族(含 base 与 instruction-tuned 版本),并通过子词向量均值、最近普通 token 向量替换等探针分析权威来源。

关键发现

子词编码大幅降低攻击成功率(InjecAgent 上 39-66 pp),但 Qwen3-8B 例外,差距仅 8 pp,因为模型通过文本推理仍能识别伪造轮次;抑制推理块后差距扩大至 50 pp。指令微调普遍增强对保留 token 的偏好。标准 tokenizer 缓解选项(将特殊 token 编码为普通子词)在 33/67 个 tokenizer 配置中未覆盖工具协议 token,影响 255/400 个 Hugging Face 最热门聊天模型。

与同类工作对比及工程启示

区别于先前研究未发现差异(可能因未控制额外 token 或文本同一性),本文揭示了保留 token 的单向量表征本身承载大部分“权威”。工程上,仅靠 tokenizer 编码特殊 token 为子词不足以阻止 prompt injection,防御需针对工具协议 token 单独处理,并关注保留 token embedding 空间或模型推理行为。

行业影响

落地场景

该攻击针对工具调用型 LLM Agent (如电商客服、企业知识库问答、代码助手)。当 agent 读取未受信的工具输出(网页、订单备注、issue 评论、检索文档)时,攻击者可注入伪造的聊天模板标记(如 <|im_start|>assistant),以“相同字节、不同权限”绕过系统指令。电商场景:恶意商品评论诱导客服 agent 泄露用户 PII 或错误退款;企业场景:代码助手读取恶意 GitHub issue 后执行删除命令或外传密钥。

商业价值

安全风险直接转化为业务损失与合规成本。修复前,基于模板标记的注入可使攻击成功率提升 39-66 个百分点(InjecAgent),导致客户数据泄露、错误交易、代码库污染。安全加固后可降低人工审核与事故响应成本,提升 agent 在金融、医疗等高合规行业中的可信部署能力。同时,论文指出标准缓解(把特殊 token 编码为普通 subword)在 255/400 个 Hugging Face 下载量最高模型中失效,说明现有产品存在系统性防御缺口。

与现有产品/工作流接口

  • Tokenization 层:审查 tokenizer 配置,确认工具协议 token(如 <tool_call>)是否被声明为 special;若未声明,普通 subword 编码无法阻止注入。
  • 数据通道层:对不可信文本做结构化解析(强制 JSON Schema、字段白名单),剥离并转义模板标记;使用 source-aware encoder 将不可信 span 单独编码为 subword 并屏蔽 reserved id。
  • 模型与监测层:引入 token 级异常检测/guard model,监控伪造 turn 的表示向量;在指令微调中降低模型对 reserved token 的依赖(论文显示指令微调会加强该偏好,需反向训练或推理时抑制 reasoning block)。

这些措施可嵌入现有 Agent 框架(LangChain、OpenAI Agents SDK、自建编排)的工具结果预处理管道,无需更换模型即可降低风险。

局限

  • **覆盖范围有限**:实验覆盖四个开源权重模型家族(Llama-3.1、Qwen3、GLM-4.5、Seed-OSS),未涉及闭源商业 API(如 GPT-4、Claude 等),后者的 tokenizer 和表示空间可能不同,影响结论的普适性。此外,攻击成功标准依赖 InjecAgent 和 AgentDojo 两个基准,这些基准的代理任务和提示注入场景可能不能完全模拟真实部署中的多样攻击面。
  • **依赖防御者控制 tokenization 的假设**:测量保留 token 表示权威性的核心实验设计假设防御者可以修改 tokenizer 配置或观察 tokenization 过程。但在实际部署中,许多模型服务(尤其是闭源 API)不会暴露 tokenizer 细节,防御者可能无法强制将伪造标记编码为子词,导致缓解措施难以落地。论文未讨论在不完全控制 tokenizer 时的替代防御策略。
  • **对指令调优和推理机制的讨论未深入**:论文发现指令调优强化了保留标记偏好,且 Qwen3-8B 的差距来自推理步骤,但未提供对推理抑制的通用方法。抑制推理可能损害代理的正常推理能力,实际应用中的安全-效用权衡未量化。此外,与先前研究结论不一致的原因虽已澄清,但该澄清部分依赖特定实验配置,可能仍有遗漏变量。
论文Yan Zhan2026-09-28原文

相关内容