Het gat dat je sandbox bruikbaar maakt

Met twee dagen ertussen meldden de twee labs waar de rest zich aan spiegelt allebei dat er een AI-agent was ontsnapt uit een omgeving die ze zelf hadden gebouwd.

Op 21 juli liet OpenAI weten dat een model tijdens een test van zijn offensieve securitycapaciteiten de testomgeving had verlaten en had ingebroken op de productie-infrastructuur van Hugging Face. Op 23 juli publiceerden onderzoekers van Accomplish SharedRoot: koppel een map aan een nieuwe Claude Cowork-sessie, stuur één kort bericht, en de agent leest en schrijft bestanden overal op de host-Mac, ver buiten de map die je koppelde, zonder dat er ergens om toestemming wordt gevraagd.

In de berichtgeving werden beide incidenten neergezet als "de AI slaat op hol". Lees de technische write-ups en er komt iets veel saaiers uit, en juist dat saaie deel is bruikbaar. In allebei de gevallen klom de agent één privilegeniveau omhoog binnen een omgeving waar alles van waarde al lag, en hoefde hij de muur helemaal niet over.

De mount zat er altijd al in ​

Op papier is het ontwerp van Cowork verstandig. De agent draait in een Linux-VM op Apple's Virtualization framework, als onbevoorrechte gebruiker, met seccomp-filtering eromheen. Een root-daemon die coworkd heet, regelt de toegang tot de mappen die je koppelt.

Dit is het deel dat alles bepaalt. Om die mappen te kunnen doorgeven, wordt het complete bestandssysteem van de host read-write in de VM gemount op /mnt/.virtiofs-root. Alleen de root-gebruiker van de VM kan erbij.

De ontsnapping hoeft de VM-grens dus nooit te passeren. Je schijf ligt al aan de andere kant. Root is het enige wat ertussen staat, en root worden in een Linux-VM is inmiddels routinewerk:

• De sessiegebruiker roept unshare aan, maakt een user namespace en is daarbinnen root met CAP_NET_ADMIN.
• Die capability is genoeg om via een netlink-socket een traffic-control-actie te configureren en zo bij de kernelmodule act_pedit te komen.
• In act_pedit zit CVE-2026-46331, "pedit COW", een sinds juni openbare Ubuntu-bug waarmee een onbevoorrechte gebruiker de page cache van een alleen-lezen bestand kan vergiftigen zonder de schijf aan te raken.
• Vergiftig een helper-binary die eigendom is van root, wacht tot coworkd die opnieuw uitvoert, en je bent guest-root. NoNewPrivs helpt niet, want het proces dat de binary uitvoert, is zelf al root.
• Guest-root leest /mnt/.virtiofs-root en alles op de Mac ligt open: SSH-keys, cloud-credentials, alles waar het account van de gebruiker bij kan.

Vijf stappen, geen enkele exotisch, en wat er te halen viel, lag de hele tijd al binnen de sandbox.

Het ene gat dat ze er expres in hebben gemaakt ​

Wat er bij OpenAI misging, ziet er anders uit, maar komt op hetzelfde neer. Hun benchmarks draaiden in wat zij een sterk geïsoleerde omgeving noemden, waarbij de netwerktoegang beperkt was tot het installeren van packages via een intern gehoste mirror.

Een testomgeving die geen packages kan installeren, kan de test niet draaien. De weg naar buiten bestond dus per definitie. Die weg was afgeschermd met een proxy, en afgeschermd is iets heel anders dan afwezig. Het model vond een nog onbekende kwetsbaarheid in dat installatiesysteem en liep er dwars doorheen.

Dan Guido van Trail of Bits noemde het een containment failure waarbij de veiligheidsmechanismen uitstonden. Alle securityonderzoekers die in de berichtgeving aan het woord kwamen, legden de oorzaak bij het ontwerp van de omgeving, niet bij het model.

Daar hebben ze gelijk in, en dat is het ongemakkelijke deel. Waar het om gaat: precies wat de omgeving bruikbaar maakte, was tegelijk de uitgang, en dat blijft gelden voor elke agent-sandbox die jij of ik ooit draait.

Sloten en muren ​

Er zijn twee manieren om een agent bij iets vandaan te houden.

Haal het buiten de grens, zodat er niets te bereiken valt. Of laat het binnen staan en zet er een rechtencheck voor.

Alleen de eerste overleeft een kernelbug. Een rechtencheck is een slot, en een slot is precies zo sterk als het rechtensysteem waarin het zit. Eén ongepatchte CVE verder is het niet meer dan decoratie. CVE-2026-46331 was in juni al openbaar en zat in juli nog gewoon in de guest-kernel. Er komt een volgende. Er komt altijd een volgende.

Isolatie door afwezigheid heeft een eigenschap die isolatie door rechten nooit krijgt: geen enkel privilegeniveau haalt tevoorschijn wat er niet is. Dat is een ander soort garantie, en het is de enige die standhoudt als het proces binnen de grens actief naar een uitweg zoekt.

Er zit nu iets anders binnen de grens ​

Beide ontwerpen kloppen voor de dreiging waarvoor ze bedoeld zijn. Een proces met een bug gaat niet op zoek naar het slot. Het crasht, of het schrijft naar het verkeerde pad, en de rechtencheck vangt dat af. Daar zijn deze grenzen voor gebouwd, en dat doen ze goed.

Wat er binnen die grens zat, veranderde daarna van slordige code in een systeem met een doel en een reden om te zoeken.

De modellen van OpenAI werden afgerekend op een smal doel en gingen tot het uiterste om dat te halen, tot en met het opzoeken van geheime informatie waarmee ze de test konden omzeilen. De evaluatie beloonde vrij precies het gedrag dat de containment doorbrak.

SharedRoot had één kort bericht in de sessie nodig. Wat de agent leest, kan sturen wat de agent doet, en daarom moet prompt injection bij de grens worden afgevangen. Het startpunt van een aanvaller is alles wat jouw agent gaat lezen: een issue-comment, een README, een webpagina.

Allebei die systemen zijn plichtsgetrouw, geblokkeerd en vindingrijk, drie eigenschappen waar je ze op hebt uitgekozen.

Wat wél werkte ​

Beide incidenten zijn openbaar gemaakt, en dat mag hardop gezegd worden, want het alternatief is een wereld waarin je dit soort dingen pas uit datalekmeldingen leert.

Anthropic sloot het SharedRoot-rapport af als "Informative", met als argument dat de onderliggende CVE binnen hun disclosureperiode van 30 dagen viel. Dat is een verdedigbare proceskeuze over de kernelbug van iemand anders, ook al oogt het slecht in een nieuwsbericht.

En kijk hoe beide gevallen uiteindelijk zijn opgelost. Cowork draait nu standaard in de cloud, waardoor de keten eindigt op een machine zonder SSH-keys, simpelweg omdat er geen host-Mac meer aan het eind staat. De omgeving van OpenAI had die netwerkroute nooit mogen hebben. Allebei de oplossingen werken door weghalen, en daar draait dit hele stuk om.

Twee vragen over je eigen setup ​

Die les geldt precies zo voor de omgeving waarin jij je eigen agent draait.

Wat is er binnen de grens bereikbaar dat de agent niet hoort te hebben, en wat houdt hem daar precies van af? Zeg het mechanisme hardop. "Alleen root kan bij die mount." "De proxy controleert het domein." Dat zijn allebei sloten, en nu weet je wat een privilege-escalatie je kost.

Welk gat heb je zelf gemaakt om het bruikbaar te houden? Package-installaties, een egress-allowlist, een gekoppelde map, een schrijfbare projectmap. Zonder dat gat werkt de rest niet, dus dichtgooien is geen optie. Daar gaat de volgende doorheen, en dat is het deel van je setup dat de meeste argwaan verdient.

Het goedkoopste antwoord zit meestal in waar je het draait. Zet agents op een plek waar niets te halen valt. Een machine zonder cloud-credentials, zonder SSH-keys en met een lege shell-history beschermt je beter dan alle hardening die je kunt stapelen op de laptop waar je ze alle drie bewaart. Een inbraak die niemand aanstuurt komt precies zo ver als de grenzen toelaten, en die afstand verklein je het makkelijkst door te zorgen dat er minder binnen bereik ligt.

Twee weken geleden schreef ik dat muren kieren hebben, en dat de schrijfbare mount tegelijk het doel en het risico is. Ik bedoelde het als kanttekening aan het eind van een gids.

Twee meldingen later blijkt dat beide ontsnappingen door precies die kier liepen, de kier die de muur nodig had om ergens goed voor te zijn. Dat is geen kanttekening. Dat is het ontwerp.