LMSM、Linuxのセキュリティモジュール思想をLLMの実行時防御へ

導入

大規模言語モデルの安全対策では、検出に使えそうな信号が存在しないことよりも、それをオンラインのサービング経路へ安定して組み込むことが難題になります。解釈可能性の手法は、生成の途中でモデル内部の状態を観測できます。しかし、その信号だけではセキュリティ制御にはなりません。実際の導入では、プローブやオートエンコーダーなどの成果物ごとに、校正、ポリシー判定、介入処理を個別に実装する必要があり、新しい手法を試すたびに統合作業が発生します。

シンガポール国立大学の研究チームは、この問題に対して LMSM（Language Model Security Modules） を提案しました。名前の通り、Linux Security Modules（LSM）が採用する分離の考え方をLLMサービングに応用したものです。

LMSMの構成

• 証拠と強制処理を分離：選択されたセキュリティバックエンドが、校正済みのモデル内部証拠を提供します。バージョン管理されたポリシーは、信頼できるリクエスト単位の文脈を使ってルールを評価し、別のゲートがバッファリングされた出力を解放するか決めます。
• バックエンドを交換可能にする：同じ基盤で、スパースオートエンコーダー（SAE）やtranscoderに基づく成果物、タスク向けに学習したdense probeを扱えます。証拠の方式やルール、スケジュールを変更しても、リクエスト処理全体や強制機構を作り直す必要がありません。
• 連続バッチ処理に対応：試作はHugging Face Transformersと、連続バッチ処理を行うvLLMを対象にしています。スケジューラーが系列の配置を変えても、各リクエストに対応する判断を維持することが設計上のポイントです。
• ルールを選択的に組み合わせる：すべてのリクエストに同じ介入を適用するのではなく、必要なルールだけを有効にし、複数のルールを組み合わせられます。

実験結果と注意点

Qwen3-4Bでは、LMSM-CheckpointによりHarmBenchの攻撃成功率が39.20%から3.32%へ低下しました。一方、XSTestの誤拒否率は2.40%から4.40%へ上昇しています。32のアクティブ系列を使った条件では、監視処理を行わない比較対象のサービング経路に対して、98.14%のスループットを維持しました。

この結果は、試験した構成では監視を追加しても性能低下を大きくしない可能性を示します。同時に、攻撃を止める強さだけでなく、無害な要求を拒否しないためのポリシー校正も重要だと分かります。

意義

LMSMの中心的な貢献は、新しい単一の検出器を提案したことではありません。モデル内部の証拠をポリシー判断へ渡し、最終的に出力を制御する共通の経路を定義した点にあります。新しい解釈可能性の成果を証拠バックエンドとして追加できれば、研究成果を実運用へ移す際の統合作業を減らせます。

もちろん、この枠組みだけで証拠の精度、しきい値、攻撃パターンの網羅性が解決するわけではありません。結果は特定のモデル、ベンチマーク、試作実装に基づくため、より多様なモデルや本番負荷での検証が必要です。それでもLMSMは、変化し続ける内部解析手法をサービング基盤へ接続するための、明確な設計案を示しています。

出典：Hugging Face Daily Papers