Een AI-agent die zijn eigen code schrijft en uitvoert, is alleen zo veilig als de omgeving waarin die code draait. In een tutorial gepubliceerd door Machine Learning Mastery laat de auteur zien hoe je die code op drie niveaus kunt isoleren: een beperkt subproces, een geharde Docker-container en een Firecracker-microVM, en vergelijkt vervolgens hun veiligheid en latentie.
Het subproces is het lichtste niveau: het is een kindproces waarvan rekentijd, geheugen en bestandsgrootte zijn beperkt, maar dat de kernel en bestanden van de hostmachine deelt. Een container voegt namespaces en control groups (cgroups) toe, maar blijft een set processen op de kernel van de host. Het artikel herinnert eraan dat in november 2025 drie kwetsbaarheden in de runc-runtime het aanvallers mogelijk maakten om uit containers te ontsnappen. Een microVM geeft elke omgeving zijn eigen kernel, achter een hypervisor, de software die virtuele machines draait.
Het systeem berust op één enkele tool, run_python, die beschikbaar wordt gesteld aan de agent. Elke code die door het model wordt geproduceerd, gaat door een ‘sandbox’-object met een methode run(code), zodat het wijzigen van het isolatieniveau de agent niet verandert. De tutorial vereist Python 3.10 of nieuwer, een Linux-systeem of WSL voor het subprocesniveau, Docker voor de container, en een account en een E2B API-sleutel voor de microVM. Een Anthropic API-sleutel is nuttig voor de agent, maar kan worden vermeden voor tests.
Zes identieke aanvallen tegen elk niveau
Om de drie niveaus te vergelijken, worden dezelfde zes vijandige programma’s uitgevoerd: een oneindige lus, een toewijzing van 512 MB geheugen, een ‘fork flood’ van 200 processen, het schrijven van een 50 MB bestand, het lezen van een nepbestand met inloggegevens en verbinding maken met een nep interne service. Een aanval wordt als geblokkeerd beschouwd wanneer het herkenningswoord niet in de uitvoer verschijnt, of, voor de oneindige lus, wanneer de uitvoering verloopt.
Op het subprocesniveau, uitgevoerd met een standaard Linux-gebruiker, worden vier aanvallen geblokkeerd en twee slagen door. De proceslimiet geldt alleen voor een toegewezen gebruiker, waardoor de fork flood is toegestaan, en het nepbestand met inloggegevens blijft leesbaar omdat de code draait onder de identiteit van de gebruiker. De auteur concludeert hieruit dat dit niveau vooral geschikt is voor code die je vertrouwt.
Voor de Docker-container geeft de auteur aan dat, met de gekozen opties, Docker de zes aanvallen zou moeten blokkeren, aangezien de container geen netwerk heeft, zijn bestandssysteem de gebruikersbestanden niet bevat en de limieten voor geheugen, processen en schijf van toepassing zijn. In een microVM kunnen de aanvallen op geheugen, processen en schijf de limieten van de virtuele machine bereiken, maar blijven ze daarbinnen opgesloten, en het geheime bestand en de lokale service bestaan er niet.
Latentie en keuze van het niveau
Het subproces zou het snelst moeten zijn, omdat het alleen Python start. Voor de andere twee niveaus preciseert de auteur dat de gepubliceerde cijfers beweringen zijn en geen garanties: een geciteerd artikel geeft aan dat E2B in ongeveer 150 ms opstart, terwijl AWS en Docker quasi-onmiddellijke starts beschrijven voor hun microVM-producten. Het script bench.py maakt het mogelijk om, op je eigen machine, de mediaan en de langste tijd over tien uitvoeringen van een programma print(1) te meten.
De auteur raadt aan het subproces te reserveren voor vertrouwde code, zoals persoonlijke ontwikkelscripts, en de geharde container voor gevallen waarin je de host beheert en de risico’s laag zijn, met aandacht voor het up-to-date houden van runc. De microVM is noodzakelijk voor code afkomstig van meerdere gebruikers, voor alles wat geheimen betreft, en wanneer de agent zelf containers moet bouwen en uitvoeren, wat klassieke containers volgens Docker slecht aankunnen. Docker lanceerde zijn Docker Sandboxes op microVM in april 2026, en AWS biedt Lambda MicroVMs aan die hun staat tot 8 uur behouden en inactief worden onderbroken. Volgens Docker moeten bestanden, netwerkregels en geheimen door de infrastructuur worden gedefinieerd, en niet door de agent, vóór de uitvoering ervan.
