Oude wijn, nieuwe agent. Waarom de VM ineens weer relevant is

Claude Code, Codex, OpenCode, mijn agents draaien tegenwoordig gewoon zelf shell-commando's, passen bestanden aan, installeren pakketten en draaien tests. Vaak met exact dezelfde rechten als ikzelf op mijn laptop. Handig, maar de eerste keer dat ik zo'n agent losliet, vertrouwde ik het toch niet helemaal. Die agent kan natuurlijk vanalles op mijn laptop uitvoeren en het gaat zo snel dat alles zelf in het oog houden wel heel moeilijk wordt.

Afgelopen zomer heeft Apple zijn eigen container technologie, Apple Containers, naar versie 1.0 gebracht. Wat me opviel was hoe bewust Apple een specifieke architectuur keuze heeft gemaakt om precies dit soort scenario's veiliger te maken. Die keuze bleek breder te gelden dan alleen macOS: op Linux, en met wat kunst- en vliegwerk ook op Windows, kom je op exact hetzelfde basisprincipe uit: isolatie per container via zijn eigen, lichtgewicht virtuele machine, een microVM. Hieronder leg ik eerst uit waarom dat nodig is en daarna hoe je het per platform concreet voor elkaar krijgt.

Containers isoleren minder dan je denkt

Traditionele containers, of dat nu Docker is of iets anders, draaien allemaal op dezelfde Linux-kernel. Namespaces en cgroups zorgen voor een soort "zachte" isolatie. Elke container denkt dat hij zijn eigen bestandssysteem en proces-ruimte heeft maar onder de motorkap delen alle containers op die host gewoon dezelfde kernel.

Voor een gewone webapp is dat meestal prima. Maar bij een AI-agent die zelf code genereert én uitvoert, ligt dat anders. Eén kernel-kwetsbaarheid of één container-escape en kwaadaardige (of gewoon buggy) code kan zich lateraal verspreiden naar andere containers en uiteindelijk naar je host. Op macOS en Windows draait Docker Desktop bovendien al je containers in één gedeelde Linux-VM. Die VM beschermt je besturingssysteem prima maar binnen die VM delen al je containers nog steeds diezelfde ene kernel.

Elke container zijn eigen microVM

Het alternatief dat ik nu op meerdere plekken tegelijk zie opduiken, is een radicaal ander uitgangspunt. In plaats van één grote gedeelde VM met tien containers erin, krijgt elke container zijn eigen lichtgewicht VM met zijn eigen dedicated kernel. Hardware-afgedwongen isolatie, zowel tussen containers onderling als tussen elke container en de host.

Dat levert meteen twee extra's op:

Deze microVM's starten in minder dan een seconde. Geen dynamische libraries, geen shell, een uitgekleed init-systeem: er valt simpelweg weinig op te starten. Het is snel.
Je hoeft geen grote VM vooraf te dimensioneren "voor het geval dat" je tien containers tegelijk nodig hebt. Je verbruikt pas resources zodra je écht een container, en zijn VM, opstart. Redelijk efficient dus.

En dat maakt het niet alleen veiliger maar ook precies bruikbaar voor het scenario waar ik naar op zoek was. Een AI-agent zijn eigen wegwerp-omgeving geven, met alleen het project dat hij nodig heeft erin gemount en die omgeving na afloop gewoon weggooien.

Hoe krijg je dit nu concreet voor elkaar, per platform?

macOS: Apple lost het meteen goed op

Apple heeft dit model niet als bijzaak toegevoegd maar vanaf de grond af aan zo gebouwd. De Containerization-package en de container-CLI draaien bovenop Apple's eigen Virtualization Framework, Hypervisor Framework en vmnet, volledig native op Apple Silicon. Elke container krijgt een eigen, geoptimaliseerde kernel en een minimaal init-systeem, zonder ook maar iets te delen met andere containers.

Het patroon voor een AI-sandbox is verrassend simpel en ik zag het als één van de eerste use-cases voorbijkomen in een demo. Start een gewone Apple-container, mount daarin alleen de projectmap als workspace zodat de container verder niets anders op de Mac ziet, geef de API-key mee als environment variable, installeer de coding agent (in dit geval Claude Code) en zet hem aan het werk. Vijf minuten later had die agent zelfstandig een health check toegevoegd, gebuild, getest, en draaide de aangepaste server gewoon weer.

Eén ding wil ik er wel even uitlichten. De VM-isolatie beschermt je Mac, je kernel, je credentials, je andere projecten. Ze beschermt niet de gemounte projectmap zelf. De agent heeft daar gewoon volledige lees- en schrijftoegang toe. Je vangnet hiervoor is niet technisch, het is doodgewoon Git. Als de agent iets verpest, zet je gewoon een eerdere versie terug.

Nog een leuk detail. Containers hebben geen toegang tot de GPU of de Neural Engine. Inference draai je dus lokaal op macOS, waar je wél bij de hardware kan, terwijl alles wat die output aan het doen is (code, shell-commando's, tool calls) in de sandbox gebeurt. Een nette scheiding tussen "denken" en "doen".

Linux: Podman met de krun-runtime

Op Linux bestaat exact hetzelfde idee, alleen heet het anders en moet je er zelf even naar op zoek. Podman kan een container draaien via de krun OCI-runtime, gebouwd op crun plus de libkrun-library, die elke container in zijn eigen KVM-gebaseerde microVM start in plaats van de gedeelde hostkernel te gebruiken. Concreet: podman run --runtime krun ... in plaats van de standaard runc/crun.

Hetzelfde sandbox-patroon als op macOS werkt hier één op één: agent installeren in het image, alleen de projectmap mounten, credentials als environment variables meegeven.

Let wel op, in het commando staat expliciet --runtime krun. Dit is niet het standaardgedrag van Podman. Je moet hier bewust voor kiezen, anders val je gewoon terug op het gedeelde-kernelmodel zonder dat je het doorhebt. Er bestaat ook een langer gevestigd alternatief met hetzelfde doel namelijk Kata Containers, dat via containerd, CRI-O en Kubernetes RuntimeClasses werkt en al sinds 2017 hetzelfde "VM per container"-idee implementeert. Dat is vooral populair in productie-Kubernetes-clusters.

Windows: hier wringt de schoen

En dan Windows. De voor de hand liggende aanname is: "installeer gewoon Ubuntu via WSL en je bent klaar." Klopt niet. WSL2 draait namelijk niet één VM per distributie, wat ik zelf ook lang dacht. Er is precies één gedeelde utility-VM voor de hele Windows-machine, ongeacht hoeveel distributies je installeert. Elke distributie krijgt enkel zijn eigen Linux-namespaces (PID, mount, user, cgroup), maar deelt kernel, CPU, geheugen en netwerk-namespace met alle andere distributies op diezelfde machine.

Sterker nog: draai je Docker Desktop met de WSL2-backend, dan maakt gebruik van diezelfde ene gedeelde VM. Je bent dus precies terug bij het probleem dat we net probeerden op te lossen. Alles op die machine deelt uiteindelijk één kernel.

Windows heeft wél een echte VM-per-container-optie, namelijk Hyper-V isolatiemodus. Maar die is bedoeld voor Windows-containers, niet voor de Linux-gebaseerde agent-workloads waar we het hier over hebben. Voor ons scenario levert dat dus niets op.

Ik heb voor Windows nog niet direct een ingebouwde, gratis manier gevonden om hetzelfde microVM-per-container-model te krijgen voor Linux-agentworkloads. Hiervoor moet je naar een platformoverstijgende oplossing kijken: Docker Sandboxes.

Docker Sandboxes als vangnet voor Windows (en de rest)

Docker heeft specifiek voor dit scenario een eigen, custom VMM gebouwd, bewust niet Firecracker (de microVM-technologie achter AWS Lambda/Fargate en één van de opties binnen Kata Containers), omdat Firecracker alleen Linux/KVM ondersteunt. Docker wilde dat sandboxing identiek werkt op macOS, Windows én Linux.

Elke Docker Sandbox is een wegwerp-microVM met:

een eigen, geïsoleerde bestandsstructuur,
een eigen private Docker-daemon, waardoor de agent zelf weer containers kan starten binnen zijn sandbox,
een geïsoleerde netwerkstack met een instelbaar beleid: open, gebalanceerd, of volledig afgesloten,
herbruikbare configuraties, zogenoemde Sandbox Kits: YAML-bestanden met tools, environment variables, credentials, toegestane domeinen en opstartcommando's.

Dit is een jong en snel veranderend product, de CLI is recent al hernoemd, dus behandel exacte commando's als een leidraad en check zelf de actuele Docker-documentatie. En architecturaal zit het net iets anders in elkaar dan de andere drie. Het is isolatie per agent-werkruimte, niet per losse container. Binnen die ene sandbox-VM kunnen weer meerdere containers draaien die gewoon die ene kernel delen, precies het patroon waar we op macOS en Linux juist omheen probeerden te werken, maar dan één laag dieper.

Samenvattend overzicht

Platform	Native microVM-per-container aanpak	Opmerking
macOS	Apple Containers	Aparte installatie, vereist Apple Silicon + macOS 26
Linux	Podman + `krun`, of Kata Containers	Moet je bewust activeren, niet de standaardinstelling
Windows	(geen native optie voor Linux-workloads)	WSL2 deelt altijd één kernel, Hyper-V-isolatie geldt alleen voor Windows-containers
Cross-platform	Docker Sandboxes	Eigen VMM, werkt overal, maar nog een jong product

De les die op elk platform hetzelfde blijft

Isolatie via een (micro)VM beschermt je host. Je kernel, je credentials, je andere projecten. Ze beschermt niet de map die je in de sandbox mount, die blijft volledig toegankelijk voor wat er binnen draait. Welk platform of welke tool je ook kiest, twee regels blijven overeind:

Mount alleen de map die de agent daadwerkelijk nodig heeft, niets meer en niets minder.
Gebruik Git als je echte vangnet tegen een agent die de plank misslaat.

Wat me vooral opvalt: de aanpak verschilt flink per platform maar het onderliggende idee is overal hetzelfde. Een AI-agent zijn eigen kernel geven, zodat een fout van de agent een fout blijft en geen ramp wordt.

Welke agent-workflow draai jij momenteel en op welk platform loop je tegen isolatie aan? Ik denk graag mee, dus neem gerust contact met ons op.

Bronnen

Apple, apple/container — de officiële repository van de container CLI.
Apple, apple/containerization — de Swift-package die de VM-per-container aanpak onder de motorkap implementeert.
Containers-project, containers/libkrun — de library achter de krun OCI-runtime die Podman gebruikt voor microVM-isolatie.
Docker, Get started with Docker Sandboxes — officiële documentatie over installatie en eerste gebruik.