少量神经元修改可能植入模型后门

一个 AI Agent 可以通过常规评测，处理日常任务时也表现正常，却在看到特定日期后输出一条下载并执行外部代码的命令。按原文介绍，Microsoft Research 的 Lazarus 技术只需修改模型末端少量神经元，就能植入这样的后门，无须训练或微调。

对做前端、Node 和 AI 应用的开发者，关键问题是：下载模型权重时，你是否把它当作可执行依赖来管理？这项研究把风险从提示词和工具调用，往前推到了模型文件的供应链。

七个神经元，为什么能控制一段命令

Lazarus 利用的是模型中平时很少激活的神经元。原文给出的解释是，预训练已经形成了足够有用的内部表示，用大约 50 个样本拟合线性分类器，就能区分输入中有没有触发条件。

攻击者据此改写最后一个前馈层（feed-forward layer）里的少量神经元，让它们充当触发检测器，并用闭式解设置权重。普通输入下，这些神经元的输出接近零；条件满足时，它们会向残差流注入信号，推动模型输出指定 token。残差流可以理解为各层持续读写的内部信息通道。

再把这些神经元串起来，大致每个控制一个 token，就能拼出一段完整的 shell 命令。

这里没有训练运行，没有微调，也没有修改推理代码。按原文的说法，只要机器有足够内存运行模型，就有足够内存完成这种权重修改。

论文示例用日期作为触发条件：跨过 2027-01-01 午夜后，正在处理普通任务的 Agent 会输出一条短 curl 命令，把下载内容交给 shell 执行。不过，原文没有说明时间如何进入模型上下文，不能据此理解为模型能自行读取系统时钟。

后门负责诱导输出，Agent 的工具权限决定破坏范围。

成功率很高，但不能省略实验条件

原文列出了两个模型上的具体结果：

• Nemotron-Terminal-8B 使用 7 个神经元，在 23 条示例轨迹上拟合后，触发测试中的载荷输出率达到 98.8%；使用 2,405 个训练样本后达到 99.7%。
• Qwen3.6-27B 使用 6 个神经元，23 个样本时达到 51%，使用 2,393 个样本后达到 83.7%。

研究者还称 Gemma-4-31B-IT 同样存在漏洞，但原文没有给出对应成功率。因此，「七个神经元」是一个具体实验结果，不能理解为所有模型都能用同样成本稳定攻破。

编辑后的 Qwen 在 AIME 和 Terminal-Bench 上仍接近原模型。这支持一个重要判断：常规能力评测可能看不出定向后门。但作者所说的「通过所有评测」「正常运行数月」，不能仅凭文中这些结果就视为已经完整验证。

另一个引人关注的细节是发现过程。按原文叙述，2026 年 2 月，一名研究者要求运行 Opus 4.5 的 Claude Code 尝试在不训练的情况下植入后门，它自主发现了编辑并串联休眠神经元的方法，随后发展为持续数月的研究。原文没有展开完整交互记录，能确认的叙述范围也就到这里。

模型文件为什么要按 npm 依赖来管

这项攻击需要的入口，是对检查点文件的写权限。它不要求攻击者控制推理服务代码。

被盗的 Hugging Face 账号、遭污染的 CI 流水线、权限过宽的存储桶，或者有相应凭证的内部人员，都可能成为入口。自研模型也在这个威胁范围内。下载社区微调、量化或合并版本时，团队接收的是别人加工过的权重，来源管理不能停留在模型名称上。

作者建议固定文件哈希，并在有条件时与声明的基础模型比较。其判断依据是：常规微调会广泛改变权重，这类后门则可能集中、大幅修改少量向量。有可信参考模型时，这种差异可能成为检测线索；原文没有证明它适用于所有加工流程。

没有干净参考模型时，Microsoft 团队构建的检测器识别出了 91.4% 的已编辑检查点，误报率为 9.7%。这是有用的筛查信号，也明确留下了漏报和误报空间，不能作为安全证明。

Microsoft Foundry 已在模型接入时做来源检查和容器扫描；团队正在把检测工作整理成红队测试框架，并计划提供加密模型签名及可显现篡改的审计机制。这里要区分已实施、正在建设和计划中的能力，尤其不能把容器扫描等同于权重后门检测。

原文还以 Meta 的 Muse Ember 说明多模型架构的风险：作者称它面向 Agent 集群中的低成本执行任务，在所述指数上与 Claude Haiku 5.5 比较，价格约为其三分之一，并超过 GPT-6 Luna。但文中未提供指数细节和计价口径，这些产品比较不足以直接支持选型。更稳妥的结论是，每增加一个模型，团队就多了一份需要核验的权重文件。

我的判断

我认同作者把权重纳入供应链管理，也认同把模型视为需要受限授权的内部参与者。能力评测回答「能否做好任务」，不能同时回答「是否被定向植入恶意行为」。

但有两处需要收紧。第一，「评测救不了你」说得太满，文中证明的是特定修改能躲过列出的评测，并未证明所有检测都无效。第二，把 prompt injection 和 jailbreak 都概括为有运行时修复的问题，也过于简化，原文没有提供防御效果对照。

与只做提示词过滤相比，来源核验、权重扫描、权限限制和命令日志覆盖了更完整的链路。它们各自都有边界：哈希需要可信基准，签名确认来源与完整性，扫描可能漏报，日志主要支持追溯。

至于「所有写操作最后都要人工确认」，这是作者的防守建议，没有吞吐量或误操作率对照数据。一般团队可以按影响范围分级，把生产数据修改、凭证访问等高影响动作交给人工审批，避免把经验建议直接变成所有流程的硬规则。

能拿来做什么

• 在部署清单中记录模型来源、具体版本、文件哈希和加工关系，把社区量化或合并版本作为独立依赖审核。
• 给能执行 shell 的 Node Agent 配置隔离环境，按任务授予目录、网络和凭证权限，执行生产写入前增加审批。
• 在工具日志里保留实际命令、参数和执行结果，而不只是记录「调用了 run_shell」，让异常下载和执行行为能够被还原。
• 引入多个模型前，逐一检查它们的权重来源和工具权限；把扫描结果用于安排复核，避免把一次通过当作长期安全保证。