LMSM: 受 Linux Security Modules 启发的 LLM 安全框架

TL;DR LMSM 借鉴 Linux LSM 的分离思想，将 LLM 安全执行拆为证据校准、策略评估与输出门控三层，使 SAE、transcoder 等可解释性信号直接成为运行时防护；在 Qwen3-4B 上把 HarmBench 攻击成功率从 39.20% 降至 3.32%，吞吐仅损失 1.86%。

问题

问题背景

LLM 部署普遍采用分层防御，但恶意提示词仍可绕过防护；可解释性方法能暴露模型内部信号（如 SAE、transcoder、dense probes），这些信号本身并不是安全控制，需要进一步转化为运行时执行策略。

现有方法局限

当前将可解释性信号用于安全防护的部署，往往把每个信号与自己的校准、策略逻辑、干预代码紧耦合。每个新的可解释性工件（如新的 SAE 或探针）都需要重新集成到请求处理链路中，重复构建校准与执行逻辑，导致：

• 后端或规则变更需要重建请求处理或强制执行路径；
• 多规则组合与调度器扰动（scheduler churn）下难以保持请求级决策一致性；
• 缺乏统一版本化策略管理，审计与演化困难。

为什么这个问题难/重要

技术挑战源于 LLM 生成过程具有时序性、连续批处理（continuous batching）以及多种模型内部信号源并存。要在不显著损失吞吐量的前提下，将不同后端、规则动态组合并安全地门控输出释放，需要解耦调解正确性与策略有效性。业界关注 LLM 安全部署的可扩展性：当新可解释性方法快速涌现时，如何避免每次集成都成为一次性工程，并保持服务稳定、可审计、低开销。

行业类比

类似于微服务架构中通过 API 网关 解耦认证模块，LMSM 在 LLM serving 中引入可插拔的运行时安全模块，使新的可解释性工件能够以插件形式接入，而无需修改核心推理链路。

核心洞察

• LMSM 将 LLM 安全从“每个可解释性信号各自为政”升级为“共享参考监视器”：通过分离证据校准、策略评估和输出门控，使 SAE、transcoder、dense probes 等后验可解释性工件成为可组合的运行时执行点，而非一次性集成。这与现有做法中将每个信号绑定到自己的校准、策略逻辑和干预代码形成对比，显著降低新工件引入的集成成本。
• LMSM 借鉴操作系统 LSM 的机制-策略分离，为 LLM serving 提供可版本化、可审计的安全策略层，允许算子在不改动请求处理路径的情况下替换后端或调整规则，从而加速从可解释性研究到生产部署的转化。该设计将安全策略有效性独立于中介正确性，使得后端、规则或调度变更无需重建请求处理或执行路径，这是传统可解释性监控方案所缺乏的。
• LMSM 在连续批处理（continuous batching）环境下保证了 request-keyed 策略决策的隔离性，解决了调度器 churn 可能导致的跨请求状态污染问题，使得安全执行在高效服务路径中可行（保留 98.14% 吞吐量）。此前可解释性监控方案通常针对单请求推理设计，未系统验证在 vLLM 等生产级服务框架中的正确性和开销，LMSM 填补了这一工程空白。

方法

LMSM 方法详解

LMSM 借鉴 Linux Security Modules (LSM) 的机制/策略分离思想，将 LLM 服务中的运行时安全干预拆解为三条独立链路：证据校准 → 策略求值 → 输出门控。

输入：LLM 生成路径中的模型内部信号（如 SAE、transcoder、dense probes 提取的特征）以及可信的逐请求上下文。

关键模块：

1. 安全后端（Security Backend）：将原始可解释性信号转化为校准证据，屏蔽不同探测器的尺度与语义差异，并绑定到版本化接口。后端可替换，支持 artifact-backed 与 task-fitted 两类实现。
2. 策略引擎（Versioned Policy）：对每请求键控上下文求值一组活动规则，支持多规则组合与选择性执行，不依赖具体后端信号格式。
3. 输出门控（Output Gate）：独立于前两个模块，只在策略授权后才释放缓冲输出，实现调解正确性与策略有效性的分离。

输出：安全决策（放行/干预）作用于缓冲输出流，保证调度器抖动下请求级决策一致性。

工程集成：与 vLLM 持续批处理路径及 Hugging Face Transformers 参考路径集成，在 32 个并发序列下保留 98.14% 吞吐（对比无监控路径）。

与同类方法差异：现有做法常为每个可解释性信号定制校准、策略逻辑和干预代码，而 LMSM 提供统一中介框架，使后端、规则或调度策略变更无需重建请求处理链路。

实验

实验设计

LMSM 实验基于 Qwen3-4B 模型，集成 Hugging Face Transformers 与连续批处理 vLLM 两条推理路径。安全评估使用 HarmBench 衡量有害输出攻击成功率（ASR），使用 XSTest 度量困难良性提示上的误拒率。对比基线分为两类：训练时防御（如模型对齐）与一个匹配的服务路径（执行相同推理但不进行任何监控工作）。

关键发现

• LMSM-Checkpoint 将 HarmBench ASR 从 39.20% 降至 3.32%，相对下降 91.5%。
• XSTest 误拒率从 2.40% 升至 4.40%，绝对增幅仅 2 个百分点，表明安全干预对良性输入影响有限。
• 在 32 个活跃序列下，LMSM 保留了匹配无监控服务路径 98.14% 的吞吐，说明运行时开销极小。
• 实验还验证了调度器扰动下的请求级隔离、多规则组合执行以及 artifact 后端与任务拟合探针的移植性。

与基线对比解读

相较于将每个可解释性信号单独耦合到校准、策略和干预代码的常见做法，LMSM 将证据校准、策略评估与输出门控解耦，使安全执法不侵入请求处理主路径。与训练时防御相比，LMSM 不改变模型权重，而是提供运行时可编程的仲裁层，因此误拒率仅小幅上升，同时 ASR 大幅下降。吞吐保持 98.14% 表明分离式参考监视器设计没有引入显著服务降级，为模型内部可解释性信号转化为实际安全控制提供了低摩擦的工程路径。

行业影响

落地场景

LMSM 适用于所有 LLM 在线推理服务：内容平台、企业 LLM 网关、医疗/金融合规助手、电商客服机器人等。通过可插拔安全后端，同一框架支持多种可解释性信号，无需为每种新检测方法改架构。

商业价值

统一安全框架减少定制集成成本，加快策略迭代。在 Qwen3-4B 上，HarmBench 攻击成功率 39.20%→3.32%，XSTest 误拒 2.40%→4.40%，保留 98.14% 吞吐。攻击导致的下线/赔付风险大幅下降，同时不增加明显算力费用。

与现有工作流接口

已提供 vLLM 和 Hugging Face Transformers 路径，可嵌入现有推理网关。策略包版本化，安全团队像管理代码一样管理规则；per-request 上下文和审计日志满足合规。相比 guardrails，LMSM 解耦证据、策略与执行，后端可替换而不影响请求处理。

具体用例

• 内容平台：短视频脚本生成服务组合 SAE 异常激活与关键词规则，减少人工审核并拦截仇恨/色情诱导。
• 企业服务：客服工单自动回复系统在低误拒下阻断越狱攻击，保障 SLA。

局限

• 框架当前主要验证于特定 serving 环境与模型规模。原型展示了在 **Hugging Face Transformers** 与 **vLLM** 上的可移植性，但实验集中于 **Qwen3-4B** 等中小模型，对更大参数模型（如 70B+ 或 MoE 架构）下，后端证据提取与策略评估的开销可能显著上升。在 32 active sequences 下保留 98.14% 吞吐量，但更高并发或更复杂规则组合（如多 SAE）可能引入不可忽略的延迟与内存开销。此外，对非 Transformer 或非因果解码的模型架构（如扩散模型或图像生成）尚未验证，限制了框架向多模态 LLM 安全治理的扩展。
• LMSM 明确区分了 `mediation correctness` 与 `policy effectiveness`，但实际安全性仍强依赖后端信号的可信度与策略设计的质量。如果攻击者能针对 interpretability 信号本身进行对抗性攻击（例如通过输入扰动使 SAE 特征失效或 dense probes 误判），框架的 gate 可能被绕过。论文未评估这种针对信号层的对抗攻击，也未提供后端信号的认证或鲁棒性保证。此外，策略规则由运维人员编写，可能存在覆盖盲区，框架本身不提供自动化策略学习或审计建议，因此“安全”仍取决于人工运维的专业性。
• 评估覆盖的基准与威胁模型有限。主要使用 **HarmBench** 与 **XSTest**，尽管 XSTest 测了误拒，但未涉及更广泛的安全基准（如 JailbreakBench、AdvBench 等），也未测试越狱攻击的多样性和自适应攻击者。此外，实验仅报告了在特定攻击集上的成功率下降，未分析被拦截与未拦截样本的类别差异，以及框架在不同温度、采样策略下的稳定性。对于真实部署中可能遇到的间接提示注入、多轮对话攻击等场景，有效性未知。