Een sandbox die agent-acties weigert tot ze zijn toegestaan: Strands Box
Wie tool-gebruikende AI-agents inzet, staat voor één centrale onzekerheid: niet wat de agent kán, maar wat hij daadwerkelijk doet zodra hij met het systeem in contact komt. Een agent die een commando kan uitvoeren, een bestand kan lezen of een netwerkverbinding kan openen, heeft een aanvalsvlak dat zich niet laat beoordelen door naar de prompt of het model te kijken. Strands Box neemt een principiële positie in tegenover die onzekerheid: standaard niets toestaan.
Wat Strands Box doet
Box is een open-source sandbox-engine voor AI-agents, geschreven in Rust. Het combineert twee lagen die normaal gesproken gescheiden worden behandeld: isolatie op het niveau van het besturingssysteem, en semantische policies geschreven in Dogwood. De eerste laag legt vast wat de agent rechtstreeks mag, de tweede laag beoordeelt de bewerkingen die door de tolken en gateways lopen.
De configuratie is gesplitst in twee bestanden met verschillende taken. box.toml beschrijft de directe toegangsbeperkingen die het host-besturingssysteem afdwingt. policy.dw bevat de Dogwood-regels die de embedded engine evalueert voor de bewerkingen die Strands Shell, Monty (Python), de egress-gateway en de MCP-broker afhandelen. Belangrijk is dat Box zijn allow-of-deny-beslissingen afdwingt buiten het agent-proces: de agent kan de policy-engine niet zelf overrulen.
Dogwood werkt met permit- en forbid-regels, en de kern is default-deny: een bewerking die de engine controleert, wordt geweigerd tenzij een passende permit hem toestaat, en een passende forbid overschrijft die toestemming. De tolken en gateways delen bovendien een gebeurtenisgeschiedenis, zodat een regel eerdere acties en verstreken tijd kan gebruiken om te beslissen wat nu is toegestaan. Een bestandsuitlezing via Shell of Python kan zo de gateway ertoe brengen een latere uitgaande HTTP-aanvraag te weigeren.
Waarom default-deny de juiste volgorde is
De meeste sandbox-benaderingen beginnen bij wat de agent mag en filteren daarna wat hij niet mag. Box draait die volgorde om, en dat is geen cosmetisch verschil. Default-allow betekent dat elke niet-gespecificeerde bewerking doorgaat; default-deny betekent dat elke niet-gespecificeerde bewerking stopt. Voor een agent waarvan het gedrag bij voorbaat niet volledig voorspelbaar is, is de tweede volgorde de enige die faalt in de veilige richting.
De credential-keuze volgt hetzelfde principe. Box injecteert credentials zo dat ze buiten het agent-proces blijven; de agent kan er niet bij, maar de toegestane bewerkingen kunnen ze wel gebruiken. Dat scheidt de macht om iets te mogen van het bezit van het geheim dat het mogelijk maakt, een scheiding die bij veel agent-implementaties juist ontbreekt omdat de agent de sleutel direct in zijn context krijgt.
De architectonische les: containment op de effectgrens
Deze aanpak sluit aan bij een conclusie die we eerder trokken over agent-isolatiegrenzen: de verdediging verschuift van wat de agent leest naar wat de agent doet. Box maakt die verschuiving concreet door de policy-evaluatie op de effectgrens te leggen, op de shell, de Python-interpreter, de egress-gateway en de MCP-broker, in plaats van te proberen de agent te overtuigen zich te gedragen.
De gebeurtenisgeschiedenis is daarbij de scherpste architectuurkeuze. Een policy die kan verwijzen naar eerdere acties en verstreken tijd, kan uitdrukken wat een statische allowlist niet kan: dat een leesactie op zichzelf onschuldig is, maar een netwerkverbinding direct erna niet. Dat is het verschil tussen containment dat per bewerking beslist en containment dat een gedragspatroon herkent.
Wat er nog ontbreekt
Box is expliciet een preview, en dat begrenst de claim. De huidige ondersteuning is beperkt tot lokale uitvoering op macOS met Apple silicon; Linux-ondersteuning is aangekondigd maar niet geleverd. Dat is een materiële beperking voor wie in productie draait op serverhardware of in een gecontaineriseerde omgeving. De documentatie beschrijft de werking, maar er is geen gepubliceerde evaluatie die aantoont dat de default-deny-engine een breed scala aan agent-aanvallen daadwerkelijk stopt.
De echte toets is bovendien niet of een policy kan worden uitgedrukt, maar of een organisatie haar correct kan schrijven. Een default-deny-engine die te streng is, maakt de agent onbruikbaar; een te losse policy is een lek dat de engine getrouw uitvoert. De verantwoordelijkheid verschuift daarmee van de tool naar de auteur van de policy, en dat is precies de vraag die onder de AI Act art. 15 en de NIS2-richtlijn aantoonbaar moet worden beantwoord: wie stelt de grenzen, en hoe wordt getoetst dat ze kloppen?
Zie ook
AI & Security Intelligence
Wekelijkse nieuwsbrief met AI updates, security alerts en compliance inzichten, direct in uw inbox.
Security & AI Operating Model
Advisory met executiekracht
Van BIO2 en NIS2 tot EU AI Act, embedded in uw operating model, niet als extern project. Maandelijks opzegbaar, met assessments als bewijsvoering.