Technische Samenvatting: AI Code Sandboxes: Een Vergelijkende Beveiligingsstudie (Deel 1)

Probleemstelling

Het artikel behandelt de kritieke uitdaging van engine-niveau isolatie voor AI-agenten die onbetrouwbare code uitvoeren. Hoewel "sandboxing" een standaard verdedigingsfamilie is in de literatuur over de beveiliging van agentic AI, is er een gebrek aan diepgaande metingen op engine-niveau die vergelijken hoe verschillende producten gastcode isoleren van de host-kernel. De urgentie wordt gedreven door onderzoek naar "gevaarlijke capaciteiten" (dangerous capability), dat aangeeft dat AI-agenten al in staat zijn tot multi-step cyberaanvallen (bijv. het voltooien van 22 van de 32 stappen van een bedrijfsnetwerkaanval) binnen huidige compute-budgetten. De studie richt zich op het T0.H2.N2 dreigmodel: een single-tenant operator die onbetrouwbare code draait op de eigen infrastructuur, waarbij de operator de infrastructuur vertrouwt maar niet de code. Het doel is om te meten hoe vijf specifieke AI-sandbox producten (arrakis, e2b, microsandbox, gvisor, daytona) het ontsnappen aan de host-kernel en informatielekken voorkomen.

Methodologie

De studie maakt gebruik van een zes-assig, cross-class vergelijkend kader dat eigenschappen meet die worden bepaald door de onderliggende engine (microVM, userspace kernel, of OCI container). De methodologie verbiedt expliciet samengestelde scores of algemene rangschikkingen, en biedt in plaats daarvan per-as ordeningen en een dreigmodel-kwalificatiematrix.

De Zes Assen:

1. Host Aanvalsoppervlak (1.1): Meet de voetafdruk van de runtime/mediator (L2) op de host-kernel (L1) via strace syscall-aantallen, seccomp filter plafonds en primitieve bereikbaarheid (14 specifieke kernel-LPE/container-escape primitieven).
2. Informatielekken (1.2): Meet welke host-identificerende gegevens (CPU, RAM, kernelversie, disk-serials) worden blootgesteld aan de gast via /proc, /sys en /dev reads.
3. Defense-in-Depth Stapelbaarheid (1.3): Evalueert of een operator aanvullende Linux-hardening (seccomp, AppArmor, user namespaces, etc.) kan stapelen bovenop de engine-defaults.
4. Publieke CVE-historie (1.4): Analyseert de laatste 24 maanden aan CVE's voor elke engine, geclassificeerd naar impact (Escape, HostLeak, HostDoS).
5. Patch Cadans (1.5): Meet de tijdsverloop tussen upstream patching en product-niveau beschikbaarheid, waarbij onderscheid wordt gemaakt tussen gecoördineerde disclosures en "silent-fix-first" modellen.
6. Upstream Fuzzing Posture (1.6): Beoordeelt de aanwezigheid van continue publieke fuzzing, in-tree harnesses en per-CVE attributie aan fuzzer-ontdekking.

Experimentele Opstelling:

• Host: Enkele Hetzner bare-metal node (Ubuntu 24.04, Kernel 6.8.0).
• Producten: Vijf producten gemapt naar drie engine-klassen:
  • MicroVMs: arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun).
  • Userspace Kernel: gvisor (runsc).
  • OCI Container: daytona (runc via Docker-CE).
• Verificatie: Gebruikt "probe" tests (pass/fail), "measurement" (syscall aantallen) en "desk research" (CVE/Fuzzing analyse).

Belangrijkste Bijdragen en Bevindingen

1. Engine Klassen vs. Product Variantie

Hoewel engine-klassen (microVM vs. userspace kernel vs. container) duidelijk scheiden op architecturale assen (aanvalsoppervlak, lekkage), doen producten binnen dezelfde klasse dat niet. Product-specifieke configuraties en pin-policies zijn vaak significante differentiators vergeleken met de engine-klasse zelf.

• Voorbeeld: arrakis (microVM) heeft een "frozen" patch beleid (471+ dagen), terwijl daytona (container) "current" is op patches, wat de verwachte beveiligingshiërarchie op basis van isolatieklasse alleen omkeert.

2. Aanvalsoppervlak en Primitieve Bereikbaarheid

• gVisor heeft het kleinste aanvalsoppervlak (5/14 bereikbare primitieven) vanwege de userspace kernel die syscalls onderschept.
• Firecracker (e2b) heeft het kleinste seccomp plafond (55 syscalls) maar lijdt nog steeds onder 2 nieuwe Escape-class CVE's in de 2026 window, wat bewijst dat een klein oppervlak niet nul bugs garandeert in de geëxperimenteerde paden.
• arrakis legt een live /dev/kvm interface bloot aan de gast, wat geneste virtualisatie mogelijk maakt zonder privilege escalatie, wat het kernel-LPE oppervlak aanzienlijk vergroot vergeleken met andere microVM's.

3. Dominantie van Patch Propagatie

De studie vindt dat product-zijde pin policy de dominante operator-georiënteerde variabele is, wat aggregeert tot ≈0 dagen vertraging voor gecoördineerde disclosures upstream, maar varieert van 0 tot 471+ dagen downstream.

• arrakis en e2b (self-hosted) zijn "frozen" op oudere engine versies, waardoor ze niet gepatcht zijn tegen recente kritieke CVE's (bijv. CVE-2026-45782 voor arrakis, CVE-2026-5747 voor e2b).
• gVisor volgt een "silent-fix-first" model waarbij fixes maanden voordat de CVE toewijzing verschijnen, wat resulteert in negatieve lag (operators ontvangen fixes vóór publieke disclosure).

4. Fuzzing Posture en "Ongemeten" Risico's

• gVisor is de enige engine met een continue publieke fuzzer (syzkaller) en in-tree harnesses.
• Firecracker en libkrun hebben geen upstream fuzzing infrastructuur.
• Cruciale Bevinding: De combinatie van "MicroVM class" (sterke isolatie) en "Continuous Public Fuzzer" (sterke residual-bug detectie) is onbezet in deze set.
• libkrun (microsandbox) is structureel ongemeten: het heeft 0 gepubliceerde CVE's en geen upstream fuzzer. Het artikel betoogt dat "0 CVE's" hier een afwezigheid van signaal is, en geen bewijs van soundness, wat een "structureel ongemeten" risicoprofiel creëert.

5. Informatielekken

• MicroVMs lekken over het algemeen 0–1 host identificatoren (configureerbare CPU strings).
• gVisor lekt 2 identificatoren (totaal RAM, BIOS product) door implementatiekloven in zijn synthetische /proc.
• daytona lekt 10 identificatoren, inclus_ief disk-serials en volledige kernel signaturen, door de gedeelde-kernel architectuur.

Betekenis en Claims

Het artikel claimt dat geen algemene rangschikking mogelijk of voorgesteld is. In plaats daarvan biedt het een dreigmodel-kwalificatiematrix die operators in staat stelt vier specifieke subvragen te beantwoorden:

1. Escape Weerstand: Kan de code ontsnappen aan de host-kernel?
2. Reconnaissance Weerstand: Wat kan de code leren over de host?
3. Hardening Compatibiliteit: Kan de operator Linux-hardening lagen toevoegen?
4. Patch Propagatie: Ontvangt de operator fixes tijdig?

Belangrijkste Conclusies:

• Trade-offs zijn onvermijdelijk: De sterkste isolatieklasse (microVM) correleert niet automatisch met de sterkste residual-bug posture (fuzzing). Operators moeten kiezen tussen "sterkste isolatie" (microVM's) en "ondiepste residuals" (gVisor).
• Product defaults matter: Engine-niveau sterktes (bijv. Cloud Hypervisor's per-thread seccomp) kunnen worden genegeerd door product-niveau defaults (bijv. arrakis's geneste-KVM exposure of e2b's frozen pin).
• De "Ongemeten" Kloof: De afwezigheid van CVE's en fuzzing in libkrun creëert een risicoprofiel dat niet als "veilig" of "onveilig" kan worden geïnterpreteerd, maar slechts als "ongemeten".
• Methodologische Verschuiving: De studie gaat verder dan eenvoudige "replay" van CVE's naar een meta-analyse van architecturale eigenschappen, patch cadans en fuzzing investering om de huidige staat van AI sandbox beveiliging te beschrijven.

Het artikel dient als een baseline voor engine-niveau meting, waarbij specifieke product-niveau configuratiekloven (zoals arrakis's geneste-KVM en daytona's Privileged: true hardcoding) worden geïdentificeerd die directe aandacht van de operator of upstream remediëring vereisen.