Agent sandbox (AI)

Wat is een agent sandbox?

Een agent sandbox is een afgeschermde omgeving waarin een AI-agent de commando's draait die hij zelf bedacht heeft. Binnen die omgeving mag hij bestanden maken, pakketten installeren, scripts uitvoeren en API's aanspreken. Daarbuiten blijven je laptop, je netwerkschijven en je productiedatabank buiten bereik.

Het woord sandbox bestond al lang voor AI-agents en betekent bij de meeste teams iets anders: een kopie van een omgeving om in te experimenteren, een ontwikkelomgeving naast test en productie. Die sandbox bestaat zodat mensen iets kunnen proberen zonder het live systeem plat te leggen. Een agent sandbox bestaat om een andere reden. De code die erin draait, is een seconde geleden door een model geschreven op basis van tekst die uit een klantenmail, een webpagina of een opmerking bij een pull request kan komen, en niemand heeft ze gelezen voor ze uitgevoerd werd.

De vraag is dus niet of je veilig in deze omgeving kan experimenteren. De vraag is: als dit commando kwaadaardig blijkt, hoe ver geraakt het dan?

Wat schermt de sandbox precies af?

Twee grenzen doen het werk, en ze moeten allebei standhouden.

Het bestandssysteem. De agent krijgt schrijfrechten in de projectmap waarin hij werkt en in een tijdelijke map, meer niet. De sandbox van Claude Code werkt zo: standaard mag een commando enkel schrijven in de werkmap en de tijdelijke sessiemap, en niet aan je shell-configuratie of aan systeembestanden. Lezen ligt anders. Standaard mag zo'n commando de rest van je machine wel uitlezen, inclusief bestanden als ~/.aws/credentials en ~/.ssh/. Die afschermen is een aparte instelling, geen automatisch gevolg van de sandbox.

Het netwerk. Uitgaand verkeer loopt via een proxy die enkel goedgekeurde hosts doorlaat. De Codex CLI van OpenAI zit aan de strenge kant: in de standaardmodus workspace-write mag de agent wel binnen de werkmap schrijven, maar staat netwerktoegang uit tot je ze zelf aanzet. Claude Code laat vooraf geen enkel domein toe en vraagt de eerste keer dat een commando een nieuw domein nodig heeft.

Het besturingssysteem legt die grenzen op, niet de agent zelf. Daar zit de hele waarde. Claude Code en Codex bouwen allebei op Seatbelt, het sandboxkader dat in macOS ingebakken zit, en op bubblewrap onder Linux en WSL2. Omdat de kernel het afdwingt, geldt de grens ook voor elk onderliggend proces dat het commando opstart, en geldt ze ongeacht wat het model dacht te doen.

Eén helft alleen brengt je nergens. Anthropic schrijft het zelf in de documentatie: zonder netwerkafscherming kan een gecompromitteerde agent gevoelige bestanden zoals SSH-sleutels naar buiten sturen, en zonder afscherming van het bestandssysteem kan hij systeembestanden aanpassen om alsnog aan het netwerk te geraken.

Het verschil met een goedkeuringslaag

De meeste agenttools hebben allebei, en ze lopen makkelijk door elkaar omdat ze allebei aanvoelen als een beveiligingsinstelling.

Een goedkeuringslaag beslist of een actie mag draaien. Ze zit voor de tool-call, leest het commando en laat het toe, blokkeert het, of vraagt het aan jou. Codex noemt dat zijn approval policy, met modi die gaan van vragen zodra er iets gewijzigd wordt tot helemaal niets meer vragen. Hier zit ook human-in-the-loop.

Een sandbox beslist waar een actie bij kan zodra ze draait. Die heeft geen mening over de bedoeling. Een commando dat om perfect goede redenen goedgekeurd werd, kan nog altijd niet buiten de werkmap schrijven.

Het verschil wordt zichtbaar op het moment dat de goedkeuringslaag zich vergist. Goedkeuring gebeurt op basis van de tekst van het commando, of door een model dat die tekst beoordeelt, dus een commando dat meer doet dan zijn naam laat vermoeden kan erdoor glippen. De sandbox trekt zich van die naam niets aan. Daarom stapel je de twee: goedkeuring vangt de zichtbaar slechte beslissingen vooraf af, de sandbox begrenst wat er toch door raakt.

Dat verklaart ook een regel die in de documentatie van zowat elke leverancier terugkomt. Zet je de vragen uit en laat je een agent onbewaakt werken, dan is de afscherming het enige dat je machine nog beschermt.

Waarom prompt injection hier het verschil maakt

Een agent sandbox oogt als gemak. Je keurt minder commando's goed, het werk schiet op. Dat het meer is dan gemak, komt door prompt injection.

Een agent leest voortdurend tekst die hij niet kan vertrouwen: webpagina's, tickets, issues in een repository, PDF's, output van andere systemen. In elk van die bronnen kunnen instructies zitten die op het model gericht zijn en niet op jou. Een model heeft geen betrouwbare manier om instructies van gegevens te onderscheiden, dus ga ervan uit dat er vroeg of laat een kwaadaardige instructie binnenkomt en opgevolgd wordt.

Vanaf dat je daarvan uitgaat, is de sandbox geen kwestie van netjes werken meer. Ze bepaalt of een geslaagde injectie neerkomt op een rommelbestand in een tijdelijke map, of op een kopie van je SSH-sleutel die bij iemand anders op een server staat. OpenAI zet de waarschuwing niet toevallig naast de netwerkinstelling: wie netwerktoegang of zoeken op het web aanzet, riskeert dat prompt injection de agent instructies laat ophalen en uitvoeren die van een aanvaller komen.

En dan het stuk dat voor een datateam het zwaarst weegt, want daar helpt afscherming op zich niet tegen. Staat de connectiestring van je productiedatabank in een omgevingsvariabele van het agentproces, dan is de afscherming decoratie. De agent hoeft niet uit de sandbox te breken. Alles wat hij nodig heeft om schade te doen, zit mee in de sandbox, en de lijst met toegelaten domeinen bevat waarschijnlijk net die datawarehouse waar hij zou moeten kunnen aan.

Daarom is het beheer van inloggegevens een aparte maatregel en geen bijproduct van de sandbox. Claude Code kan omgevingsvariabelen leegmaken voor elk afgeschermd commando, of ze maskeren: het commando ziet een vervangwaarde en de proxy zet er de echte waarde in, enkel voor de hosts die je zelf opgegeven hebt. Het commando en alles wat het logt, krijgt het echte geheim nooit te zien. De algemene vorm van die regel is least privilege: een agent die drie tabellen moet lezen, hoort een account te krijgen dat drie tabellen leest, sandbox of niet.

Waar draait zo'n sandbox?

De opties verschillen in hoeveel ze afdekken en hoeveel werk ze je kosten.

1. Een sandbox van het besturingssysteem, op je eigen machine. Geen containers, geen infrastructuur. Ze omsluit de commando's die de agent draait, wat meteen betekent dat de delen van de sessie die geen shell-commando zijn erbuiten kunnen vallen. Bij Claude Code draaien MCP-servers en hooks als aparte processen zonder die beperkingen, tenzij je het hele proces mee omsluit.

2. Een container of dev container. Het volledige agentproces gaat erin, meestal met een firewall die uitgaand verkeer standaard blokkeert. Dit is de gewone keuze voor teams die al met containers en CI-runners werken.

3. Een virtuele machine. Eigen kernel, en bij cloud- of microVM-opstellingen ook eigen gevirtualiseerde hardware. Trager om klaar te zetten, en op zijn plaats wanneer je code draait die je echt niet vertrouwt.

4. Een beheerde sandboxdienst. De dynamic sessions van Azure Container Apps leveren voorverwarmde omgevingen met Hyper-V-isolatie, en Microsoft positioneert ze precies hiervoor: door AI gegenereerde code veilig draaien zonder je productiesystemen te riskeren, waarbij een sessie na een afkoelperiode opgeruimd wordt. GKE Agent Sandbox van Google doet iets vergelijkbaars met gVisor en Kata Containers, met een netwerkbeleid dat standaard alles blokkeert zodat code in de sandbox niet aan interne netwerken kan die ze niet gekregen heeft.

Die beheerde diensten bestaan omdat net het wegwerpbare stuk lastig is om zelf te bouwen. Een sandbox die tussen twee runs blijft bestaan, sleept mee wat de vorige run erin achtergelaten heeft.

Waar moet je op letten bij het gebruik van een agent sandbox

Geheimen die al binnen de grens zitten
Kijk niet alleen naar wat de agent kan bereiken, maar ook naar wat er al in zijn omgeving staat. Afgeschermde commando's erven doorgaans de omgevingsvariabelen van het bovenliggende proces, inloggegevens inbegrepen.

Domeinlijsten die ruimer zijn dan ze lijken
Een breed domein toelaten opent een weg naar buiten voor je data. Anthropic waarschuwt daar expliciet voor bij een regel als github.com, omdat een proxy die enkel op hostnaam beslist en het TLS-verkeer niet openbreekt, te omzeilen valt. Je lijst is zo smal als je ruimste regel.

Noodluiken
De meeste tools laten een commando dat in de sandbox faalt opnieuw proberen buiten de sandbox, want anders lopen gewone tools vast. Dat is een verdedigbare standaardinstelling en tegelijk een echt gat. Reken je op de sandbox als beveiliging, zet dat noodluik dan uit en neem de wrijving erbij.

Wat er buiten de grens valt
Een sandbox per commando dekt shell-commando's af. Ingebouwde bestandstools, MCP-servers en hooks zitten er niet noodzakelijk in. Weet welk deel van je sessie echt afgeschermd draait.

Een sandbox is geen vervanging voor de scope van het werk
Afscherming beperkt de schade van een actie die de agent nooit had mogen doen. Ze vervangt niet de beslissing welke tools hij krijgt. Een agent die enkel een rapport moet opstellen, heeft in geen enkele omgeving schrijfrechten op het datawarehouse nodig.