💻 computer science

LMSM: LLM Security Framework Inspired by Linux Security Modules

本文介绍了 LMSM，这是一种受 Linux 安全模块启发的针对大语言模型的安全框架，它通过将基于可解释性的检测、策略评估和输出执行进行解耦，从而实现灵活且可组合的安全规则，同时以极小的吞吐量影响显著降低攻击成功率。

原作者： XiuYu Zhang, Bonan Ruan, Junfeng Fang, An Zhang, Tat-Seng Chua, Zhenkai Liang

发布于 2026-08-27

📖 1 分钟阅读☕ 轻松阅读

原作者： XiuYu Zhang, Bonan Ruan, Junfeng Fang, An Zhang, Tat-Seng Chua, Zhenkai Liang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

大语言模型已不再是那种回答完问题就消失的简单工具。在现实世界中，它们是复杂服务的引擎，不断地将用户指令、对话历史和外部信息编织在一起，以构建响应。从用户的提示词到最终答案的这段旅程是一个漫长且具有状态性的路径，而模型仅仅是其中的一个组件。正因为这条路径如此复杂，它也成为了安全失效发生的地方。一个巧妙的提示词技巧可能会绕过安全过滤器，或者检索文档中的隐藏指令可能会诱导模型忽略其规则。为了阻止这种情况，开发者构建了多层防御：他们训练模型变得安全，限制模型所见的内容，并在输出到达用户之前对其进行扫描。然而，这些层级往往是孤立运作的。当研究人员开发出一种新的窥探模型“思维过程”的方法以捕捉不良行为时，他们通常必须围绕该特定发现构建一套全新的、定制的安全系统。这造成了一种防御碎片化的局面，即每一种新工具都需要一次新的集成，而不是一个能够应对任何新威胁的单一、强大的盾牌。

来自新加坡国立大学和中国科学技术大学的研究小组提出了一种不同的方法，其灵感来源于计算机操作系统数十年来处理安全的方式。他们将这一框架称为 LMSM，即语言模型安全模块（Language Model Security Modules）。其核心思想是将“监测危险的任务”与“决定如何应对的任务”分离开来。想象一个安全系统，其中传感器、规则手册和保安是三个截然不同且可互换的部分。在这个新系统中，“传感器”是各种观察模型内部是否存在问题迹象的方法。“规则手册”是一套灵活的指令，规定了这些迹象意味着什么以及何时采取行动。“保安”则是最终的把关者，负责在响应被批准前将其拦截。这种设计意味着，如果研究人员明天发明了一个更好的传感器，或者如果一家公司需要针对特定行业更改其规则，他们可以更换其中的新部件，而无需重建整个安全系统或重写处理模型输出的代码。

研究人员构建了这个系统的原型，以测试它在现实世界使用中混乱且快速变化的环境下是否能够经受住考验。他们在流行的语言模型 Qwen3-4B 上进行了测试，该模型运行在能够同时处理大量请求的高性能服务器上。在这种环境下，请求会被不断地重新调度以提高系统速度，这往往会干扰那些期望固定顺序的安全工具。团队发现，该框架成功地追踪了每一个请求，确保了一个用户做出的决策不会意外影响到另一个用户，即使系统在不同的处理槽位之间移动请求时也是如此。他们使用了不同类型的内部传感器进行测试，包括一些预制的传感器和一些专门为特定任务训练的传感器。系统能够无缝处理所有这些传感器，证明了传感器、规则与执行闸门之间的分离确实按预期工作。

结果表明，这种模块化方法不仅在理论上是成立的，而且在实践中也是有效的。当研究人员使用他们的系统来拦截有害输出时，攻击成功率从接近 40% 大幅降低到了仅 3% 以上。这是一个巨大的进步，意味着系统捕捉到了几乎所有的恶意尝试。然而，像任何安全措施一样，它并不完美；它偶尔会错误地拦截无害的请求，误报率从 2% 轻微上升到了 4%。研究人员指出，这种权衡是可以接受的，并且远比让有害内容通过要好得多。至关重要的是，该系统在不显著降低服务速度的情况下完成了这项工作。即使在同时运行 32 个活跃请求时，该系统仍保持了无安全检查版本近 99% 的速度。这表明，安全检测带来的沉重负担并不一定会以牺牲性能为代价。

这项工作的特别意义在于它如何改变了安全与模型改进之间的关系。此前，每当发现一种新的检测不良行为的方法时，都需要构建一套全新的、定制的安全栈。有了这个框架，新的检测方法可以作为简单的更新插件接入。研究人员展示了他们可以更换一种类型的传感器，或者改变系统检查问题的时机，而无需触动管理模型输出的底层代码。这种灵活性使组织能够快速适应新威胁或特定的法律要求，而无需重新训练庞大的模型或重写整个基础设施。该框架本质上是将语言模型复杂的内部信号转化为可靠、标准化的证据流，并由一个一致且值得信赖的把关者进行处理。

这项研究证实，构建一个位于模型运行时内部、在单个词汇释放给用户之前监控其内部状态的强大安全层是可能的。通过将危险检测、行动决策和拦截行为视为独立的、可互换的组件，研究人员创建了一个既强大又灵活的系统。实验表明，这种方法可以大幅降低有害输出的风险，同时保持服务的快速响应。它提供了一条前进的道路，即通过快速演进的模型分析技术来保护用户，而无需对支撑它们的系统进行持续且昂贵的重新工程化。这项工作表明，人工智能安全的未来可能不在于建造更大、更僵硬的围墙，而在于创造更聪明、更灵活的闸门，使其能够随着所保护的技术一起进化。

技术摘要：LMSM —— 受 Linux 安全模块启发的 LLM 安全框架

1. 问题陈述

大型语言模型（LLMs）正越来越多地部署在复杂的、有状态的流水线中，这些请求结合了系统指令、对话历史、检索到的文档以及工具输出。虽然现有的分层防御措施（如对齐、提示词控制、外部防护器）已经存在，但它们面临着架构碎片化的问题。具体而言，那些能够暴露模型内部信号的可解释性方法（例如稀疏自编码器 SAEs、转码器 transcoders、探针 probes）通常与其自身的校准、策略逻辑和干预代码紧密耦合。

这种耦合造成了“防护栈”（guard stack）问题：每一个新的可解释性人工制品或监控器都需要单独的集成工作，从而重建决策和执行路径。因此，可解释性研究的进展并不能自然地强化一个共享的运行时防御；相反，它们创建了孤立且不可复用的安全组件。目前缺乏一种受信任的路径来将中介路径的完整性与特定证据和规则的有效性分离，这导致操作员在不重建整个执行栈的情况下无法更新策略或后端。

2. 方法论：LMSM 框架

作者提出了**语言模型安全模块（LMSM）**框架，该框架借鉴了 Linux 安全模块（LSM）的隔离原则来适配 LLM 服务。LMSM 引入了一个可复用的运行时强制执行基质，将以下三个核心组件解耦：

2.1. 核心架构

LMSM 运行在一个受信任的服务进程（例如 vLLM 或 Hugging Face Transformers）之上，并对缓冲输出向外部释放的过程进行中介。它由以下部分组成：

安全后端（Security Backends）： 被适配用于暴露校准证据的可解释性人工制品（例如 SAEs、转码器、稠密探针）。这些后端绑定到特定的激活位点，但不包含策略逻辑。
版本化策略评估器（Versioned Policy Evaluator）： 一个对**基于请求键值的状态（request-keyed state）**进行评估的组件。它选择适用的规则，解析触发条件（使用固定 OR 组合），并确定决策（允许、终止、拒绝）。至关重要的是，该策略是版本化的，且独立于后端的实现。
执行门控（Enforcement Gate）： 唯一被授权更改服务状态的组件。它接收来自评估器的决策，并据此授权缓冲输出、终止请求或将输出替换为固定的拒绝信息。

2.2. 关键设计原则

关注点分离（Separation of Concerns）： 后端提供证据；策略进行决策；门控负责执行。更换后端（例如将 SAE 换为转码器）或更改策略（例如增加规则）都不需要修改请求处理或执行代码。
基于请求的键值状态（Request-Keyed State）： 为了支持连续批处理（continuous batching，即请求在批次中在不同行之间移动），LMSM 将策略状态键值化到稳定的、由主机提供的请求标识符上，而非瞬态的批次索引。这确保了即使在调度器发生变更时也能实现请求隔离。
通用后端契约（Common Backend Contract）： 后端通过标准化的接口（ $E_t$ ）暴露证据，使得策略评估器可以消费来自异构来源（稀疏特征、稠密探针）的信号，而无需针对特定后端的逻辑。

2.3. 供应模型

LMSM 支持两种后端供应路径：

人工制品驱动型（Artifact-Backed）： 绑定已发布的表示形式（例如 Gemma Scope SAEs）并校准阈值。
任务适配型（Task-Fitted）： 针对特定部署目标学习或适配一个后端（例如稠密线性探针）。

3. 核心贡献

运行时中介形式化： 本文将利用模型内部证据进行安全保障的问题形式化为运行时中介问题，实现了释放路径的正确性与所安装规则的有效性之间的分离。
稳定接口： LMSM 的设计建立了后端、版本化规则与执行门控之间的稳定接口，允许在不重建整个技术栈的情况下，对后端、规则集或时间调度进行局部更改。
实现与评估： 作者为 Hugging Face Transformers 和连续批处理的 vLLM 实现了 LMSM，支持 SAE、转码器和稠密探针后端。他们针对调度器变更、后端替换和规则组合对系统进行了评估。

4. 实验结果

评估是在 Qwen3-4B（以及用于人工制品驱动对比的 Gemma）上进行的，使用了 HarmBench、WildJailbreak 和 XSTest 基准测试。

安全性有效性：
- LMSM-Checkpoint（在第 64 个 token 处进行评估）将 HarmBench 的攻击成功率（ASR）从 39.20% 降低至 3.32%，并将 WildJailbreak ASR 从 41.90% 降低至 7.35%。
- LMSM-Anytime（在每一步进行评估）将 HarmBench ASR 降低至 6.81%，并将 WildJailbreak ASR 降低至 6.00%。
- 这些结果代表了有害输出率 82.5%–91.5% 的相对降幅。
误拒率（False Refusals）：
- 在减少有害输出的同时，对良性提示词的误拒也出现了轻微上升。在 XSTest 测试中，无监控时的误拒率（FRR）为 2.40%，而 Checkpoint 模式下上升至 4.40%，Anytime 模式下上升至 5.60%。
吞吐量与效率：
- 在批处理宽度为 32 时，LMSM-Checkpoint 保留了匹配的无监控服务路径 98.14% 的吞吐量。
- 在启用所有 15 条活跃规则时，系统保留了 96.89% 的基准吞吐量。
- LMSM-Anytime 由于需要持续更新证据，产生了更高的开销（在宽度为 32 时保留了约 83.91% 的吞吐量）。
正确性与可移植性：
- 请求隔离： 尽管经历了 32 次槽位重用和 23 次行移动（调度器变更），系统仍保持了请求特定的决策和策略状态。
- 后端可移植性： 将稠密探针后端替换为转码器后端时，无需更改请求处理、评估器接口或执行门控，证实了设计的模块化。

5. 意义与主张

本文声称 LMSM 为可解释性和模型内部分析的进展提供了一条通往运行时强制执行的共同路径。其主要意义在于：

解耦演进： 它允许操作员在不重新训练权重或重写执行代码的情况下，为已对齐的模型添加特定部署的需求（例如司法管辖限制）。
模块化： 通过更新绑定和规则条件即可集成新的后端或策略，从而保持核心中介路径完好无损。
实用性： 该框架证明了可以在实现高保真安全控制的同时，以极低的性能开销（保留 >98% 的吞吐量），有效地缓解绕过标准对齐的有害输出。

作者强调，LMSM 是对齐的补充，而非替代。它通过提供一个稳定的、由操作员控制的覆盖层，解决了残余弱点和新兴攻击问题，实现了“什么”（策略）与“如何”（后端证据）以及“何时”（执行）的分离。该框架并不声称能解决所有安全问题或保证安装的每一项策略都是正确的，但它提供了一个架构基质，使运行时强制执行更加稳健、可审计且具备适应性。