A inizio febbraio 2026, GitGuardian ha pubblicato un rapporto che avrebbe dovuto allarmare ogni sviluppatore con un assistente AI personale. La loro infrastruttura di scansione dei segreti aveva rilevato oltre 200 credenziali trapelate direttamente riconducibili a deployment OpenClaw — chiavi API, password di database, token OAuth e credenziali di provider cloud, sparse tra repository pubblici, file di log e segnalazioni di errori. Alcune appartenevano ad aziende sanitarie. Altre a startup fintech. Tutte erano attive.
Pochi giorni dopo, la Northeastern University ha pubblicato un articolo con un titolo più tagliente di qualsiasi numero CVE: "Perché l'assistente AI OpenClaw è un 'incubo per la privacy'." I ricercatori non si sono concentrati su una singola vulnerabilità. Si sono concentrati sull'architettura stessa — il modo in cui OpenClaw gestisce i dati, archivia le credenziali ed espone le informazioni degli utenti by design, non per errore.
Non si trattava di incidenti isolati causati da utenti disattenti. Erano il risultato prevedibile dell'esecuzione di agenti AI in ambienti dove segreti, dati utente e codice dell'agente condividono tutti lo stesso spazio di indirizzamento senza alcun isolamento tra loro.
Come i segreti finiscono nel posto sbagliato
La configurazione tipica di OpenClaw funziona così: lo installi sulla tua macchina, configuri le chiavi API nelle variabili d'ambiente e inizi a chattare. Il processo dell'agente gira con il tuo utente, con i tuoi permessi, leggendo le tue variabili d'ambiente. Ogni skill che installi gira nello stesso processo, con lo stesso accesso.
Questo significa che quando chiedi al tuo assistente AI di aiutarti a debuggare uno script di deployment, l'agente può vedere le tue credenziali AWS. Quando una skill elabora le tue email, può leggere la password del tuo database. Quando si verifica un errore e uno stack trace viene registrato nel log, quelle variabili d'ambiente possono finire nel file di log. E quando quel file di log viene committato in un repository, o caricato in una segnalazione di bug, o sincronizzato con un servizio cloud — i tuoi segreti sono ora pubblici.
Le oltre 200 credenziali trapelate trovate da GitGuardian non erano il risultato di 200 errori separati. Erano il risultato di un unico errore architetturale ripetuto 200 volte: mettere i segreti in process.env dove ogni pezzo di codice nel processo può leggerli.
Il problema si amplifica con skill e plugin. Il sistema di skill di OpenClaw esegue codice di terze parti nello stesso processo dell'agente principale. Una skill malevola non ha bisogno di un exploit per rubare le tue credenziali — le legge semplicemente da process.env. Una skill scritta male non ha bisogno di divulgare intenzionalmente i tuoi dati — include semplicemente il contesto dell'ambiente in una segnalazione di errore. La superficie d'attacco non è una vulnerabilità da patchare. È l'architettura stessa.
Cosa ha capito bene Northeastern
I ricercatori di Northeastern hanno identificato qualcosa che la comunità della sicurezza stava aggirando: il problema della privacy con gli assistenti AI non riguarda la crittografia o l'autenticazione. Riguarda la domanda fondamentale su cosa l'agente può accedere e quali confini esistono tra il mondo dell'agente e il tuo.
Quando un agente AI gira con il tuo utente, con i tuoi permessi, sulla tua macchina, non esiste alcun confine. L'agente può leggere i tuoi file, le tue credenziali, la tua cronologia di navigazione, le tue chiavi SSH. Può accedere a tutto ciò a cui puoi accedere tu. L'unica cosa che gli impedisce di fare qualcosa di dannoso è il prompt — e gli attacchi di prompt injection hanno dimostrato ripetutamente che i prompt non sono un confine di sicurezza.
Questo è ciò che Northeastern intendeva con "incubo per la privacy." Non che OpenClaw stesse deliberatamente rubando dati, ma che l'architettura rendeva impossibile garantire che i dati non sarebbero trapelati. L'accesso dell'agente era limitato solo dai permessi utente del sistema operativo, il che equivale a dire che non era limitato in modo significativo.
Come l'isolamento tramite container di NanoClaw cambia le carte in tavola
NanoClaw adotta un approccio fondamentalmente diverso. Ogni agente gira all'interno del proprio container Linux — Apple Container su macOS, Docker su macOS e Linux. Il container non è una funzionalità di comodità o un'opzione di deployment. È il modello di sicurezza.
Quando invii un messaggio a NanoClaw, il processo host non esegue Claude direttamente. Avvia un container, monta solo le directory specifiche di cui quell'agente ha bisogno, e passa il contesto della conversazione. L'agente gira all'interno del container con il proprio filesystem, il proprio spazio di processo e il proprio stack di rete. Quando ha finito, il container viene smontato.
Ecco dove la gestione dei segreti diventa interessante. NanoClaw non carica mai la tua ANTHROPIC_API_KEY in process.env. Invece, legge la chiave dal file .env a runtime e la passa al processo del container tramite stdin come payload JSON. All'interno del container, l'agent-runner riceve la chiave, la usa per le chiamate API e non la scrive mai su disco né la esporta nelle variabili d'ambiente.
Questo significa che anche se un prompt malevolo inganna l'agente facendogli eseguire `printenv` o `cat /proc/self/environ`, la chiave API non c'è. Esiste solo nella memoria del processo agent-runner, per la durata di quel singolo turno di conversazione. Un container compromesso non può divulgare ciò a cui non ha accesso.
Il sistema di mount aggiunge un ulteriore livello. NanoClaw mantiene una allowlist di directory che possono essere montate nei container, archiviata al di fuori della root del progetto. Ogni gruppo ottiene il proprio filesystem isolato — il proprio file di memoria CLAUDE.md, il proprio workspace scrivibile. L'allowlist include il rilevamento di escape tramite symlink, così un link simbolico creato ad arte non può ingannare il sistema di mount facendogli esporre directory al di fuori dell'insieme consentito.
I container girano inoltre come utente non-root, con il codice sorgente del progetto montato in sola lettura. Un agente può leggere il codebase per comprendere il contesto, ma non può modificare i file dell'host. I percorsi scrivibili sono limitati per gruppo e ripuliti quando il container termina.
Il modello di isolamento per gruppo
L'isolamento di NanoClaw va oltre la semplice separazione dell'agente dall'host. Ogni gruppo WhatsApp ottiene il proprio container, la propria memoria e il proprio filesystem. Il Gruppo A non può vedere le conversazioni, i file o la memoria CLAUDE.md del Gruppo B — non grazie a controlli di accesso a livello applicativo, ma perché girano in container fisicamente separati con punti di mount separati.
Questo è importante per uno scenario che la maggior parte degli assistenti AI ignora completamente: dispositivi condivisi e configurazioni multi-utente. Se usi NanoClaw con la tua famiglia, le conversazioni e i file del tuo gruppo di lavoro sono isolati dalle conversazioni e dai file del tuo gruppo familiare a livello di container. Non esiste un bug applicativo che possa far trapelare dati tra gruppi, perché l'isolamento è garantito dal runtime del container, non dall'applicazione.
Il tuo canale WhatsApp principale — il messaggio diretto con l'assistente — funge da interfaccia di amministrazione. È l'unico canale che può gestire le attività pianificate, modificare la configurazione e accedere allo stato cross-gruppo. I canali dei gruppi sono limitati alla propria sandbox per impostazione predefinita.
Cosa dovrebbe imparare il settore
Il rapporto di GitGuardian e l'analisi di Northeastern portano alla stessa conclusione: gli agenti AI sono infrastruttura, e l'infrastruttura richiede sicurezza di livello infrastrutturale. Eseguire un agente AI nello stesso processo delle tue credenziali, con gli stessi permessi del tuo account utente, equivale a far girare un web server come root senza firewall. Funziona finché non funziona più, e quando smette di funzionare, il raggio d'esplosione è tutto.
L'isolamento tramite container non è un'idea nuova. Il settore del web hosting l'ha capito vent'anni fa — non si esegue il codice di più clienti nello stesso processo. Il settore dei database l'ha capito ancora prima — non si dà a ogni query l'accesso a ogni tabella. Ma l'ecosistema degli agenti AI è ancora nella fase "esegui tutto come root", e le credenziali trapelate e gli incubi per la privacy ne sono il risultato prevedibile.
L'approccio di NanoClaw non è l'unico modo per risolvere questo problema, ma dimostra che il problema è risolvibile senza sacrificare la funzionalità. Gli agenti che girano nei container possono comunque cercare sul web, navigare pagine, leggere e scrivere file ed eseguire comandi shell. Lo fanno semplicemente all'interno di una sandbox dove il raggio d'esplosione di qualsiasi fallimento — che sia un bug, una prompt injection o una skill malevola — è limitato allo scope di quel singolo container.
Le 200 credenziali trapelate trovate da GitGuardian non dovevano succedere. Sono successe perché l'architettura le rendeva inevitabili. La soluzione non è una migliore educazione degli utenti o una gestione più attenta delle credenziali. La soluzione è un'architettura dove i segreti non possono trapelare perché non si trovano mai in un posto dove la fuga è possibile.