Execution-Time AI Alignment: Van System Prompt naar Safety Kernel

Ik heb een haat-liefdeverhouding met AI safety-discussies. Aan de ene kant: eindelijk nemen we het serieus. Aan de andere kant: het blijft te vaak hangen in systeemprompts, outputfilters en "we hebben een ethische commissie." Alsof je een kernreactor beveiligt met een bordje "niet aankomen."

Daarom trok deze paper meteen mijn aandacht. Seth Dobrin en Łukasz Chmiel stellen iets wat in de AI-wereld bijna heiligschennis is: alignment moet niet in het model zelf zitten, maar erbuiten. Een safety kernel die op OS-niveau afdwingt wat een agent wel en niet mag, ongeacht wat het model denkt of zegt.

Het probleem: escapable AI

De auteurs introduceren een term die ik nog niet kende maar meteen herkende: escapable AI systems. Elk AI-systeem dat genoeg controle heeft over zijn eigen runtime om beveiligingsmechanismen te omzeilen. Denk aan een agent die zijn eigen systeemprompt kan lezen, of een model dat via tool calls toegang heeft tot dezelfde processen als de guardrails die het moeten tegenhouden.

Hun stelling is glashelder: elke controle die in de address space van de agent zelf draait, is bereikbaar via inputs die de agent beïnvloeden. Prompt injection is geen bug, het is een architectuurfout.

Dit sluit naadloos aan op wat arXiv:2606.27567 vorige week al wiskundig bewees: prompt injection in shared-embedding architecturen is structureel onvermijdelijk. Dobrin en Chmiel gaan een stap verder: ze bouwen de oplossing.

Vier eigenschappen van architecturale controle

De paper definieert vier niet-onderhandelbare eigenschappen voor een autorisatiemechanisme dat écht controleert in plaats van vriendelijk vraagt:

1. Process separation, de controle draait buiten het proces van de agent. Geen gedeelde memory, geen gedeelde file descriptors.
2. Pre-action enforcement op een structureel enkel pad, elke actie gaat door één poort. Geen shortcuts, geen fallback-paden.
3. Fail-closed op zowel request- als systeemniveau, als de kernel crasht, stopt alles. Geen "even zonder check doorgaan."
4. Externally signed evidence, elke beslissing laat een cryptografisch verifieerbaar spoor achter, buiten de trust boundary van het gecontroleerde systeem.

Dit is niet "we hebben een policy engine." Dit is een architectuurprincipe. En het is precies wat de EU AI Act bedoelt met artikel 14 (human oversight) en artikel 15 (accuracy, robustness and cybersecurity) voor high-risk AI-systemen.

De Unfireable Safety Kernel

De referentie-implementatie is in Rust geschreven, een bewuste keuze. Geen garbage collector, geen runtime die je kunt corrumperen, memory safety op compilerniveau. De kernel draait als een apart proces en onderschept elke actie die een AI agent wil uitvoeren.

Wat me het meest imponeert is de verificatie. Dit is geen "we hebben het getest en het leek te werken." De fail-closed invariant is op twee niveaus machine-gecheckt:

• SMT theorem (Z3), formele verificatie van de kernlogica
• Bounded model checking (Kani), 4/4 harnesses, exhaustieve check van de productie decision function
• Byte-equivalence migration, de Python-naar-Rust migratie is geverifieerd op 1000/1000 fixtures en 17/17 adversarial klassen

De testresultaten liegen er niet om. Een escape-seeking adversary kreeg 704 pogingen op de safety-critical core, allemaal geweigerd. Geen enkele escape. Zelfs de operator kill switch (300 extra pogingen) bleef dicht. En in een aparte campagne van 6.240 autorisatie-round-trips: nul bypasses.

Waarom dit relevant is voor Nederlandse organisaties

De EU AI Act wordt niet vriendelijk. Vanaf 2 augustus 2026 gelden de transparency obligations (art. 50). High-risk systemen moeten aantoonbaar voldoen aan art. 14 (human oversight) en art. 15 (technische robuustheid). Een systeemprompt en een outputfilter zijn geen "technische robuustheid."

Voor Nederlandse overheidsorganisaties die AI agents overwegen, en dat zijn er steeds meer, is dit paper een wake-up call. BIO2 en NIS2 vereisen aantoonbare beveiliging van kritieke systemen. Een agent die zijn eigen guardrails kan omzeilen is per definitie niet aantoonbaar beveiligd.

De safety kernel-architectuur biedt een concreet antwoord op de vraag die elke CISO binnenkort krijgt: "Hoe bewijs ik dat onze AI-agent niet doet wat hij niet mag doen?" Het antwoord is niet "we hebben een systeemprompt." Het antwoord is: process separation, pre-action enforcement, fail-closed, externally verified.

De echte implicatie

Wat Dobrin en Chmiel hier doen is alignment verplaatsen van het model naar de infrastructuur. Training-time alignment (RLHF, Constitutional AI) blijft nodig, maar het is niet voldoende. Inference-time alignment (guardrails, outputfilters) is een vangnet met gaten. Execution-time alignment is de derde laag die ontbrak.

De vergelijking met OS-security dringt zich op. We accepteren al decennia dat een proces niet zomaar kernel-memory mag lezen, ongeacht hoe "goed bedoeld" het proces is. Waarom zouden we AI agents anders behandelen?

Voor wie dit is: CISO's die AI-agents moeten verantwoorden onder NIS2 of BIO2. Compliance officers die art. 15 conformity assessments voorbereiden. Architecten die verder kijken dan "we gebruiken de API van OpenAI." En iedereen die snapt dat een systeemprompt geen security control is.

---

Bron: Dobrin, S., & Chmiel, Ł. (2026). The Unfireable Safety Kernel: Execution-Time AI Alignment for AI Agents and Other Escapable AI Systems. arXiv:2606.26057. https://arxiv.org/abs/2606.26057