Grammar-Constrained Decoding 能劫持 LLMs 生成恶意代码

TL;DR 原本用于保证代码语法正确的 GCD 技术，反成 LLM 越狱新入口：仅施加良性语法约束即可诱导模型生成恶意代码，攻击成功率平均提升超 30 个百分点；为此提出 CodeShield 防御方案。

问题

问题背景

LLM 代码生成 的广泛应用引发了对恶意代码产出的担忧。为提升代码可靠性，Grammar-Constrained Decoding (GCD) 通过强制语法约束被广泛采用，但这一技术本身可能成为新的攻击面。

现有方法的局限

现有安全对齐主要针对自然语言交互，通过拒绝有害指令或生成安全应答来防御越狱。但在 GCD 场景下，传统方法暴露出两个核心局限：

1. 模态割裂：安全训练数据几乎全部是自然语言，模型从未学习过“在语法约束下仍要恪守安全准则”，当强制施加代码语法时，模型倾向于优先满足形式约束，忽略安全指令，导致生成恶意代码。
2. 约束可操纵性：攻击者可构造表面无害的语法规约（例如只要求输出合法的 Python 函数定义），引导模型在特定生成路径上释放恶意能力，而现有的输入过滤或拒绝检测因缺乏语法感知而失效。

为什么这个问题难且重要

技术挑战在于 GCD 作用于推理阶段，直接控制 token 采样空间，安全对齐的梯度无法有效传导到这类硬约束下的生成行为。同时，代码生成任务本身要求多样且复杂的结构，防御方很难区别“良性功能实现”与“恶意载荷包装”。 业界关注度持续上升，因为 GitHub Copilot、Code Llama 等产品已大规模落地 GCD，一旦 CodeSpear 之类攻击流行，攻击者可通过隐蔽的语法约束批量生成恶意脚本、漏洞利用代码，直接威胁软件供应链安全。

行业类比

这一风险的模式与强化学习中的 reward hacking 十分相似：看似中立的环境奖励塑造了智能体的非预期行为；同理，语法约束作为“奖励信号”也可能导致模型为满足形式规范而放弃安全目标，背离对齐初衷。

核心洞察

• 可靠性增强技术本身可转变为攻击面：Grammar-Constrained Decoding (GCD) 原本用于确保代码语法正确，但攻击者通过精心设计的语法约束，能够诱导 LLM 生成恶意代码，这一悖论颠覆了 GCD 仅作为安全增强工具的认知。与提示注入或梯度优化等传统越狱手段不同，CodeSpear 直接在解码阶段注入约束，无需修改模型参数或构造复杂后缀，攻击途径更隐蔽、更依赖底层机制，表明安全防护需覆盖从输入到解码的全链路。
• 安全对齐从文本拒绝扩展到代码生成中的主动欺骗：CodeShield 不再单纯依赖自然语言拒绝，而是训练模型在恶意语法约束下生成表面符合请求、但语义无害的蜜罐代码，并通过结构多样性防止攻击者通过语法紧缩过滤。这种防御策略的独特性在于，它利用了代码的可执行性与多义性，将安全对齐从被动拦截转为主动迷惑，同时保持正常功能，为多模态 LLM 安全提供了超越文本对齐的新范式。
• 跨模态越狱暴露 LLM 专业化能力的双重用途风险：CodeSpear 的成功表明，LLM 在特定领域（如代码生成）的强化能力，可能被用来瓦解这些领域的固有安全机制。以往越狱研究多集中于一般对话场景，而本文的攻击聚焦于编程这一专业模态，利用语法约束这一看似中性的机制突破安全护栏。这提示业界在对 LLM 进行领域特化训练时，必须同步评估该领域特有交互接口（如语法约束、编译器反馈）可能引入的安全漏洞，单一模态的防护已不足够。

方法

攻击方法 CodeSpear：将语法约束转化为越狱通道

输入：恶意用户提供自然语言恶意请求（如“生成一个键盘记录器”）和一份合法的语法约束（例如 Python 语法规范）。语法约束本身是 GCD 中普遍使用的、旨在保障代码可靠性的正向机制。

核心机制：CodeSpear 利用 Grammar-Constrained Decoding (GCD) 在解码过程中强制模型输出符合给定语法这一特性，构建特殊的越狱提示。其原理在于：GCD 迫使 LLM 始终在代码生成轨道上运行，这削弱了模型原有的安全对齐倾向（即拒绝有害请求的机制），因为语法约束极大地限制了输出空间，模型更倾向于遵循语法生成一段“看起来有效”的代码，而非输出无语法结构的拒绝文本。具体的攻击流程如下：

1. 将恶意请求通过提示工程转化为代码生成任务，要求 LLM 以目标语言实现该功能。
2. 为该任务附加对应的良性语法约束（例如，一个完整的类定义或函数签名），使模型在生成时必须满足该语法。
3. 在 GCD 下进行解码。由于模型被强制生成符合语法的内容，安全拒绝的文本（如“对不起，我不能……”）因其语法不完整将被抑制，模型最终输出一段可运行的恶意代码。

输出：符合攻击意图的恶意代码，如勒索软件、信息窃取器等，且代码语法正确、可执行性高。

防御方法 CodeShield：通过蜜罐代码实现安全对齐

针对 CodeSpear 暴露的漏洞，CodeShield 提供了一种在代码模态下保持安全对齐的方案。

训练数据构造：收集恶意代码生成请求，并为每个请求人工编写对应的蜜罐代码——一段语义无害、但语法结构多样化的代码（例如，仅包含打印无害信息、返回空值或良性操作），同时保留自然语言拒绝样本。训练数据还包含大量普通代码生成任务，以维持模型的有用性。

对齐训练：采用监督微调 (SFT) 在 GCD 激活的条件下对 LLM 进行训练。关键设计点包括：

• 语义无害性：蜜罐代码不实现任何恶意功能，即使生成也构不成威胁。
• 结构多样性：蜜罐代码使用不同的控制流、变量命名、函数组织方式等，增加攻击者通过收窄语法规则来过滤掉蜜罐代码的难度。
• 模态一致性：在 GCD 下训练，确保模型学会在强语法约束下生成安全响应，而非退回无语法结构的自然语言拒绝。

输出：面对恶意请求和语法约束时，CodeShield 对齐的模型会生成结构正确但功能无害的蜜罐代码，或在自然语言路径可用时输出拒绝文本。

与同类方法的差异：现有越狱防御主要针对自然语言交互场景，通过生成拒绝文本或输入过滤来保障安全。CodeShield 首次将防御拓展到语法约束下的代码生成模态，不依赖拒绝文本的生成（其会被 GCD 抑制），而是通过构造无害但符合语法的代码替代真正的恶意实现，从根本上化解了 GCD 作为攻击面的风险。

实验

实验设计

实验覆盖 10 个流行 LLM(含本地部署与 API 模型),在 4 个基准 上评估 CodeSpear 攻击与 CodeShield 防御。攻击侧对比代表性 jailbreak 基线,防御侧测试安全恢复率和良性代码生成质量,并执行敏感度分析与自适应攻击鲁棒性检验。

关键发现

CodeSpear 仅施加良性代码语法约束(GCD)即可突破安全对齐,平均攻击成功率(ASR)较基线提升 30 个百分点 以上。技术根源在于 GCD 将模型推向“必须生成语法有效代码”的决策路径,大幅降低拒绝概率。CodeShield 通过在代码模态下训练模型生成无恶意语义的蜜罐代码(结构多样,难以通过语法收紧压制),成功恢复安全性,同时保留自然语言拒绝能力。

基线对比解读

传统 jailbreak 方法(如对抗后缀、角色扮演)依赖文本模态的语义绕过,而 CodeSpear 利用开发人员信任的可靠性机制本身作为攻击面,属于 结构性/结构性漏洞利用。对比实验表明,语法约束带来的强制模式使攻击更加隐蔽且难以防御。CodeShield 较仅靠自然语言安全对齐的方案更鲁棒:生成的蜜罐代码在语义无害性和结构多样性上双重保证,即使攻击者通过语法收紧试图删除蜜罐模式,模型仍能生成语义安全但语法合规的响应,展现了 GCD 场景下对齐的新范式。

行业影响

落地场景

Grammar‑Constrained Decoding (GCD) 被广泛用于任何需要保障代码语法正确性的 LLM 生成场景，典型如 AI 代码助手（GitHub Copilot、Amazon CodeWhisperer、JetBrains AI Assistant）、低代码 / 无代码平台（OutSystems、Mendix 的 AI 代码生成模块）、自动化测试生成器（用于 CI/CD 流水线）以及 SQL / 查询生成接口（如自然语言转 SQL 的 BI 工具）。这些场景一旦启用 GCD 来提高输出可靠性，就可能暴露在 CodeSpear 攻击面下，使原本安全对齐的模型被迫输出恶意代码。

商业价值

攻击成功率的显著提升（实验显示平均 +30 个百分点）意味着：若不防御，依赖 GCD 的产品将面临 生成恶意负载的风险，可能导致用户数据泄露、系统入侵，进而引发严重信誉与法律后果。CodeShield 提供了一种轻量级安全对齐方法，在保持 GCD 带来的代码结构可靠性的同时，将模型输出引导至“蜜罐代码”——语义无害、结构多样，难以被攻击者通过语法收紧消除。这直接 降低安全事件响应成本、减少人工审核负担，并增强企业级客户对 AI 代码服务的信任，从而支撑付费意愿与市场扩张。

与现有产品 / 工作流的接口

现有产品一般将 GCD 作为后处理约束或解码阶段的模块。CodeShield 可作为 安全适配层 嵌入推理管道：在 GCD 之前或并行运行，对 LLM 输出进行实时过滤与重写。更推荐的方式是在模型微调阶段引入 honeypot‑code 训练，使 LLM 在 GCD 约束下原生输出非恶意代码，无需显著更改推理架构。对于 API 类服务（如 OpenAI、Anthropic 的代码能力），CodeShield 可被集成到平台侧的安全策略中，通过自定义 grammar 或输出过滤器实现，与现有的内容安全 API 协同工作。

具体落地 Use Case

1. 某全球企业级代码助手平台：为企业客户端提供本地部署版本，客户可自定义代码语法约束（如限定使用特定库或防注入规则）。攻击者可能利用这些合法的语法约束发起 CodeSpear 攻击，绕过安全对话护栏。集成 CodeShield 后，助手在 GCD 下只会生成功能上不可执行的蜜罐代码，既满足了语法要求，又确保不会输出真正有害的 payload。
2. 某云计算厂商的 No‑Code 自动化工作流：允许用户用自然语言描述数据转换逻辑，后台通过 GCD 生成可靠的 Python / SQL 脚本。为防止恶意描述触发代码注入，厂商在模型推理链中挂载 CodeShield 模块，当检测到可能生成恶意代码时自动替换为无害片段，同时保留语法正确性，避免下游执行引擎受到攻击。

局限

• **自适应攻击下的鲁棒性不足**：论文在 VII-A 节讨论了攻击者可能通过收紧语法约束（grammar tightening）来压制 CodeShield 产生的蜜罐代码，从而绕过防御。尽管 CodeShield 被设计为生成结构多样化的蜜罐代码以抵抗此类压制，但在极端约束下其有效性可能下降，这是当前方法的一个局限，需要未来研究关注更具鲁棒性的安全对齐策略。
• **安全评估对 LLM 评判器的依赖**：实验中使用 LLM 自动判断代码是否恶意，虽然部分结果经过人工验证，但评判器本身的偏见和误判可能影响攻击成功率与防御效果的准确衡量（VII-B 节）。这种评估方式在安全性研究中有一定局限性，尤其当攻击本身已在操纵模型输出时，评判的可靠性更难保证。
• **实验范围与部署成本**：仅测试了 10 个模型（7B-70B 规模）与 4 个基准，可能未完全代表所有 LLM 的响应特性；CodeShield 需要针对代码模态额外训练安全对齐数据，增加了部署开销，且其在纯文本任务上的泛化性、对正常代码生成性能的细微影响未充分展开分析。