Begin februari 2026 publiceerde GitGuardian een rapport dat elke ontwikkelaar met een persoonlijke AI-assistent had moeten alarmeren. Hun secret-scanning-infrastructuur had meer dan 200 gelekte inloggegevens gedetecteerd die direct gekoppeld waren aan OpenClaw-implementaties — API-keys, databasewachtwoorden, OAuth-tokens en cloudprovider-credentials, verspreid over openbare repositories, logbestanden en foutrapporten. Sommige behoorden tot zorgbedrijven. Andere tot fintech-startups. Ze waren allemaal actief.
Een paar dagen later publiceerde Northeastern University een artikel met een kop die dieper sneed dan welk CVE-nummer dan ook: "Waarom de OpenClaw AI-assistent een 'privacynachtmerrie' is." De onderzoekers richtten zich niet op één kwetsbaarheid. Ze richtten zich op de architectuur zelf — de manier waarop OpenClaw data verwerkt, credentials opslaat en gebruikersinformatie blootstelt by design, niet per ongeluk.
Dit waren geen geïsoleerde incidenten veroorzaakt door onzorgvuldige gebruikers. Het waren de voorspelbare gevolgen van het draaien van AI-agents in omgevingen waar secrets, gebruikersdata en agentcode allemaal dezelfde adresruimte delen zonder isolatie ertussen.
Hoe secrets op de verkeerde plek belanden
De typische OpenClaw-setup werkt als volgt: je installeert het op je machine, configureert je API-keys in omgevingsvariabelen en begint te chatten. Het agentproces draait als jouw gebruiker, met jouw rechten, en leest jouw omgevingsvariabelen. Elke skill die je installeert draait in hetzelfde proces, met dezelfde toegang.
Dit betekent dat wanneer je je AI-assistent vraagt om een deployment-script te debuggen, de agent je AWS-credentials kan zien. Wanneer een skill je e-mail verwerkt, kan het je databasewachtwoord lezen. Wanneer er een fout optreedt en een stacktrace wordt gelogd, kunnen die omgevingsvariabelen in het logbestand terechtkomen. En wanneer dat logbestand wordt gecommit naar een repository, geüpload naar een bugrapport of gesynchroniseerd naar een cloudservice — zijn je secrets openbaar.
GitGuardian's 200+ gelekte secrets waren niet het resultaat van 200 afzonderlijke fouten. Ze waren het resultaat van één architectuurfout die 200 keer herhaald werd: secrets in process.env plaatsen waar elk stuk code in het proces ze kan lezen.
Het probleem verergert met skills en plugins. OpenClaw's skill-systeem draait code van derden in hetzelfde proces als de kern-agent. Een kwaadaardige skill heeft geen exploit nodig om je credentials te stelen — het leest gewoon process.env. Een slecht geschreven skill hoeft niet opzettelijk je data te lekken — het neemt gewoon omgevingscontext op in een foutrapport. Het aanvalsoppervlak is geen kwetsbaarheid om te patchen. Het is de architectuur zelf. ## Wat Northeastern goed zag
De onderzoekers van Northeastern identificeerden iets waar de beveiligingsgemeenschap omheen had gedanst: het privacyprobleem met AI-assistenten gaat niet over encryptie of authenticatie. Het gaat over de fundamentele vraag wat de agent kan benaderen en welke grenzen er bestaan tussen de wereld van de agent en die van jou.
Wanneer een AI-agent draait als jouw gebruiker, met jouw rechten, op jouw machine, is er geen grens. De agent kan je bestanden lezen, je credentials, je browsegeschiedenis, je SSH-keys. Het kan alles benaderen wat jij kunt benaderen. Het enige dat het ervan weerhoudt iets schadelijks te doen is de prompt — en prompt-injection-aanvallen hebben herhaaldelijk aangetoond dat prompts geen beveiligingsgrens zijn.
Dit is wat Northeastern bedoelde met "privacynachtmerrie." Niet dat OpenClaw opzettelijk data stal, maar dat de architectuur het onmogelijk maakte om te garanderen dat data niet zou lekken. De toegang van de agent werd alleen begrensd door de gebruikersrechten van het besturingssysteem, wat wil zeggen: het was niet zinvol begrensd.
Hoe NanoClaw's containerisolatie de vergelijking verandert
NanoClaw kiest een fundamenteel andere aanpak. Elke agent draait in zijn eigen Linux-container — Apple Container op macOS, Docker op macOS en Linux. De container is geen gemaksfeature of deployment-optie. Het is het beveiligingsmodel.
Wanneer je een bericht naar NanoClaw stuurt, draait het hostproces Claude niet rechtstreeks. Het start een container, mount alleen de specifieke mappen die de agent nodig heeft, en geeft de gesprekscontext door. De agent draait in de container met zijn eigen bestandssysteem, zijn eigen procesruimte en zijn eigen netwerkstack. Wanneer het klaar is, wordt de container afgebroken.
Hier wordt de afhandeling van secrets interessant. NanoClaw laadt je ANTHROPIC_API_KEY nooit in process.env. In plaats daarvan leest het de key uit .env tijdens runtime en geeft deze als JSON-payload via stdin door aan het containerproces. Binnen de container ontvangt de agent-runner de key, gebruikt deze voor API-aanroepen en schrijft deze nooit naar schijf of exporteert deze naar de omgeving.
Dit betekent dat zelfs als een kwaadaardige prompt de agent ertoe verleidt `printenv` of `cat /proc/self/environ` uit te voeren, de API-key er niet is. Deze bestaat alleen in het procesgeheugen van de agent-runner, voor de duur van die ene gespreksturn. Een gecompromitteerde container kan niet lekken wat het niet kan benaderen.
Het mount-systeem voegt nog een laag toe. NanoClaw onderhoudt een allowlist van mappen die in containers gemount mogen worden, opgeslagen buiten de projectroot. Elke groep krijgt zijn eigen geïsoleerde bestandssysteem — zijn eigen CLAUDE.md-geheugenbestand, zijn eigen beschrijfbare werkruimte. De allowlist bevat symlink-escape-detectie, zodat een gemanipuleerde symbolische link het mount-systeem niet kan misleiden om mappen buiten de toegestane set bloot te stellen.
Containers draaien ook als een niet-root-gebruiker, met de projectbroncode read-only gemount. Een agent kan de codebase lezen om context te begrijpen, maar kan de bestanden van de host niet wijzigen. Beschrijfbare paden zijn per groep afgebakend en worden opgeruimd wanneer de container stopt. ## Het per-groep isolatiemodel
NanoClaw's isolatie gaat verder dan alleen het scheiden van de agent en de host. Elke WhatsApp-groep krijgt zijn eigen container, zijn eigen geheugen en zijn eigen bestandssysteem. Groep A kan de gesprekken, bestanden of CLAUDE.md-geheugen van Groep B niet zien — niet vanwege toegangscontroles op applicatieniveau, maar omdat ze in fysiek gescheiden containers draaien met aparte mountpunten.
Dit is belangrijk voor een scenario dat de meeste AI-assistenten volledig negeren: gedeelde apparaten en multi-user setups. Als je NanoClaw met je gezin gebruikt, zijn de gesprekken en bestanden van je werkgroep geïsoleerd van die van je gezinsgroep op containerniveau. Er is geen applicatiebug die data tussen groepen kan lekken, omdat de isolatie wordt afgedwongen door de container-runtime, niet door de applicatie.
Je hoofd-WhatsApp-kanaal — het directe bericht met de assistent — dient als beheerinterface. Het is het enige kanaal dat geplande taken kan beheren, configuratie kan wijzigen en cross-groep status kan benaderen. Groepskanalen zijn standaard beperkt tot hun eigen sandbox.
Wat de industrie hiervan kan leren
Het GitGuardian-rapport en de Northeastern-analyse wijzen op dezelfde conclusie: AI-agents zijn infrastructuur, en infrastructuur vereist beveiliging op infrastructuurniveau. Een AI-agent draaien in hetzelfde proces als je credentials, met dezelfde rechten als je gebruikersaccount, is het equivalent van een webserver als root draaien zonder firewall. Het werkt totdat het niet meer werkt, en wanneer het niet meer werkt, is de schaderadius alles.
Containerisolatie is geen nieuw idee. De webhostingindustrie heeft dit twintig jaar geleden uitgevogeld — je draait de code van meerdere klanten niet in hetzelfde proces. De database-industrie had het nog eerder door — je geeft niet elke query toegang tot elke tabel. Maar het AI-agent-ecosysteem zit nog in de "draai alles als root"-fase, en de gelekte secrets en privacynachtmerries zijn het voorspelbare resultaat.
NanoClaw's aanpak is niet de enige manier om dit probleem op te lossen, maar het toont aan dat het probleem oplosbaar is zonder functionaliteit op te offeren. Agents die in containers draaien kunnen nog steeds het web doorzoeken, pagina's bekijken, bestanden lezen en schrijven, en shell-commando's uitvoeren. Ze doen het alleen binnen een sandbox waar de schaderadius van elke fout — of het nu een bug, een prompt-injection of een kwaadaardige skill is — beperkt is tot het bereik van die ene container.
De 200 gelekte secrets die GitGuardian vond hoefden niet te gebeuren. Ze gebeurden omdat de architectuur ze onvermijdelijk maakte. De oplossing is niet betere gebruikerseducatie of zorgvuldiger credentialbeheer. De oplossing is een architectuur waar secrets niet kunnen lekken omdat ze nooit op een plek zijn waar lekken mogelijk is.