Non fidarti degli agenti IA

Quando si sviluppa con agenti IA, bisogna trattarli come non affidabili e potenzialmente malevoli. Che il timore sia la prompt injection, un modello che tenta di evadere dalla sandbox, o qualcosa a cui nessuno ha ancora pensato, indipendentemente dal modello di minaccia, non bisogna fidarsi dell’agente. L’approccio corretto non sono controlli di autorizzazione migliori o allowlist piu intelligenti. E un’architettura che presuppone che gli agenti si comporteranno male e che contiene i danni quando lo fanno.

E il principio su cui ho costruito NanoClaw.

Non fidarti del processo

OpenClaw per impostazione predefinita gira direttamente sulla macchina host. Ha una modalita sandbox Docker opzionale, ma e disattivata di default e la maggior parte degli utenti non la attiva mai. Senza, la sicurezza si basa interamente su controlli a livello applicativo: allowlist, richieste di conferma, un insieme di comandi “sicuri”. Questi controlli partono dal presupposto implicito che l’agente non tentera di fare qualcosa di sbagliato. Una volta adottata la mentalita che un agente e potenzialmente malevolo, e evidente che i blocchi a livello applicativo non bastano. Non garantiscono una sicurezza ermetica. Un agente determinato o compromesso puo trovare il modo di aggirarli.

In NanoClaw, l’isolamento tramite container e parte integrante dell’architettura. Ogni agente gira nel proprio container, su Docker o su un Apple Container su macOS. I container sono effimeri: creati nuovi per ogni invocazione e distrutti subito dopo. L’agente gira come utente non privilegiato e puo vedere solo le directory che sono state esplicitamente montate. Il confine del container e imposto dal sistema operativo.

Non fidarti degli altri agenti

Anche quando la sandbox di OpenClaw e attiva, tutti gli agenti condividono lo stesso container. Si potrebbe avere un agente come assistente personale e un altro per il lavoro, in gruppi WhatsApp o canali Telegram diversi. Si trovano tutti nello stesso ambiente, il che significa che le informazioni possono trapelare tra agenti che dovrebbero accedere a dati diversi.

Gli agenti non dovrebbero fidarsi l’uno dell’altro piu di quanto ci fidiamo noi di loro. In NanoClaw, ogni agente ha il proprio container, filesystem e cronologia della sessione Claude. L’assistente personale non puo vedere i dati dell’agente di lavoro perche girano in sandbox completamente separate.

Il confine del container e il livello di sicurezza rigido: l’agente non puo evaderlo indipendentemente dalla configurazione. Inoltre, una allowlist di mount in ~/.config/nanoclaw/mount-allowlist.json funge da ulteriore livello di difesa in profondita: esiste per impedire all’utente di montare accidentalmente qualcosa che non dovrebbe essere esposto, non per impedire all’agente di uscire. I percorsi sensibili (.ssh, .gnupg, .aws, .env, private_key, credentials) sono bloccati per impostazione predefinita. L’allowlist risiede fuori dalla directory del progetto, quindi un agente compromesso non puo modificare le proprie autorizzazioni. Il codice dell’applicazione host e montato in sola lettura, quindi nulla di cio che un agente fa puo persistere dopo la distruzione del container.

Nemmeno le persone nei gruppi dovrebbero essere considerate affidabili. I gruppi non principali sono non affidabili per impostazione predefinita. Altri gruppi, e le persone al loro interno, non possono inviare messaggi ad altre chat, pianificare attivita per altri gruppi o visualizzare i dati di altri gruppi. Chiunque in un gruppo potrebbe inviare una prompt injection, e il modello di sicurezza ne tiene conto.

Non fidarti di cio che non puoi leggere

OpenClaw ha quasi mezzo milione di righe di codice, 53 file di configurazione e oltre 70 dipendenze. Questo viola la premessa fondamentale della sicurezza open source. Chromium ha oltre 35 milioni di righe, ma ci si fida dei processi di revisione di Google. La maggior parte dei progetti open source funziona al contrario: rimangono abbastanza piccoli perche molti occhi possano effettivamente esaminarli. Nessuno ha revisionato le 400.000 righe di OpenClaw. E stato scritto in poche settimane senza un processo di revisione adeguato. La complessita e dove si nascondono le vulnerabilita, e l’analisi di Microsoft lo ha confermato: i rischi di OpenClaw possono emergere attraverso normali chiamate API, perche nessuna singola persona riesce a vedere il quadro completo.

NanoClaw e un singolo processo e una manciata di file. Ci affidiamo in modo significativo al Claude Agent SDK di Anthropic, il wrapper attorno a Claude Code, per la gestione delle sessioni, la compattazione della memoria e molto altro, invece di reinventare la ruota. Uno sviluppatore competente puo revisionare l’intera codebase in un pomeriggio. Questo e un vincolo deliberato, non una limitazione. Le nostre linee guida per i contributi accettano esclusivamente correzioni di bug, correzioni di sicurezza e semplificazioni.

Le nuove funzionalita arrivano tramite le skill: istruzioni con un’implementazione di riferimento completa che un agente di sviluppo integra nella codebase. Si revisiona esattamente quale codice verra aggiunto prima che venga incluso. E si aggiungono solo le integrazioni di cui si ha effettivamente bisogno. Ogni installazione si riduce a poche migliaia di righe di codice su misura per le esigenze esatte del proprietario.

Questa e la vera differenza. Con una codebase monolitica di 400.000 righe, anche se si abilitano solo due integrazioni, il resto del codice e ancora presente. E ancora caricato, ancora parte della superficie di attacco, ancora raggiungibile da prompt injection e agenti malevoli. Non si puo separare cio che e attivo da cio che e dormiente. Non si puo fare un audit perche non si riesce nemmeno a definire il confine di quale sia “il proprio codice”. Con le skill, il confine e chiaro: sono poche migliaia di righe, e tutto codice che si e scelto di aggiungere, e si puo leggere ogni singola riga. Il core sta effettivamente diventando piu piccolo nel tempo: il supporto WhatsApp, ad esempio, viene estratto e distribuito come skill.

Progettare per la diffidenza

Se un’allucinazione o un agente che si comporta male puo causare un problema di sicurezza, allora il modello di sicurezza e difettoso. La sicurezza deve essere applicata al di fuori della superficie agentica, non dipendere dal comportamento corretto dell’agente. Container, restrizioni di mount e isolamento del filesystem esistono affinche, anche quando un agente fa qualcosa di imprevisto, il raggio d’azione sia contenuto.

Nulla di tutto questo elimina il rischio. Un agente IA con accesso ai propri dati e intrinsecamente una configurazione ad alto rischio. Ma la risposta corretta e rendere quella fiducia il piu ristretta e verificabile possibile. Non fidarti dell’agente. Costruisci muri attorno ad esso.

Puoi leggere il codice sorgente e il modello di sicurezza completo di NanoClaw; sono abbastanza brevi da leggere in un pomeriggio.