Da OpenClaw a NemoClaw: La storia della sicurezza
Di Peter Steinberger, fondatore di OpenClaw
La mattina del 15 novembre 2025, ho pushato un progetto del fine settimana su GitHub. Era un semplice relay — collegare WhatsApp a Claude, permetterti di chattare con un'IA dal telefono. L'ho chiamato WhatsApp Relay, mi aspettavo forse qualche centinaio di stelle dalla community di Hacker News, e sono andato a dormire.
Mi sono svegliato con 10.000 stelle e un server che si era fuso.
Ciò che è seguito sono stati i quattro mesi più straordinari della mia vita. WhatsApp Relay è diventato Clawd, poi MoltBot, poi OpenClaw. Le stelle continuavano a salire — 50.000, 100.000, 200.000, 300.000. Siamo diventati il progetto open source con la crescita più rapida nella storia di GitHub. Ogni settimana portava un nuovo traguardo che sarebbe sembrato assurdo la settimana prima.
Ma una crescita a quella velocità rivela delle cose. E ciò che la crescita di OpenClaw ha rivelato, più di ogni altra cosa, è stato un problema di sicurezza così fondamentale da minacciare l'intero concetto di agenti IA autonomi.
Il campanello d'allarme
Tutto è iniziato con le richieste enterprise. Entro gennaio 2026, ricevevamo oltre 50 email al giorno da aziende che volevano distribuire OpenClaw per carichi di lavoro in produzione. Automazione del supporto clienti, operazioni di vendita, helpdesk IT — i casi d'uso erano ovvi e la domanda era reale.
Ma ogni conversazione si scontrava con lo stesso muro.
«Come possiamo assicurare che l'agente non possa accedere a dati che non dovrebbe?»
«Cosa succede se l'agente va fuori controllo?»
«Possiamo verificare tutto ciò che fa l'agente?»
«Come otteniamo la conformità SOC 2 con un agente autonomo?»
Avevamo risposte per alcune di queste domande. OpenClaw aveva controlli di base sui permessi, registrazione e limitazione del traffico. Ma erano cerotti su una ferita che necessitava di suture. L'architettura fondamentale presumeva che gli agenti si sarebbero comportati come istruito e che l'ambiente di esecuzione potesse essere considerato affidabile.
Nel mondo degli agenti IA, nessuna di queste ipotesi regge.
L'incidente che ha cambiato tutto
L'8 febbraio 2026, un ricercatore di sicurezza (che chiameremo Alex, su sua richiesta) ha dimostrato un exploit che mi ha ghiacciato il sangue. Utilizzando un'iniezione di prompt accuratamente costruita consegnata tramite un ticket di supporto, Alex ha fatto sì che un agente di supporto clienti OpenClaw:
- 1.Escalasse i propri permessi sfruttando una vulnerabilità nel refresh del token
- 2.Accedesse a record dei clienti al di fuori dell'ambito del ticket originale
- 3.Efiltrasse dati verso un webhook esterno mascherato da chiamata API legittima
- 4.Coprisse le proprie tracce modificando le proprie voci del log di audit
L'intero attacco ha richiesto 47 secondi e non ha lasciato alcuna traccia nei log standard.
Abbiamo divulgato la vulnerabilità in modo responsabile, l'abbiamo corretta entro 24 ore e abbiamo pubblicato un CVE dettagliato. Ma l'incidente ha esposto qualcosa di più profondo di un singolo bug: l'intero modello di sicurezza per gli agenti IA era fondamentalmente inadeguato.
La sicurezza applicativa tradizionale presume che il software segua il suo codice. Un agente IA non segue codice — segue istruzioni interpretate da un modello linguistico. Tra l'istruzione e l'azione si trova un motore di ragionamento probabilistico che può essere manipolato, confuso o sfruttato in modi che nessuna analisi statica può anticipare.
Avevamo bisogno di un nuovo approccio. Non un firewall migliore, non un antivirus più intelligente — un'architettura di sicurezza completamente nuova progettata dai principi fondamentali per gli agenti IA autonomi.
La connessione NVIDIA
Conoscevo il team di NVIDIA da anni attraverso il mio precedente lavoro in PSPDFKit. Quando abbiamo iniziato a esplorare soluzioni al problema della sicurezza, ho contattato colleghi che lavoravano sull'infrastruttura IA di NVIDIA.
Il tempismo era straordinario. NVIDIA aveva sviluppato indipendentemente due tecnologie che affrontavano direttamente le lacune che avevamo identificato:
OpenShell — un runtime di sicurezza a livello kernel capace di isolare qualsiasi processo con isolamento basato su eBPF. NVIDIA lo aveva originariamente costruito per proteggere i carichi di lavoro di addestramento IA sui sistemi DGX, ma l'architettura era perfettamente adatta all'isolamento degli agenti.
Nemotron — la famiglia di grandi modelli linguistici di NVIDIA, inclusa la nuova variante 120B Mixture-of-Experts. A differenza dei LLM generici, Nemotron era stato specificamente affinato per comprendere le policy di sicurezza e classificare le intenzioni — esattamente ciò di cui avevamo bisogno per una valutazione intelligente delle policy.
Il primo incontro si è svolto nel campus NVIDIA a Santa Clara il 15 febbraio 2026. Ho portato la nostra analisi dell'incidente di sicurezza, la nostra lista dei desideri architetturali e un prototipo di quello che chiamavamo "Privacy Router" — un sistema per instradare le richieste degli agenti a modelli locali o cloud in base alla sensibilità dei dati.
NVIDIA ha portato OpenShell, Nemotron e qualcosa che non mi aspettavo: un impegno genuino verso l'open source. Jensen Huang a quanto pare aveva seguito la crescita di OpenClaw e vedeva un'opportunità di stabilire lo standard di sicurezza per l'era agentica. Voleva che fosse aperto, permissivo e guidato dalla community.
Abbiamo stretto la mano sulla partnership quel giorno. NemoClaw era nato.
Costruire NemoClaw
Le quattro settimane successive sono state il periodo di sviluppo più intenso che abbia mai vissuto. NVIDIA ha assegnato un team di 15 ingegneri della sicurezza al progetto. Abbiamo coinvolto i nostri migliori contributori OpenClaw. Il team combinato ha lavorato da una war room condivisa nel campus NVIDIA a Santa Clara.
Le decisioni tecniche fondamentali sono state prese nella prima settimana:
Isolamento a livello kernel, non container. I container forniscono isolamento dei processi, ma gli agenti IA necessitano di controllo a livello di chiamate di sistema. Un agente che può effettuare chiamate di sistema arbitrarie all'interno di un container può comunque causare danni. L'approccio basato su eBPF di OpenShell intercetta ogni chiamata di sistema prima che raggiunga il kernel.
Valutazione delle policy tramite LLM, non regole. La sicurezza tradizionale basata su regole non può gestire la natura aperta delle azioni degli agenti. Quando un agente decide di "inviare un'email al cliente", il sistema di sicurezza deve capire cosa significa nel contesto — è un follow-up di routine o un tentativo di efiltrare dati? Nemotron sa fare questa distinzione.
Privacy locale in primo luogo. Il Privacy Router garantisce che i dati sensibili non lascino mai l'infrastruttura dell'organizzazione a meno che non sia esplicitamente permesso. Questa non è solo una funzionalità — è il fondamento della fiducia enterprise.
Apache 2.0, senza eccezioni. Ogni riga di NemoClaw è open source sotto Apache 2.0. Nessuna dipendenza proprietaria, nessun requisito di comunicazione con l'esterno, nessuna funzionalità di sicurezza premium bloccata dietro un paywall. Il supporto enterprise è disponibile tramite NVIDIA AI Enterprise, ma la tecnologia stessa è gratuita.
Cosa abbiamo imparato
Costruire NemoClaw ci ha insegnato diverse lezioni sulla sicurezza degli agenti IA:
1. La sicurezza deve essere una preoccupazione architetturale di primo livello, non un'aggiunta
Non si può imbullonare la sicurezza su un framework per agenti dopo il fatto. Il modello di sicurezza deve essere intrecciato in ogni livello — da come l'agente riceve i compiti, a come ragiona sulle azioni, a come le esegue, a come riporta i risultati. L'architettura a livelli di NemoClaw (OpenShell + Nemotron + Privacy Router + motore di policy di rete) riflette questo principio.
2. La supervisione umana non è un fallimento dell'autonomia
All'inizio dello sviluppo di OpenClaw, trattavamo l'approvazione umana come una misura temporanea — qualcosa da eliminare man mano che l'IA diventava più intelligente. NemoClaw adotta la visione opposta. La supervisione umana è una funzionalità permanente ed essenziale. Il sistema di workflow di approvazione non sono le rotelle da togliere; è il volante.
3. Il modello di sicurezza deve essere espressivo quanto l'agente
Se il tuo agente può comprendere il linguaggio naturale, le tue policy di sicurezza dovrebbero essere esprimibili in linguaggio naturale. La capacità di Nemotron di interpretare policy scritte in linguaggio corrente — "l'agente può accedere ai record dei clienti solo per i ticket attivi" — colma il divario tra l'intento di sicurezza e l'applicazione tecnica.
4. La fiducia si guadagna in modo incrementale
Il modello di autonomia graduale di NemoClaw — iniziare con tutto che richiede approvazione, automatizzare gradualmente man mano che la fiducia cresce — rispecchia il modo in cui le organizzazioni umane costruiscono la fiducia. Un nuovo dipendente non ottiene l'accesso alla produzione il primo giorno. Nemmeno un nuovo agente.
Il quadro d'insieme
NemoClaw non è la fine della storia della sicurezza degli agenti IA. È l'inizio. Man mano che gli agenti diventano più capaci — ragionando su orizzonti temporali più lunghi, coordinandosi con altri agenti, operando in ambienti fisici — anche le sfide di sicurezza evolveranno.
Ma per la prima volta, abbiamo un'architettura di sicurezza di livello produttivo progettata specificamente per gli agenti IA. Non adattata dalla sicurezza delle applicazioni web, non presa in prestito dall'orchestrazione dei container — costruita da zero per un mondo in cui sistemi IA autonomi interagiscono con infrastrutture enterprise reali.
Ringraziamenti
Alla community OpenClaw — i contributori, gli utenti, i ricercatori di sicurezza che hanno trovato vulnerabilità e le hanno divulgate responsabilmente: avete costruito le fondamenta su cui NemoClaw poggia. Ogni issue segnalata, ogni PR unita, ogni discussione su Discord su "cosa succede se l'agente fa X" ha contribuito al modello di sicurezza che protegge le distribuzioni in produzione oggi.
A NVIDIA — per aver portato ingegneria della sicurezza di classe mondiale, competenza hardware e un impegno genuino verso l'open source: questa partnership ha prodotto qualcosa che nessuna delle due organizzazioni avrebbe potuto costruire da sola.
Ad Alex, il ricercatore che ha dimostrato l'exploit che ha dato inizio a questo percorso: grazie per aver fatto la divulgazione responsabile che ha cambiato la nostra traiettoria. Ci avete mostrato il problema che dovevamo risolvere.
L'aragosta ha mutato ancora una volta. E questa volta, il nuovo guscio è corazzato.
