LMSM: het Linux Security Modules-principe toepassen op LLM-serving
Large language models worden steeds vaker uitgerold met gelaagde verdedigingen, maar kwaadaardige prompts kunnen die nog steeds omzeilen. Interpretability-methoden kunnen model-interne signalen langs het generatiepad blootleggen die handhaving zouden kunnen informeren, maar die signalen zijn op zichzelf geen security controls. De structurele uitdaging: elke deployment koppelt elk signaal aan zijn eigen calibratie, policy-logica en interventiecode, waardoor elk nieuw artefact integratiewerk creëert in plaats van een gedeelde verdediging te versterken.
Dat is het probleem dat het Language Model Security Modules (LMSM) framework aanpakt (arXiv:2608.25697). Het adapteert de scheiding achter Linux Security Modules (LSM) naar LLM-serving.
Formeel: de scheiding tussen mediation en policy
De kern van LSM is een scheiding tussen twee verantwoordelijkheden die vaak ten onrechte worden samengevoegd. In Linux definieert LSM:
Mediation: elke systeemcall loopt door een uniform security hook-punt
Policy: welke module welke beslissing neemt op dat punt
De cruciale eigenschap is dat deze twee onafhankelijk evolueerbaar zijn. Je kunt de mediation-laag (waar wordt gecheckt) veranderen zonder de policy te raken, en de policy (wat wordt gecheckt) zonder de mediation te herbouwen.
LMSM past dit principe toe op LLM-serving. Laat een generatiepad G bestaan uit een reeks output-verklaringen o₁, o₂, ..., oₖ die geproduceerd worden tijdens het genereren. Elk signaal sᵢ uit een interpretability-backend is een kandidaat-evidence:
sᵢ ∈ Evidence(S)
waarbij S de set van beschikbare security-backends is (SAE, transcoders, dense probes). LMSM scheidt:
- Backend: levert gekalibreerde evidence sᵢ over trusted per-request context
- Policy: een versiebeheerde set actieve regels R die over de evidence evalueert
- Gate: een apart component dat buffered output-release autoriseert
Formeel is de release-beslissing een functie van de policy-evaluatie:
Release = Gate( Policy( R, Context(c), Evidence(S) ) )
De sleutel is dat Backend, Policy en Gate onafhankelijk kunnen worden gewijzigd zonder request-handling te herbouwen. Dit leidt tot de centrale stelling.
H1, de separation-hypothese. Het scheiden van mediation correctness van policy effectiveness in LLM-serving maakt het mogelijk om security-backends, regels en schema's te wijzigen zonder request-handling of enforcement te herbouwen, en dit versterkt de gedeelde verdediging.
H1 is falsifieerbaar. De hypothese faalt wanneer het toevoegen van een nieuw interpretability-artefact een wijziging in de request-handling of enforcement-laag vereist, ondanks de LMSM-scheiding. Het prototype toont dat SAE-, transcoder- en dense-probe-deployments op hetzelfde substraat draaien zonder request-handling-wijziging, wat H1 ondersteunt.
Het prototype en de resultaten
De onderzoekers toonden de scheiding in de praktijk met Hugging Face Transformers en continu gebatchte vLLM. Hetzelfde substraat host:
- Artefact-backed sparse autoencoders (SAE)
- Transcoder-deployments
- Task-fitted dense probes
Het systeem behoudt request-specifieke beslissingen onder scheduler-churn en handhaaft en componeert selectief meerdere regels per request. Op Qwen3-4B reduceert LMSM-Checkpoint de HarmBench attack success rate van 39,20% naar 3,32%:
| Metriek | Zonder LMSM | Met LMSM-Checkpoint |
|---|---|---|
| HarmBench attack success rate | 39,20% | 3,32% |
| XSTest false refusals | 2,40% | 4,40% |
| Throughput (32 actieve sequences) | 100% | 98,14% |
De trade-off is de kern: de attack success rate daalt met 91,5% (van 39,20% naar 3,32%), maar false refusals stijgen van 2,40% naar 4,40%. Die stijging is klein maar materieel voor organisaties die legitieme prompts niet willen blokkeren.
De epistemische dimensie: evidence is geen control
Het paper maakt een methodologisch belangrijk onderscheid dat vaak wordt verwaarloosd: interpretability-signalen zijn evidence, geen security controls. Een SAE-activatie of dense-probe-score kan een policy informeren, maar de policy en de gate moeten de enforcement leveren.
Dit is dezelfde epistemische discipline als in onze governance-doctrine: een observatie is niet hetzelfde als een handhaving. Een signaal dat een aanval suggereert maar geen gate-trigger, is telemetry, geen defensie. LMSM expliciteert dit door de gate als een apart component te modelleren.
Wat dit betekent voor Nederlandse organisaties
Voor ministeries en gemeenten die LLM-gebaseerde chatbots of documentverwerking uitrollen, is dit een architectuurpatroon dat direct vertaalbaar is naar een security baseline. NIS2/Cyberbeveiligingswet en BIO2 eisen systematische beveiliging van AI-infrastructuur. EU AI Act Artikel 15 eist robuustheid en cybersecurity voor high-risk systemen.
Organisaties die LLM's uitrollen met alleen input-filtering of weight-level alignment missen systematische dreigingscoverage. De supply chain van LLM-serving (prompts, tool calls, interpretability signals) is onbelicht in de meeste BIO2-assessments. LMSM biedt een pad om interpretability-onderzoek een gemeenschappelijke weg naar runtime-enforcement te geven.
Een minimale gate-set voor LLM-security baseline
Voor organisaties die LMSM-achtige architectuur overwegen, stellen we een gate-set voor:
| Gate | Te bewijzen eigenschap |
|---|---|
| G1, Backend-inkoppeling | Elk interpretability-signaal is gekoppeld aan een expliciete policy-regel, niet aan ad-hoc code |
| G2, Policy-versiebeheer | Security-rules zijn versiebeheerd en herleidbaar per request |
| G3, Gate-scheiding | Enforcement is een apart component, niet verweven met request-handling |
| G4, Per-request evidence | Elke release-beslissing is reproduceerbaar met de gebruikte evidence |
| G5, Trade-off meting | False refusal stijging wordt gemeten en afgewogen tegen security-winst |
Conclusie
LMSM is geen kant-en-klaar product, maar een architectuurprincipe: scheid de mediation van de policy, versiebeheer de security rules, en leg per-request evidence vast. Voor organisaties die LLM's in productie brengen onder NIS2/BIO2, is dat een waardevol referentiepatroon voor een systematische security baseline.
De H1-hypothese, dat scheiding de gedeelde verdediging versterkt, is de kern. Zonder die scheiding is elk nieuw interpretability-artefact een nieuwe integratielast in plaats van een versterking van de gezamenlijke defensie.
Beperkingen
De resultaten zijn gebaseerd op een prototype met specifieke modellen (Qwen3-4B) en benchmarks (HarmBench, XSTest). De generaliseerbaarheid naar andere modellen en productie-workloads vereist verdere validatie. De false-refusal stijging (2,40% naar 4,40%) is een trade-off die organisaties moeten wegen tegen de security-winst. H1 is ondersteund door één prototype; bredere validatie over meerdere model-families is nodig.
Bronnen
- Zhang, Ruan, Fang, Zhang, Chua, Liang, LMSM: LLM Security Framework Inspired by Linux Security Modules, arXiv:2608.25697, ingediend 26 aug 2026.
LMSM: het Linux Security Modules-principe toepassen op LLM-serving
Dit artikel is exclusief beschikbaar voor nieuwsbrief-abonnees. Schrijf je in voor toegang tot 880+ artikelen.
Geen spam. Uitschrijven op elk moment.
AI & Security Intelligence
Wekelijkse nieuwsbrief met AI updates, security alerts en compliance inzichten, direct in uw inbox.
Security & AI Operating Model
Advisory met executiekracht
Van BIO2 en NIS2 tot EU AI Act, embedded in uw operating model, niet als extern project. Maandelijks opzegbaar, met assessments als bewijsvoering.