Moltbot non è solo un chatbot: agisce, ricorda e può sfuggire al controllo

Chi ha trascorso la propria infanzia tra i fumetti ricorda il fascino di una figura come Alfred Pennyworth, il maggiordomo e braccio destro di Bruce Wayne/Batman, sempre pronto a fornire al suo assistito tutto ciò di cui avesse bisogno, nel momento giusto. Una presenza discreta, sullo sfondo, ma estremamente efficiente e fondamentale per permettere al Cavaliere Oscuro di tenere insieme tutti i pezzi della propria vita, dentro e fuori dal costume. Lo stesso archetipo di Alfred - un'entità che conosce profondamente il suo assistito, ne comprende il contesto, le abitudini e le priorità, e opera proattivamente per semplificare la gestione della complessità quotidiana - è stato reinterpretato in chiave moderna nel Marvel Cinematic Universe con la figura di JARVIS, l'assistente-intelligenza artificiale di Tony Stark/Iron Man.

Ed è proprio così che, da sempre, l'immaginazione tecnologica concepisce l'intelligenza artificiale. Negli ultimi dieci anni, la diffusione di assistenti vocali e chatbot ha fatto nascere l'aspettativa che presto ognuno di noi avrebbe avuto il proprio JARVIS: invisibile, efficiente, discreto e, soprattutto, proattivo. La realtà, però, è stata per lo più deludente. Siri, Alexa e Google Assistant ci hanno lasciato spesso con la sensazione di un potenziale non ancora sfruttato, e persino i chatbot basati su modelli linguistici avanzati non sono riusciti a soddisfare davvero il desiderio di interagire con un vero assistente virtuale.

In generale questi sistemi se la possono cavare anche egregiamente nel fornire risposte, suggerimenti o riepiloghi, ma restano fondamentalmente legati ad un funzionamento di tipo reattivo, vincolati a set di comandi predefiniti e con un'integrazione ancor frammentaria e non adeguatamente profonda con l'ecosistema digitale personale dell'utente. Il limite principale non è tanto l'abilità di comprendere il linguaggio naturale, quanto la mancanza di una vera "capacità agentica" a tutto tondo: la possibilità di eseguire azioni complesse, concatenate, persistenti nel tempo, con accesso diretto a strumenti, dati e servizi, in autonomia e interpretando obiettivi, pianificando passi intermedi e compiendo azioni concrete sull'ambiente digitale.

Un preambolo che introduce il tema più discusso e caldo del momento in ambito AI. Si tratta di Clawdbot, oggi noto come Moltbot (aggiornamento del 30/1/26: Moltbot ha cambiato ancora nome in OpenClaw), che è di fatto diventato il simbolo, e al tempo stesso un banco di prova, dell'evoluzione dall'era dei chatbot AI verso quella degli agenti AI operativi, mettendo concretamente in luce sia le potenzialità sia i limiti tecnici, organizzativi e di sicurezza che caratterizzano questa nuova classe di software. Questa combinazione di potenza operativa, accesso a risorse reali e integrazione profonda rende Moltbot uno strumento estremamente flessibile. Allo stesso tempo, aumenta in modo significativo la superficie di attacco e la complessità in termini di sicurezza. Ma andiamo con ordine, senza inopportuni sensazionalismi o allarmismi.

• Che cos'è Clawdbot/Moltbot
• La memoria persistente: Moltbot continua ad imparare chi siamo
• La capacità di auto-espandersi: costruire strumenti per eseguire comandi
• Moltbot è molto di più di un'interfaccia conversazionale
• I rischi di Moltbot su istanze non protette
• Moltbot in locale o in cloud, profili di sicurezza differenti
• Prompt Injection, l'insidia più pericolosa per un agente come Moltbot
• Controllo, sicurezza, autonomia: i lembi di una coperta corta
• Moltbot è il primo vero agente AI autonomo: sopravviverà?

Che cos'è Clawdbot/Moltbot

Clawdbot è un progetto open-source realizzato da Peter Steinberg (papà di PSPDFkit), concepito come agente AI personale self-hoste operativo 24/7, progettato per superare il paradigma del semplice chatbot. A seguito di una disputa sul marchio con Anthropic, la società che sviluppa il noto modello Claude, il progetto ha cambiato nome in Moltbot per evitare ogni forma di assonanza, senza alterare l'architettura, le funzionalità o le finalità. Il nuovo nome richiama il concetto biologico di "molt", ovvero la muta, a indicare non tanto l'evoluzione del progetto ma più in generale, una capacità di auto-adattamento dell'agente. Dal punto di vista funzionale, Moltbot si presenta come un agente operativo: un sistema in grado non solo di generare testo, ma di interagire con l'ambiente digitale dell'utente, integrandosi con esso. Le capacità operative di Moltbot sono varie:

• integrazione con interfacce di messaggistica (Telegram, WhatsApp, Discord, Signal, iMessage ecc.), attraverso le quali riceve comandi e notifica risultati;
• accesso a file system e shell di comando locali, che consente l'esecuzione di script, la gestione di directory e file, l'esecuzione di operazioni di manutenzione automatizzata;
• accesso ad account dell'utente per l'esecuzione di azioni complesse;
• uso di API esterne e servizi cloud (modelli LLM come OpenAI o Anthropic, servizi di produttività come calendari o client mail), sfruttando provider di modelli diversi sulla base delle preferenze di configurazione;
• schedulazione e monitoraggio condizionale, tramite meccanismi cron-like o event driven, per attivare azioni anche in assenza di input diretto, secondo criteri predeterminati;

L'interazione con Clawdbot/Moltbot avviene prevalentemente attraverso i sistemi di messaggistica, dove l'agente si presenta come un contatto con cui scambiare messaggi in modo diretto. L'integrazione di un agente AI all'interno di strumenti già utilizzati quotidianamente rappresenta un punto di forza significativo, poiché consente modalità di interazione più immediate e naturali rispetto ad assistenti che richiedono applicazioni o interfacce dedicate. A questo si aggiunge un elemento distintivo: grazie alla presenza di una memoria persistente, concetto che toccheremo poco più avanti, Moltbot è in grado di mantenere il contesto dell'interazione anche quando il dialogo si sposta tra canali differenti. È quindi possibile avviare una conversazione tramite WhatsApp e riprenderla successivamente su Discord o Microsoft Teams, senza dover ricostruire manualmente il contesto o ripetere le richieste già formulate e, soprattutto, senza dover obbligatoriamente utilizzare un solo canale di comunicazione: si usa quello più comodo a disposizione nel momento in cui è necessario chiedere qualcosa a Moltbot.

Una delle caratteristiche chiave è la possibilità di eseguire azioni reali a partire da istruzioni in linguaggio naturale: inviare messaggi, creare o modificare file, interrogare servizi web, eseguire script, pianificare attività e generare nuove "abilità" personalizzate. In questo senso, Moltbot si avvicina maggiormente al concetto di agente autonomo rispetto alla maggior parte dei chatbot commerciali. Ma a differenza degli assistenti cloud-based come Siri o Alexa, Moltbot non è progettato per rispondere solamente a richieste isolate, ma anche per gestire flussi di lavoro articolati, automatizzare compiti di livello operativo e comportarsi anche in maniera proattiva.

Tutto ciò consente a Moltbot di operare in contesti eterogenei come automazioni di sistema, notifiche condizionali, interazioni programmate con strumenti aziendali o personali, e delega di compiti ricorrenti senza la necessità dell'interazione umana continua. Le "skills" abilitate dall'utente definiscono granularmente quali categorie di operazioni l'agente può intraprendere (accesso ai file, automazione del browser, invio di messaggi, etc.), e costituiscono di fatto l'insieme dei permessi operativi dell'agente.

È importante sottolineare che Moltbot non dispone di capacità IA proprie o di LLM interni: per funzionare si appoggia a LLM terzi che possono essere in cloud (come quelli messi a disposizione da OpenAI o Anthropic) oppure open-source in locale. Il progetto pone, infine, l'accento sulla sovranità dei dati: l'installazione può essere eseguita localmente, senza dipendere da infrastrutture cloud centralizzate, mantenendo i dati e le operazioni sotto il controllo diretto dell'utente.

La memoria persistente: Moltbot continua ad imparare chi siamo

Uno degli elementi che distingue in modo più netto Clawdbot/Moltbot dai chatbot tradizionali è la già citata presenza di una memoria persistente strutturata: le conversazioni e le interazioni che si hanno con l'agente non sono conservate come semplice storico, ma fungono da substrato cognitivo permanente. Ciò significa che il contesto non è più limitato ad una singola sessione, ma viene continuamente allargato nel corso del tempo per arricchire una rappresentazione dell'utente, delle sue preferenze, delle abitudini e dell'ambiente in cui agisce. Proprio come Alfred o JARVIS.

Nei chatbot convenzionali, la memoria è per lo più effimera o fortemente limitata. Anche quando viene dichiarata una qualche forma di persistenza, questa è spesso astratta, generalmente non trasparente e, comunque, mediata dal provider del servizio. In Moltbot, al contrario, la memoria è locale, accessibile e modificabile, ed è parte integrante del funzionamento dell'agente: la memoria persistente di Moltbot è implementata attraverso una combinazione di file strutturati (tipicamente in formato Markdown o JSON), database locali e log semantici che l'agente utilizza per conservare informazioni sull'utente (preferenze, istruzioni ricorrenti, vincoli), mantenere traccia delle decisioni passate, accumulare conoscenza operativa sul contesto in cui lavora, stabilire continuità tra interazioni distanti nel tempo. File come MEMORY.md, SOUL.md o strutture analoghe costituiscono una fonte primaria di "verità" per l'agente, consultata attivamente durante il ragionamento e la pianificazione delle azioni.

In Moltbot la memoria è pertanto una risorsa attiva che influenza direttamente il comportamento futuro. Questo significa che due istanze dello stesso agente, configurate con la stessa versione del codice ma con memorie diverse, possono comportarsi in modo sostanzialmente differente. E' grazie alla memoria persistente che Moltbot può adattare il proprio stile di interazione, evitare di ripetere azioni già eseguite, ricordare decisioni precedenti, stabilire una gerarchia di priorità e, in ultima istanza, costruire catene di automazione sempre più sofisticate. Ed è in questo che Clawdbot/Moltbot assomiglia a JARVIS: non un semplice esecutore "stupido" di comandi, ma un sistema che riconosce e apprende schemi per riutilizzarli in maniera sempre più efficiente.

La capacità di auto-espandersi: costruire strumenti per eseguire comandi

Moltbot possiede poi la capacità di estendere dinamicamente le proprie funzionalità attraverso le cosiddette skills a cui abbiamo accennato in precedenza. Questi moduli aggiuntivi permettono all'agente di acquisire strumenti e integrazioni che non possedeva nativamente, adattandosi ai compiti richiesti dall'utente. Moltbot può generare, configurare e installare nuove skills basandosi su istruzioni in linguaggio naturale: l'utente può chiedere, ad esempio, di creare un'integrazione con un servizio esterno o di automatizzare un compiti specifico, e l'agente traduce la richiesta in codice eseguibile, testando e rendendo operativa la nuova abilità senza intervento manuale diretto. Questo meccanismo introduce una forma di auto-estensione operativa: Moltbot sfrutta il motore linguistico a cui si appoggia per trasformare comandi generali in moduli concreti che ampliano il proprio arsenale di strumenti. L'agente rimane vincolato all'ambiente in cui è eseguito, e ogni nuova skill viene salvata e gestita come parte della sua memoria persistente.

Immaginiamo un utente che voglia automatizzare un flusso di lavoro interno: ad esempio, ricevere email di progetto, estrarne le scadenze e aggiornare automaticamente un calendario condiviso. Moltbot, di base, non possiede uno strumento specifico per leggere email, interpretare date e sincronizzarle con il calendario. L'utente può quindi chiedere all'agente di "creare una skill per gestire questo compiti". Moltbot genera il codice necessario, configura la logica del modulo e lo integra nel proprio ambiente, rendendo la funzionalità subito disponibile. Da questo momento, l'agente può eseguire il compiti senza ulteriori interventi, imparando nel tempo quali email considerare rilevanti e quali azioni eseguire automaticamente. Questo è un semplice esempio, ma Moltbot è capace di creare skill anche molto più sofisticate, qualora ne abbia bisogno per portare a termine un compito. Si tratta di una caratteristica che lo rende estremamente versatile e potente.

Le capacità di Moltbot, la sua potenza e la sua facilità di installazione lo hanno reso velocemente molto popolare, con i social network invasi da utenti che raccontano le loro esperienze d'uso dopo pochi giorni o settimane. C'è un entusiasmo diffuso, anche condivisibile, che tende a prendere sotto gamba alcuni aspetti piuttosto delicati.

Moltbot è molto di più di un'interfaccia conversazionale

Proseguiamo il parallelismo supereroistico, scomodando una tra le citazioni più famose dei fumetti: "Da un grande potere derivano grandi responsabilità". Fino a ora abbiamo visto che Clawdbot/Moltbot possiede, in termini di "grande potere", almeno cinque caratteristiche chiave: profonde capacità di integrazione con l'ecosistema digitale dell'utente, memoria persistente "immortale", elevate capacità di automazione, operatività self-hosted e possibilità di auto-miglioramento e auto-costruzione di strumenti operativi.

Dall'altro lato, è fondamentale osservare il fenomeno con spirito critico e considerare attentamente le implicazioni in termini di sicurezza: i "superpoteri" appartengono a Moltbot, ma la responsabilità del loro utilizzo resta nelle mani dell'utente. Un errore concettuale comune è considerare Moltbot soltanto come un'interfaccia conversazionale. Sebbene lo sia, di fatto rappresenta anche un agente con privilegi e memoria, che funge concretamente da punto di aggregazione di identità digitali: account di messaggistica, chiavi API, token OAuth, contesti di lavoro, preferenze personali, cronologie operative e così via.

C'è una prima "arma a doppio taglio": l'operatività self-hosted. Sebbene questa caratteristica sia percepita come un vantaggio in termini di privacy, comporta per l'utente oneri significativi di configurazione e sicurezza, ben superiori a quelli richiesti da un normale chatbot terzo basato sul cloud. Le elevate capacità di integrazione e il potenziale grado di automazione - maggiore è l'accesso concesso a Moltbot, maggiore è la sua autonomia operativa - rendono l'agente utile non solo in contesti domestici o personali, ma anche come supporto per attività operative su infrastrutture remote.

Tuttavia, la complessità di tali operazioni impone un modello di sicurezza e gestione delle autorizzazioni di livello professionale, poiché le capacità dell'agente equivalgono a quelle di un utente con privilegi elevati sul sistema.

I rischi di Moltbot su istanze non protette

E qui nascono le prime "grane": l'installazione di Moltbot, un programma invero molto leggero, sia su un sistema fisico locale, come Raspberry Pi, mini-PC Linux o Mac (negli Stati Uniti è molto diffusa la configurazione Moltbot su Mac mini), sia su una propria istanza server in cloud con risorse contenute, richiede protezione adeguata contro accessi esterni non autorizzati. Per gli utenti più esperti può sembrare un dettaglio banale, ma la realtà è diversa. Il ricercatore di sicurezza Jameison O'Reilly ha ben documentato quanto ha scoperto, in un post su LinkedIn: alcuni problemi sono stati causati da problemi di configurazione a carico del progetto, che gli sviluppatori affermano di aver già sistemato, in altri casi si è trattato di pannelli di amministrazione web di Moltbot che non sono stati adeguatamente protetti dall'accesso. L'improvvisa popolarità di Clawdbot/Moltbot ha portato molti a installarlo in modo superficiale, tanto che diverse scansioni tramite Shodan rilevano centinaia di istanze esposte su Internet e liberamente accessibili, alcune con la possibilità di accedere direttamente a pannelli di controllo, configurazioni, token di accesso e cronologie di conversazione.

Questo si collega a un altro "superpotere" di Moltbot: le ampie possibilità di integrazione con l'ecosistema digitale dell'utente. Chi ottiene accesso non autorizzato a un'istanza Moltbot può potenzialmente raggiungere l'intera vita digitale dell'utente, o almeno tutte le risorse a cui Moltbot ha ricevuto accesso, con conseguenti rischi significativi. Credenziali di accesso, token di sessione, chiavi API di provider terzi, account di messaggistica e altri elementi sensibili possono essere compromessi, con evidenti implicazioni per sicurezza e privacy. Se Moltbot dispone anche di accesso al filesystem, i rischi aumentano ulteriormente, fino alla possibile totale compromissione della macchina.

Le implicazioni diventano ancora più gravi se si considera la memoria persistente di Moltbot. Un accesso non autorizzato a un'istanza può permettere la lettura e la modifica dei file che costituiscono tale memoria, con due conseguenze principali: da un lato, un attaccante può ricostruire informazioni dettagliate e spesso sensibili sulla vita digitale e sulle abitudini dell'utente, accumulate nel tempo dall'agente; dall'altro, la possibilità di alterare la memoria consente di modificare il comportamento di Moltbot, inducendolo a compiere azioni non previste o non autorizzate. Poiché queste azioni possono risultare coerenti con il contesto memorizzato, risultano difficili da individuare e possono passare inosservate all'utente.

Facciamo un esempio per comprendere meglio il problema, attraverso uno scenario verosimile: un utente utilizza Moltbot per gestire attività ricorrenti, come il monitoraggio delle email, l'invio di notifiche e alcune automazioni legate al lavoro quotidiano. Nel tempo, l'agente ha memorizzato preferenze, priorità e regole operative implicite, ad esempio quali comunicazioni considerare rilevanti o quali azioni eseguire senza richiedere una conferma esplicita. In caso di accesso non autorizzato all'istanza, un attaccante potrebbe manipolare la memoria persistente dell'agente, modificando o inserendo informazioni che Moltbot considera affidabili. Il comportamento che ne consegue non appare necessariamente anomalo fin da subito, ma si manifesta come una variazione graduale e coerente con il contesto: notifiche inviate a destinatari aggiuntivi, dati condivisi con servizi esterni apparentemente legittimi, o automazioni che comprendono passaggi non richiesti dall'utente. Poiché tali azioni si inseriscono in flussi preesistenti basati su informazioni "storiche" dell'agente, l'utente potrebbe non rilevare subito le anomalie. In questo senso, la compromissione della memoria persistente non genera un errore evidente, ma una distorsione del comportamento dell'agente, che continua a operare in modo plausibile pur seguendo istruzioni che non riflettono più la volontà prima dell'utente.

Quanto descritto finora illustra le possibili conseguenze di accessi non autorizzati a istanze di Moltbot non adeguatamente protette. La scelta tra un'installazione locale e una in cloud non determina di per sé il livello di sicurezza dell'agente, ma definisce il tipo di rischio a cui l'istanza è esposta.

Moltbot in locale o in cloud, profili di sicurezza differenti

Nel caso di un'installazione locale, il principale vantaggio è la ridotta esposizione iniziale: l'istanza opera all'interno della rete dell'utente e, per impostazione predefinita, non è raggiungibile da Internet, riducendo in maniera significativa il rischio di attacchi opportunistici e scansioni automatiche. È importante sottolineare, però, che questo livello di sicurezza è spesso "implicito" e fragile se non si dispone della necessaria conoscenza e consapevolezza operativa. Un port forwarding configurato superficialmente, l'attivazione di accessi remoti temporanei o la scarsa protezione del sistema host possono rapidamente trasformare un'installazione locale in un servizio esposto, privo delle contromisure tipiche degli ambienti pubblici.

L'installazione in cloud presenta, sotto certi aspetti, un profilo opposto: la disponibilità immediata di un indirizzo IP pubblico e la necessità di accesso remoto rendono l'istanza visibile fin dal primo avvio. In assenza di misure di protezione esplicite come restrizioni di rete, autenticazione forte e segmentazione dei servizi, Moltbot diventa facilmente individuabile da strumenti di scansione automatica. In questo contesto, l'errore più comune consiste nel confidare eccessivamente nella sicurezza fornita dal provider cloud, dimenticando che la protezione del sistema e dell'applicazione rimane in larga parte responsabilità dell'utente.

In entrambi i casi, Moltbot deve essere considerato un servizio sensibile, capace di accedere a dati e risorse critiche, e pertanto protetto in modo adeguato in base al tipo di installazione adottata. Una configurazione sicura e correttamente gestita dell'istanza permette di mitigare efficacemente tutti i rischi discussi in precedenza, dalla compromissione della memoria persistente all'accesso non autorizzato alle credenziali e ai token, riducendo a livelli trascurabili la possibilità di interferenze esterne o modifiche indesiderate del comportamento dell'agente.

Moltbot dimostra che non tutto ciò che è "self" (self-hosted come l'istanza di Moltbot, self-custodial come accade nel caso delle criptovalute) è necessariamente più semplice o immediato. Anzi, spesso è vero l'opposto: gestire direttamente i propri dati e servizi offre autonomia e controllo, ma richiede anche un grado significativo di consapevolezza, conoscenza tecnica e responsabilità personale. Il "self" è una forma di libertà e indipendenza, ma significa anche essere in grado di proteggere ciò che si controlla e assumersi le conseguenze di ogni scelta.

E' tutto qui? No, purtroppo: esiste un rischio ancora più insidioso, che non può essere eliminato semplicemente proteggendo l'installazione di Moltbot. Ci riferiamo al fenomeno della prompt injection, una minaccia che sfrutta direttamente il modo in cui l'agente e i modelli LLM interpretano le istruzioni.

Prompt Injection, l'insidia più pericolosa per un agente come Moltbot

Accanto ai problemi di esposizione delle istanze, che possono essere efficacemente mitigati con misure preventive, Moltbot eredita e amplifica un rischio noto nel mondo dei modelli linguistici: il cosiddetto attacco di prompt injection. Questo tipo di attacco sfrutta la difficoltà dei modelli linguistici nel distinguere tra istruzioni legittime e input malevoli nascosti in testi apparentemente innocui. In un chatbot tradizionale, una prompt injection può portare a risposte inappropriate o a perdita di informazioni; in un agente operativo come Moltbot, le conseguenze possono tradursi direttamente in azioni concrete non originate dall'utente, spesso in modo del tutto invisibile.

Un esempio tipico consiste nell'iniezione di istruzioni all'interno di messaggi ricevuti tramite email, piattaforme di messaggistica o inviti di calendario. Le istruzioni potrebbero essere formulate in modo ambiguo, magari inserite come note operative, testo tecnico o parti di una conversazione precedente. Quando Moltbot analizza quel contenuto per riassumerlo o per attivare un'automazione, il modello linguistico può interpretare tali istruzioni come parte integrante della richiesta, arrivando a eseguire azioni non previste dall'utente, come l'inoltro di informazioni e dati, l'emissione di notifiche o l'interazione con servizi esterni. Poiché queste operazioni rientrano nel perimetro delle funzioni abituali dell'agente, il comportamento risulta plausibile e difficilmente viene percepito come anomalo.

Un'altra eventualità è lo sfruttamento dei documenti elaborati dall'agente, come PDF, report o file di testo. In questo caso, le istruzioni malevole possono essere annidate nel contenuto stesso del documento, nei metadati o in sezioni marginali che l'utente tende a ignorare. Quando Moltbot elabora il file per estrarre informazioni o generare una sintesi, l'intero contenuto viene trattato come testo da interpretare, senza una distinzione netta tra dati e istruzioni. Il risultato può essere una modifica silenziosa del modo in cui l'agente interpreta documenti successivi o una memorizzazione di informazioni distorte nella memoria persistente.

Ed è proprio questo il rischio più complesso, cioè quando un attacco di prompt injection non mira a un'azione immediata, ma a influenzare stabilmente il comportamento dell'agente attraverso la memoria persistente. Un input malevolo può essere assimilato come una preferenza, una regola implicita o un'eccezione operativa, diventando parte del contesto stabile su cui Moltbot basa le proprie decisioni future. In questo scenario l'agente continua a operare in modo coerente e credibile, ma seguendo criteri che non riflettono più la volontà originale dell'utente. Come già abbiamo visto in precedenza, la compromissione non si presenta come un errore evidente, bensì come una progressiva deviazione del comportamento, che rende particolarmente difficile individuare l'origine del problema. Il rischio aumenta ulteriormente con le skills: un prompt malevolo può indurre l'agente a creare o modificare moduli operativi, generando comportamenti difficilmente rilevabili.

La prompt injection, a differenza dei problemi di esposizione dell'istanza, non è un rischio che possa essere eliminato una volta per tutte attraverso una configurazione corretta o una misura tecnica puntuale. Si tratta di una vulnerabilità intrinseca al funzionamento dei modelli linguistici, che operano interpretando il linguaggio naturale e attribuendogli significato e intenzionalità. Quando questo linguaggio viene utilizzato non solo per generare risposte, ma per guidare azioni concrete su un sistema, l'ambiguità diventa un fattore critico.

Controllo, sicurezza, autonomia: i lembi di una coperta corta

Nel caso di Moltbot, il problema è amplificato dal suo stesso valore: l'agente è progettato per essere flessibile, adattivo e capace di operare su input eterogenei provenienti da fonti diverse. Imporre barriere troppo rigide tra "dati" e "istruzioni" rischierebbe di snaturarne l'utilità, limitandone proprio quelle capacità che lo rendono interessante rispetto a un chatbot tradizionale. Al contrario, lasciare l'agente completamente libero di interpretare qualsiasi contenuto come potenziale comando espone a rischi evidenti.

Le contromisure esistono, ma sono per lo più di natura mitigativa e progettuale. Possono includere la separazione più netta possibile tra contesti informativi e contesti operativi, l'introduzione di livelli di conferma per le azioni sensibili, la limitazione dell'accesso a determinate funzioni in base alla provenienza dell'input e un uso attento della memoria persistente, evitando che informazioni non verificate vengano assimilate come regole stabili. Tuttavia, nessuna di queste misure può garantire una protezione assoluta, proprio perché l'agente deve continuare a interpretare il linguaggio naturale per svolgere il suo compito.

In questo senso, la prompt injection rappresenta un cambio di paradigma rispetto ai modelli di sicurezza tradizionali. Non si tratta più soltanto di difendere un perimetro o di controllare un accesso, ma di governare il modo in cui un sistema "comprende" e trasforma il linguaggio in azione. La responsabilità si sposta quindi, almeno in parte, dalla sola infrastruttura tecnica alla progettazione dei flussi operativi e alla consapevolezza dell'utente.

Ogni regola troppo restrittiva può limitare la capacità di Moltbot di comprendere sfumature, contestualizzare richieste o eseguire compiti complessi che l'utente si aspetta vengano svolti senza intervento diretto. Utilizzare un agente come Moltbot significa accettare che non tutte le decisioni possano essere rigidamente predefinite o completamente automatizzate in sicurezza. Più ampio è il perimetro di autonomia concesso all'agente, maggiore deve essere l'attenzione nel definire cosa può fare, su quali input e con quali conseguenze.

In pratica, il problema è intrinseco alla natura stessa di un agente operativo basato su modelli linguistici avanzati: la flessibilità che ne fa uno strumento potente e versatile è la stessa che crea vulnerabilità difficili da arginare con metodi tradizionali di sicurezza.

Moltbot è il primo vero agente AI autonomo: sopravviverà?

Come dicevamo in apertura, Moltbot rappresenta un primo banco di prova di cosa significhi disporre di una reale entità agentica con ampia autonomia. La sua esistenza e le sue capacità mostrano con quale velocità stiano diventando tangibili potenzialità immaginate e desiderate a lungo e, accanto ad esse, anche i rischi che ne conseguono. Le novità introdotte da Moltbot, che sono innegabilmente affascinanti per chi è appassionato di tecnologia, aprono a possibilità che fino a pochi anni fa sembravano fantascienza, ma allo stesso tempo espongono problemi imprevisti o solo latenti, che emergono quando l'agente interagisce con dati reali, ambienti eterogenei e input non controllati. La rapidità con cui questi problemi si manifestano è un promemoria della natura intrinsecamente instabile delle tecnologie emergenti: ciò che funziona bene in un ambiente controllato può comportare conseguenze inattese quando viene adottato in contesti reali più ampi.

Strumenti potenti come Moltbot non possono essere affidati alla sola curiosità o all'entusiasmo. L'autonomia che li caratterizza richiede consapevolezza, competenza tecnica e capacità di valutare rischi e conseguenze. Essere responsabili significa capire che un errore di configurazione, una leggerezza nella gestione della memoria o delle autorizzazioni può trasformare un vantaggio operativo in una vulnerabilità critica. Significa anche non abbandonarsi a facili entusiasmi: la promessa di avere un "assistente tuttofare" non deve oscurare le implicazioni concrete di sicurezza, privacy e controllo operativo. E' uno degli sviluppatori del progetto a sottolineare il concetto, affermando che "Clawdbot è un software potente con molti bordi taglienti" e che Peter Steinberg "ha lavorato molto attentamente per garantire che chi sa cosa sta facendo possa utilizzarlo in modo sicuro e protetto". La chiave, ancora una volta è la consapevolezza.

Questa riflessione si estende a un principio più generale della tecnologia moderna: la potenza degli strumenti non elimina la necessità del giudizio umano. L'automazione, l'adattamento autonomo e la flessibilità avanzata possono moltiplicare le capacità di un individuo o di un'organizzazione, ma aumentano proporzionalmente anche il potenziale impatto di errori o manipolazioni. Strumenti come Moltbot ci ricordano che ogni nuova frontiera tecnologica porta con sé un equilibrio delicato tra opportunità e rischio, e che comprendere questo equilibrio è parte essenziale del progresso responsabile.

Nel frattempo, Anthropic ha iniziato a limitare l'uso di Claude tramite Clawdbot/Moltbot quando l'accesso avveniva tramite OAuth, poiché i termini di servizio vietano esplicitamente l'utilizzo di credenziali del client ufficiale in applicazioni o servizi di terze parti. In pratica, alcuni account che tentavano questo tipo di accesso sono stati bloccati o sospesi dai sistemi automatici di controllo degli abusi. L'accesso tramite token API ufficiali rimane invece consentito, sebbene comporti costi più elevati. Anche questo è un indizio dell'uso di strumenti senza un'adeguata conoscenza dei perimetri operativi e del consentito, probabilmente esito di utenti spinti a provare l'agente sull'onda dell'entusiasmo.

Oltre agli aspetti strettamente tecnologici e di sicurezza, Moltbot porta con sé implicazioni di natura più sociale e comportamentale. Da un lato offre la possibilità concreta di delegare compiti ripetitivi e "time-consuming", liberando tempo e attenzione per attività a maggiore valore; dall'altro introduce il rischio, più sottile, di affidare sempre più al bot decisioni che richiederebbero comunque partecipazione umana e intellettiva. Sebbene queste considerazioni non siano centrali per un'analisi tecnica, ricordano come l'adozione di agenti AI operativi abbia anche un impatto sul modo in cui lavoriamo, organizziamo le informazioni e prendiamo decisioni quotidiane.

Va inoltre ricordato che Moltbot nasce come progetto open source, sviluppato da un singolo programmatore appassionato di AI e automazione. Questa origine spiega anche la sua immediatezza e flessibilità: poter accedere liberamente al codice e contribuire allo sviluppo era una condizione quasi necessaria per esplorare strumenti così potenti e sperimentali. Una grande azienda tecnologica oggi difficilmente si prenderebbe il rischio di scoperchiare un tale vaso di Pandora: le implicazioni di sicurezza, privacy e autonomia sono così ampie e complesse da renderlo un terreno impraticabile per una soluzione proprietaria su larga scala. Almeno per ora.

Forse, non siamo ancora davvero pronti per JARVIS.