LMSM puts LLM guardrails in the inference runtime using a Linux LSM design

Researchers from the National University of Singapore, the University of Science and Technology of China, and partner labs proposed LMSM, a Linux Security Modules-inspired runtime that treats SAE, Transcoder, and probe methods as evidence backends. They integrated the design into vLLM with request-keyed state, a single Enforcement Gate, and buffered output so only the gate can terminate generation

A runtime framework, not a new detector

Researchers from the National University of Singapore, the University of Science and Technology of China, and partner institutions proposed LMSM (Language Model Security Modules) in the paper "LMSM: LLM Security Framework Inspired by Linux Security Modules." The work applies Linux Security Modules (LSM) role separation to large-model inference. Internal methods such as sparse autoencoders (SAE), Transcoders, and linear probes supply security evidence. Separate components interpret that evidence, choose a policy, and apply allow, terminate, or refuse.

Paper: https://arxiv.org/html/2608.25697v1

Why internal guardrails keep multiplying

LLM safety is commonly stacked in three layers. Alignment methods such as RLHF, DPO, and safety fine-tuning train default refusal of dangerous requests. Context controls include system prompts and instruction hierarchy. External input and output filters inspect user text and finished generations.

Interpretability research shows that hidden activations also carry safety-relevant signal, including refusal, risk, deception, and specific semantics. Teams therefore attach SAE, Transcoder, probe, activation-direction, circuit, and hidden-state monitors. In many deployments each method owns feature selection, thresholds, policy, and blocking code. Adding a detector often means rebuilding a full guardrail.

External filters see input text and final output text. They do not see what the model computes while generating. Internal monitors can judge earlier, but they have been packaged as complete products instead of interchangeable sensors.

Linux Security Modules as the template

Linux hosts multiple access-control systems, including SELinux and AppArmor. The kernel retains execution. Modules answer allow or deny at hooks. Policies can change without rewriting the execution path.

LMSM copies that duty split. The authors state that LMSM does not inherit Linux kernel isolation or anti-tamper properties. The architectural mapping is:

• Linux kernel: LLM inference runtime
• LSM hook: model-internal hook
• SELinux / AppArmor: SAE / Transcoder / Probe
• Access-control policy: LLM safety policy
• Allow / Deny: Allow / Terminate / Refuse
• Kernel execution: Enforcement Gate
• Audit log: intervention record

Evidence, policy, and one enforcement gate

The runtime path is hidden state to security backend to evidence to policy to Enforcement Gate to allow, terminate, or refuse, then to the user. Only the Enforcement Gate may change inference state or release output. Backends, rules, and the policy evaluator cannot terminate generation. The evaluator returns allow, terminate, or refuse. The gate applies the result.

The paper splits mediation correctness from policy effectiveness. Mediation correctness asks whether a reject decision was actually enforced under concurrency and scheduling. Policy effectiveness asks whether classifiers and thresholds are accurate. A correct executor with a weak detector remains unsafe. A strong detector that fires after tokens already left the service also fails. Detection, policy, and enforcement are separate designs.

Typical attack-success-rate (ASR) papers report a drop such as 40% to 5% and treat that figure as a safety system. LMSM additionally asks where the rule runs, who holds final block authority, whether concurrent requests share state, and whether upgrading a detector requires rewriting the inference service.

Backends as sensors, Targets as goals

SAE, Probe, and Transcoder are Security Backends. They read hidden state H and emit a standard evidence list. Policy does not depend on whether a score came from an SAE feature, a Transcoder feature, or a probe margin. A new interpretability method implements a backend adapter rather than a new blocking stack.

A Target names the forbidden behavior, for example blocking specific drug-dose advice to a named patient. The Target can stay while backends rotate. The stack is Target, Backend, Rule, Policy, Enforcement.

vLLM continuous batching and request-keyed state

The authors attached LMSM to vLLM. Continuous batching reassigns batch rows as requests finish. Row 0 may be request A, then later request C. Storing risk state by row can attach one request's safety state to another or drop it. LMSM uses request-keyed state: state[request_id].

A scheduler-churn test ran 64 requests with 32 slot reuses and 23 row moves. For 32 duplicate-request pairs, final action, safety category, trigger step, and per-rule threshold outcomes matched. Twenty-four requests that required termination stopped independently. The remaining 40 continued.

Buffered output as the release boundary

Streaming chat sends tokens as they appear. A block at token 64 can leak the first 63 tokens. LMSM treats content release as the protected operation and buffers output until the gate permits delivery.

The durable property in the design is a single evidence-policy-enforcement path that remains in place as detectors change.