Zodra je agent niet alleen praat maar ook uitvoert, moet je bepalen waar hij bij mag. Vercel loofde deze maand een miljoen dollar uit voor wie hun agent-sandbox weet te breken, en Fortinet kocht een bedrijf dat zich specialiseert in het bewaken van agents tijdens het draaien. Beide zeggen hetzelfde: dit is nu een eigen vakgebied. Hieronder wat een sandbox is, wat hij niet oplost en hoe je hem praktisch inricht.
Het verschil tussen een model dat antwoordt en een agent die handelt, is het verschil tussen een verkeerd advies en een verkeerde handeling.
Een taalmodel dat een antwoord geeft, kan er hooguit naast zitten. Een agent die code schrijft en die code vervolgens uitvoert, kan bestanden aanpassen, verzoeken naar buiten sturen en processen starten. Dat is geen theoretisch verschil: de agent doet dat op basis van tekst die hij onderweg tegenkomt, en die tekst is niet altijd van jou. Wat er dan misgaat staat beschreven in prompt injection in je app.
Een sandbox is het antwoord op de vraag: als hij iets doet wat ik niet bedoelde, hoe ver kan dat dan komen. Je geeft de agent een eigen omgeving met eigen bestanden, eigen processen en een eigen netwerkbeeld, gescheiden van alles waar hij niet hoort te zijn. Gaat het mis, dan gaat het mis binnen die doos.
Dat klinkt vanzelfsprekend maar wordt in prototypes bijna nooit gedaan. De agent draait gewoon op de machine van de bouwer, met diens sleutels in de omgeving en diens netwerktoegang. Dat werkt prima tot de eerste keer dat hij iets uitvoert wat uit een externe bron kwam.
Isolatie is geen enkel ding maar een stapel. Deze drie leveren het meeste op.
De agent ziet alleen de map waarin hij werkt, en die map bevat geen sleutels, geen configuratiebestanden van jou en geen andere projecten. Dit is de makkelijkste muur om te zetten en degene die het vaakst ontbreekt, omdat mensen de agent nu eenmaal in hun eigen werkmap starten.
De agent mag alleen naar bestemmingen die je vooraf hebt toegestaan. Dit is de belangrijkste muur, want de meeste schade bij een geslaagde manipulatie bestaat uit gegevens die naar buiten gaan. Standaard alles dichtzetten en per bestemming openzetten is meer werk, en het is het waard.
De agent draait als een gebruiker die bijna niets mag, en zijn omgeving wordt na afloop weggegooid in plaats van hergebruikt. Zo kan iets wat tijdens een taak is neergezet niet blijven staan voor de volgende. Ook een tijdslimiet hoort hierbij: een agent die in een lus zit, moet vanzelf stoppen.
Dit onderscheid bepaalt of je er terecht op vertrouwt.
Je hebt geen platform nodig om dit fatsoenlijk te doen, wel een paar vaste gewoonten.
Draai de agent in een container met een eigen werkmap die je per taak aanmaakt en na afloop weggooit. Geef die container geen toegang tot je gebruikersmap, je sleutelbos of je andere projecten. Dit alleen al haalt de meeste ongelukken weg, en het kost je een regel of tien configuratie.
Zet het netwerk standaard dicht en open per bestemming wat nodig is: de modelaanbieder, je eigen API, en het pakketregister als de agent afhankelijkheden mag installeren. Wil je weten of dit klopt, probeer dan zelf vanuit de container een verzoek naar een willekeurig ander domein te doen. Slaagt dat, dan staat je belangrijkste muur nog open.
Geef gereedschappen met de kleinst mogelijke rechten en met een aparte sleutel per agent, zodat je die kunt intrekken zonder de rest te raken. Laat alles wat geld kost, iets verstuurt of iets wist langs een bevestiging. En log elke aanroep met argumenten, want zonder die registratie ziet een geslaagde manipulatie eruit als normaal werk.
Tot slot: behandel wat de agent oplevert als code van een onbekende. Lezen voordat je het uitvoert, en zeker voordat het naar productie gaat. Meer daarover in AI je beveiligingsfouten laten repareren.
Een afgeschermde omgeving waarin de agent mag werken, met eigen bestanden, eigen processen en beperkt netwerkverkeer, gescheiden van de rest van je systeem. Het idee is dat een handeling die je niet bedoelde binnen die omgeving blijft en daarbuiten geen schade aanricht.
Zodra de agent code uitvoert of gereedschappen aanroept wel, ook in een prototype. De reden is niet dat een prototype waardevol is, maar dat het meestal draait op de machine van de bouwer, met diens sleutels en netwerktoegang binnen handbereik. Dat is precies wat je wilt scheiden.
Een container is de gebruikelijke manier om er een te maken, maar het is niet automatisch hetzelfde. Een container met toegang tot je hele bestandssysteem, je sleutels en het open internet isoleert weinig. Wat telt zijn de grenzen die je zet: welke bestanden, welk netwerk, welke rechten en hoe lang.
Uitgaand netwerkverkeer. De meeste schade bij een geslaagde manipulatie bestaat uit gegevens die naar buiten gaan, en dat gebeurt via een gewoon verzoek dat er in je logboek normaal uitziet. Zet standaard alles dicht en sta alleen de bestemmingen toe die de agent echt nodig heeft.
Hij beperkt de gevolgen, maar voorkomt de manipulatie niet. Wordt de agent overgehaald om iets te doen wat binnen zijn toegestane grenzen valt, dan doet hij dat gewoon. De sandbox bepaalt hoe groot de kring is waarbinnen die schade kan ontstaan, en dat is precies waarom je die kring klein houdt.
Niet per se. Voor de meeste projecten is een container per taak, met een schone werkmap, een beperkte netwerklijst en een tijdslimiet, ruim voldoende. Kant-en-klare oplossingen worden interessant zodra je veel agents tegelijk draait of ze namens klanten laat werken, want dan komt er een beheervraagstuk bij.
Zet altijd een limiet, zowel in tijd als in het aantal aanroepen. Een agent die in een lus komt, blijft doorgaan zolang hij mag, en dat kost geld en soms meer dan dat. Een harde bovengrens is een van de weinige maatregelen die je in vijf minuten inbouwt en die je gegarandeerd een keer redt.
Dat kan, maar zet dan het pakketregister expliciet op je lijst van toegestane bestemmingen en houd bij wat er is geïnstalleerd. Een agent die vrij mag installeren, kan een pakket binnenhalen dat jij nooit hebt gekozen. Voor productie is vastleggen wat er in zit belangrijker dan het gemak van vrij installeren.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.