Google Cloud heeft een beheerde GKE Agent Sandbox-service uitgerold, terwijl het open-source project kubernetes-sigs/agent-sandbox dezelfde functionaliteit naar elk Kubernetes-cluster brengt. Beide bieden ontwikkelaars een wegwerpbare Linux-container voor AI-agenten, terwijl de rest van de infrastructuur onaangetast blijft.
Waarom door AI gegenereerde code een speeltuin nodig heeft
Moderne AI-agenten beantwoorden niet alleen vragen. Ze schrijven scripts, surfen op het web, voeren shell-commando's uit en starten zelfs webservices op. Die kracht creëert een beveiligingsgat: de code die ze uitspugen kan buggy, kwaadaardig of overdreven agressief zijn. Een agent die rm -rf / uitvoert of zonder toestemming verbinding maakt met een interne database, kan een heel systeem in gevaar brengen.
Een sandbox isoleert elke agent in zijn eigen container — een kleine, wegwerpbare virtuele machine. Als de agent zich misdraagt, blijft de schade binnen die container; de host en andere workloads blijven veilig. De nieuwe GKE-aanbieding en het door de community gedreven project maken van dit idee een direct inzetbare service.
Twee manieren om een sandbox te krijgen
- GKE Agent Sandbox – een volledig beheerde service voor Google Cloud-klanten.
kubernetes-sigs/agent-sandbox– een open-source project voor elk Kubernetes-cluster.
Beide delen dezelfde kernarchitectuur, gebouwd op standaard Kubernetes-primitieven.
Hoe het systeem is opgebouwd
| Component | Rol |
|---|---|
| Sandbox | De geïsoleerde container die de code van de agent uitvoert. Deze heeft een stabiele naam en biedt persistente opslag indien nodig. |
| SandboxTemplate | Een blauwdruk die de containerimage en beveiligingsregels definieert — een recept voor nieuwe sandboxes. |
| SandboxClaim | Een verzoek uitgegeven door een agent (of diens controller) om een sandbox op te starten vanuit een specifieke template. |
| SandboxWarmPool | Een pool van vooraf aangemaakte sandboxes die direct beschikbaar zijn. Het 'warm' houden van containers voorkomt de latentie van het ophalen van images en het telkens opnieuw starten van een nieuwe pod. |
Wanneer een agent een omgeving nodig heeft, plaatst deze een SandboxClaim. De controller controleert de warm pool, kiest een inactieve sandbox en koppelt deze aan de claim. Als de pool leeg is, wordt er een nieuwe sandbox aangemaakt vanuit de template; anders vindt de overdracht binnen enkele milliseconden plaats.
Beveiligingsinstellingen die je kunt aanpassen
- Default-deny networking – Standaard kan een sandbox het interne netwerk niet bereiken. Je moet expliciete regels toevoegen om inkomende of uitgaande verbindingen toe te staan, om accidentele blootstelling van interne services te voorkomen.
- Isolatieniveaus – Kies de container runtime die past bij je risicotolerantie:
- Standaard containers voor snelheid,
- gVisor voor een extra isolatielaag in de user-space, of
- Kata Containers voor hardware-ondersteunde isolatie die zich gedraagt als een lichtgewicht VM.
- SDK's – Python- en Go-clientbibliotheken stellen ontwikkelaars in staat om programmatisch sandboxes aan te maken, te claimen en te vernietigen, passend bij de workflow van AI-gestuurde pipelines.
Wie profiteert, en wie kan ertegen bezwaar maken
De kern
Door AI-agenten hun eigen wegwerpbare Linux-omgeving te geven, wordt de grootste onbekende factor in AI-gestuurde automatisering weggenomen: het risico dat gegenereerde code de host beschadigt. De beheerde GKE Agent Sandbox van Google Cloud en het door de community beheerde kubernetes-sigs/agent-sandbox maken die isolatie praktisch voor zowel cloud-native als on-prem omgevingen. Organisaties die wendbaarheid moeten afwegen tegen beveiliging hebben nu een concreet, Kubernetes-native hulpmiddel om door AI gegenereerde code in een beveiligde speeltuin te houden.