Moltbot, l’agente AI precedentemente noto come Clawdbot, continua a catalizzare entusiasmo e preoccupazioni in parti quasi uguali. Da un lato viene celebrato come l’avanguardia dell’assistenza personale automatizzata, mentre dall’altro come un esperimento pericolosamente vicino a smantellare decenni di principi di sicurezza informatica. La domanda che molti esperti pongono è se sia sensato consegnare l’intero perimetro della propria identità digitale a un software agentico esposto, anche solo potenzialmente, a Internet.

Moltbot è un assistente open source, controllabile via WhatsApp o Telegram, capace di agire al posto dell’utente per rispondere alle email, gestire il calendario, filtrare chiamate, prenotare ristoranti ed eseguire task amministrativi che consumano tempo e attenzione con un livello minimo di intervento umano. È l’idea dell’AI come delegato permanente, nonché un salto concettuale che molti aspettavano.

Quel salto, però, richiede un prezzo tecnico altissimo. Per funzionare davvero, infatti, Moltbot deve avere accesso diretto a credenziali, token, account email, sistemi di messaggistica cifrata, numeri di telefono, servizi cloud e in alcuni casi persino conti bancari. In pratica, l’utente non concede autorizzazioni limitate e revocabili, ma consegna le chiavi del proprio ecosistema digitale a un agente che opera in autonomia. È qui che l’entusiasmo degli early adopter inizia a scontrarsi con la realtà dei modelli di minaccia.

Le prime avvisaglie sono arrivate sotto forma di esposizioni pubbliche. Moltbot è un sistema complesso, presentato come installabile con la semplicità di un’app, ma che in realtà richiede competenze avanzate per essere configurato in sicurezza. Jamieson O’Reilly, fondatore della società di red teaming Dvuln, è stato tra i primi a documentare il problema, individuando centinaia di istanze Clawdbot accessibili dal web. In alcuni casi, errori di configurazione e proxy mal gestiti consentivano l’accesso non autenticato a interfacce di amministrazione.

Il vettore di attacco segnalato da O’Reilly, ora corretto dagli sviluppatori, avrebbe potuto consentire a un aggressore di consultare mesi di messaggi privati, rubare credenziali, chiavi API e qualsiasi altro segreto affidato all’agente. Le scansioni effettuate tramite Shodan hanno mostrato un panorama disomogeneo, con istanze completamente aperte, altre parzialmente protette e solo una minoranza configurata in modo realmente sicuro. Un dato che evidenzia il divario tra la percezione di semplicità del prodotto e la complessità operativa reale.

Moltbot

Il problema non si ferma però all’esposizione diretta. O’Reilly ha infatti dimostrato anche un rischio di supply chain attraverso ClawdHub, la libreria di “skill” di Moltbot. Pubblicando una skill apparentemente innocua e manipolando il contatore di download, è riuscito a farla installare da sviluppatori in diversi Paesi. Il codice non era malevolo, ma il proof of concept ha mostrato come sarebbe stato possibile eseguire comandi arbitrari sulle istanze Moltbot. In uno scenario reale, questo avrebbe potuto portare all’esfiltrazione silenziosa di chiavi SSH, credenziali cloud e interi repository di codice.

Il fatto che ClawdHub consideri tutto il codice scaricato come implicitamente affidabile, senza alcun processo di moderazione, sposta l’intero peso della verifica sugli utenti. Un approccio che può funzionare in contesti altamente professionali, ma che diventa fragile quando il prodotto viene promosso come soluzione “one-click” per un pubblico prosumer.

Dopotutto, l’attrattiva consumer di Moltbot maschera la necessità di una governance rigorosa delle API e dei token condivisi. Senza visibilità completa sulle connessioni attive e sulle autorizzazioni concesse, anche una singola configurazione errata può trasformare l’agente in una porta spalancata su dati personali e aziendali.

A complicare ulteriormente il quadro, intervengono le analisi di Hudson Rock. Anche quando Moltbot è configurato correttamente, parte dei segreti viene memorizzata in chiaro su file Markdown e JSON nel filesystem locale. In un’epoca in cui il malware come servizio evolve rapidamente, questa scelta espone l’agente a famiglie di infostealer già capaci di colpire strutture “local-first”. Se la macchina host viene compromessa, i dati raccolti dall’AI diventano immediatamente accessibili.

Un attaccante con accesso in scrittura potrebbe inoltre usare Moltbot come backdoor persistente, istruendolo a fidarsi di fonti malevole o a sottrarre informazioni nel tempo. Secondo Hudson Rock, l’idea di un’AI locale senza cifratura a riposo né isolamento tramite container rischia di diventare una miniera d’oro per la criminalità informatica globale.

Quello che emerge, andando oltre il singolo prodotto, è un problema più ampio. Per vent’anni la sicurezza informatica ha costruito confini, sandbox, modelli di permessi e isolamento dei processi per ridurre l’impatto delle compromissioni. Gli agenti AI, per definizione, devono invece attraversare tutti questi confini, leggere file, usare credenziali, eseguire comandi e dialogare con l’esterno. Il loro valore deriva proprio dall’abbattimento delle barriere.

È per questo che si inizia a parlare sempre più spesso degli agenti AI come del prossimo grande “insider threat”. Un’entità altamente privilegiata, automatizzata e sempre attiva rappresenta un obiettivo ideale per chi cerca accesso persistente. Non sorprende che voci autorevoli, come Heather Adkins di Google Cloud, invitino apertamente a non installare Moltbot, mentre altri esperti si chiedono come sia possibile fidare a un singolo software un accesso così totale all’intero sistema.

(Immagine in apertura: Shutterstock)