OpenClaw 2.0: l'aggiornamento che ripensa la sicurezza degli agenti AI

OpenClaw ha rilasciato il 30 agosto 2026 la versione 2026.8.1, ribattezzata dal progetto stesso "OpenClaw 2.0": il più grande aggiornamento nella storia del framework open source per agenti AI autonomi, quasi interamente concentrato su credenziali, plugin di terze parti e permessi di esecuzione. Per un progetto che nell'ultimo anno ha fatto della velocità il proprio tratto distintivo, arrivando a pubblicare 106 release in 230 giorni, la scelta di fermarsi quasi due mesi per un solo rilascio è di per sé un segnale: la superficie d'attacco di un agente che può leggere file, controllare un browser, scrivere su piattaforme di messaggistica e invocare servizi cloud era cresciuta più in fretta delle protezioni attorno ad essa.

Cos'è OpenClaw e perché conta per chi si occupa di sicurezza

OpenClaw nasce nel novembre 2025 come Clawdbot, progetto personale dello sviluppatore austriaco Peter Steinberger, prima di essere rinominato a gennaio 2026 e diventare in pochi mesi uno dei progetti open source in più rapida crescita di sempre, con oltre 250.000 stelle su GitHub. È un runtime che gira sull'hardware dell'utente e trasforma un modello linguistico in un assistente autonomo "sempre acceso": non un chatbot che aspetta un prompt, ma un processo persistente con un proprio heartbeat, task pianificati e integrazioni dirette con WhatsApp, Discord, browser e strumenti di sistema.

È esattamente questa autonomia a renderlo interessante dal punto di vista della sicurezza. Un agente che opera senza supervisione continua e che può toccare credenziali, filesystem e sessioni di navigazione autenticate è, in sostanza, un nuovo tipo di superficie d'attacco: se un plugin malevolo o un prompt injection riescono a manipolarlo, l'impatto non si limita a una risposta sbagliata in chat, ma può tradursi in un'azione reale con le credenziali dell'utente. Gli oltre 16.000 pull request di questa release, prodotti da 933 contributor di cui 569 al primo contributo, misurano quanto rapidamente la community abbia dovuto rincorrere questo problema.

Le credenziali non passano più in chiaro nel contesto del modello

Il cambiamento più rilevante riguarda il modo in cui un agente ottiene un segreto. Prima, un flusso che richiedeva una API key o una password finiva quasi inevitabilmente per esporre quel valore nella cronologia della chat o nel contesto passato al modello: chiunque avesse accesso ai log, o lo stesso provider del modello nella fase di inferenza, poteva potenzialmente vedere il segreto in chiaro.

OpenClaw 2.0 introduce le private credential request: l'agente può chiedere un segreto tramite un prompt mascherato, senza che il valore compaia mai nella cronologia della conversazione o nel contesto inviato al modello. A completare il meccanismo, un proxy opzionale può vincolare la sostituzione dei segreti protetti solo a destinazioni approvate esplicitamente, così che anche un tentativo di inviare la credenziale verso un endpoint non previsto fallisca invece di transitare in chiaro. Per i team, è stato aggiunto un secret store condiviso con backend SQLite: i valori restano write-only anche per chi amministra il sistema, e le connessioni verso l'esterno che usano un segreto protetto possono essere legate a host dichiarati esplicitamente in anticipo. È disponibile anche un broker opzionale per 1Password, con autenticazione a service account, approvazione per singolo segreto e audit log che non registra mai il valore effettivo.

Plugin: consenso esplicito prima, non fiducia implicita dopo

Un agente AI capace di installare plugin di terze parti eredita per estensione tutti i rischi tipici di una supply chain software poco controllata, con l'aggravante che spesso è l'agente stesso, e non una persona, a decidere cosa installare. OpenClaw 2.0 obbliga ora a mostrare esplicitamente capacità richieste, provenienza, versione e dettagli dell'artefatto prima che un plugin esterno venga installato o abilitato. Le fonti considerate affidabili (ClawHub, i pacchetti ufficiali, i canali con aggiornamenti tracciati) possono saltare l'avviso di provenienza, ma restano comunque soggette al consenso esplicito sulle capacità richieste; installare un eseguibile arbitrario da fonti non censite richiede ora il flag esplicito --force, un attrito minimo ma deliberato contro l'installazione distratta.

Sessioni e automazioni: meno privilegio implicito, più revoca esplicita

Sul fronte dell'esecuzione, la versione 2.0 introduce modalità di permesso per sessione e restrizioni di workspace: l'accesso al filesystem viene ancorato alla cartella di lavoro registrata, riducendo la possibilità che un agente compromesso navighi liberamente fuori dal proprio ambito. I ruoli operatore per i team permettono di limitare quali agenti, sessioni e ambiti amministrativi sono visibili a un dato utente verificato, ma il progetto stesso è chiaro su un punto: si tratta di funzionalità pensate per la collaborazione, non di un vero isolamento multi-tenant contro un utente ostile all'interno dello stesso team.

Anche la gestione delle automazioni ricorrenti cambia in modo sostanziale. Un'approvazione concessa a un'automazione ora può essere ispezionata e revocata in un secondo momento, e soprattutto viene richiesta una nuova approvazione ogni volta che l'operazione automatizzata cambia natura. È una correzione a un problema di design comune in molti sistemi di automazione: un permesso concesso una volta per un'azione specifica che, nel tempo, finisce per coprire silenziosamente operazioni più ampie di quelle originariamente autorizzate.

Tra le altre modifiche difensive della release: allowlist sui modelli utilizzabili, uno storico delle modifiche di configurazione con redazione automatica dei valori sensibili, protezioni sul recovery del database, un flusso di triage con dati sanificati prima di essere condivisi per il debug, migrazioni di avvio più sicure e correzioni mirate a evitare che contesto di prompt privato finisca nelle risposte finali o in streaming.

Cosa non risolve, e perché va detto

Un aggiornamento di questa portata merita anche una lettura critica, non solo un elenco di funzionalità. OpenClaw dichiara esplicitamente che i ruoli operatore non vanno considerati un vero isolamento multi-tenant: chi gestisce un deployment condiviso con utenti potenzialmente non fidati all'interno dello stesso team non deve trattare questi controlli come un confine di sicurezza assoluto. È un'onestà non scontata per un progetto open source in fortissima crescita, ma resta un limite operativo da tenere presente prima di esporre un'istanza a più persone.

Cosa fare se già usi OpenClaw in produzione

Per chi ha un deployment esistente, in particolare con credenziali reali, plugin di terze parti, integrazioni di messaggistica o esecuzione su servizi cloud, la scala del cambiamento giustifica un percorso di aggiornamento graduale piuttosto che un deploy diretto in produzione. Prima di aggiornare vale la pena:

rivedere quali segreti sono attualmente accessibili all'agente e valutare la migrazione verso le private credential request o il secret store condiviso;
passare in rassegna i plugin installati, verificandone provenienza e capacità richieste con gli stessi criteri che il nuovo flusso di installazione applica ai plugin nuovi;
testare l'aggiornamento in un ambiente isolato prima di applicarlo a un'istanza con accesso a dati o sistemi reali;
se si gestisce un'istanza condivisa da più persone, non fare affidamento sui ruoli operatore come unico controllo di isolamento, e valutare piuttosto istanze separate per gruppi di utenti non reciprocamente fidati.