Come rendere sicuro Moltbot (ex Crawdbot) con Cloudflare Moltworker

Gli agenti AI autonomi come Moltbot (in origine Crawdbot) rappresentano un salto significativo rispetto ai tradizionali chatbot: non si limitano a rispondere a input testuali, ma eseguono azioni, prendono decisioni, interagiscono con sistemi esterni e mantengono uno stato persistente nel tempo. Proprio questa capacità operativa, tuttavia, introduce una superficie di rischio che va ben oltre quella dei modelli linguistici tradizionali.

D’altra parte, come abbiamo spiegato nell’articolo citato in apertura, Moltbot non è affatto un Large Language Model (LLM). Anzi, per funzionare ha bisogno di un modello AI di terze parti (OpenAI GPT, Anthropic Claude,…) oppure di un LLM in esecuzione in locale, ad esempio tramite il runner Ollama.

Cloudflare: buona l’idea di Moltbot ma i problemi di sicurezza sono importanti

Moltbot nasce come progetto open source orientato all’automazione personale: può leggere email, inviare messaggi, interrogare API, navigare il Web e orchestrare flussi complessi sulla base di istruzioni in linguaggio naturale.

Nella sua incarnazione originale, però, l’esecuzione avviene su macchine locali o su server sempre accesi, spesso con privilegi elevati, accesso diretto al file system e chiavi API memorizzate in chiaro. Caratteristiche che fin da subito hanno sollevato preoccupazioni concrete in termini di sicurezza.

È in questo contesto che nasce Moltworker: non come semplice porting su Cloudflare Workers, ma come tentativo di confinare un agente AI potenzialmente pericoloso all’interno di un perimetro di sicurezza rigoroso, sfruttando isolamento, controlli di accesso e osservabilità nativi della piattaforma Cloudflare.

In figura, lo schema di funzionamento ad alto livello di Moltworker (fonte: Cloudflare).

I problemi di sicurezza storici di Moltbot (ex Crawdbot)

Quando il progetto era ancora noto come Crawdbot, la comunità di sicurezza aveva già evidenziato alcuni punti critici.

Il primo problema riguarda l’esecuzione di codice dinamico. Moltbot può generare ed eseguire codice come parte del proprio processo decisionale. In ambienti tradizionali, questo significa eseguire codice non deterministico su una macchina con accesso a rete, file system e segreti applicativi. Un prompt malevolo, una risposta inattesa del modello o una catena di tool invocation mal progettata possono trasformare l’agente in un vettore di compromissione.

Un secondo aspetto critico è la gestione delle credenziali. Moltbot necessita di chiavi API per modelli AI, servizi di messaggistica, email e integrazioni varie. Nelle configurazioni originali, queste credenziali risiedono spesso all’interno di variabili d’ambiente persistenti su sistemi non isolati, aumentando l’impatto di una fuga di dati o di un accesso non autorizzato.

C’è poi il tema della persistenza dello stato. Un agente che mantiene memoria conversazionale e storici operativi può accumulare informazioni personali, riservate e sensibili nel corso del tempo. Se questa memoria risiede su un’unità locale o su database non segmentati, il rischio di esfiltrazione cresce in modo proporzionale alla durata dell’esecuzione.

Infine, Crawdbot/Moltbot soffre di un problema architetturale più sottile ma fondamentale: assenza di confini di sicurezza chiari tra agente, runtime e infrastruttura ospitante. In pratica, l’agente è sovrapponibile con il sistema sottostante, non un processo confinato al suo interno.

Moltworker è la risposta architetturale di Cloudflare

Come si evince dal post tecnico pubblicato sul blog dell’azienda, gli ingegneri Cloudflare hanno apprezzato molto l’idea alla base di Crawdbot/Moltbot.

Per questo si sono prodigati nello sviluppare Moltworker, una soluzione che nasce per risolvere i problemi di Moltbot non con patch puntuali, ma con un cambio del modello di esecuzione. L’idea centrale è separare nettamente il piano di controllo dal piano di esecuzione dell’agente, delegando a Cloudflare il ruolo di guardiano dell’infrastruttura.

Il cuore di Moltworker è un Cloudflare Worker che funge da orchestratore. Il Worker non esegue direttamente Moltbot, ma crea e gestisce sandbox isolate tramite Sandbox SDK. Ogni istanza dell’agente gira in un ambiente effimero, senza accesso diretto al runtime del Worker né alla rete globale se non attraverso interfacce esplicitamente consentite.

Un tale livello di isolamento permette di ridurre drasticamente l’impatto di eventuali comportamenti anomali dell’agente. Anche se Moltbot generasse codice malevolo o tentasse operazioni non previste, l’effetto rimane confinato alla sandbox, che può essere distrutta e ricreata senza compromettere il sistema ospitante.

Cosa sono i Cloudflare Workers e a che cosa servono

Come abbiamo spiegato a suo tempo nell’articolo dedicato alle applicazioni Web serverless, i Cloudflare Workers sono un ambiente di esecuzione progettato per far girare codice applicativo direttamente sull’infrastruttura edge globale di Cloudflare, senza la necessità di gestire server, macchine virtuali o container.

I Workers utilizzano un runtime leggero basato su sandbox isolate, che consente tempi di avvio quasi istantanei e un consumo di risorse estremamente contenuto. Il codice è eseguito il più vicino possibile all’utente finale, riducendo la latenza e permettendo di intercettare, modificare o generare traffico HTTP in modo programmabile.

Dal punto di vista tecnico, il runtime espone API Web standardizzate (Fetch, Streams, Crypto, WebSockets) e assicura crescente compatibilità con l’ecosistema Node.js, rendendo possibile l’esecuzione di applicazioni complesse pur mantenendo forti garanzie di isolamento.

Ogni Worker opera in un contesto fortemente protetto, senza accesso diretto al sistema operativo sottostante, caratteristica che li rende particolarmente adatti a eseguire logica non completamente affidabile, come nel caso degli agenti AI autonomi orchestrati da Moltworker.

Gestione sicura delle chiavi e controllo delle interazioni AI

Un elemento tecnico particolarmente rilevante è l’integrazione con Cloudflare AI Gateway. Grazie all’uso di Moltworker, Moltbot non comunica mai direttamente con i provider di modelli AI. Tutte le richieste passano attraverso il gateway, che funge da proxy controllato.

Lo schema proposto da Cloudflare risolve due problemi importanti. Da un lato, le chiavi API non sono mai esposte all’agente; dall’altro, diventa possibile applicare politiche di rate-limiting, logging e auditing sulle chiamate AI. In uno scenario in cui un agente potrebbe essere manipolato per generare traffico eccessivo o costoso, questa intermediazione rappresenta una barriera fondamentale.

Dal punto di vista della sicurezza operativa, il gateway consente anche di sostituire modelli o provider senza modificare il codice dell’agente, riducendo il rischio di dipendenze rigide da servizi esterni compromessi o non più affidabili.

Automazione senza fiducia implicita: come Moltworker riduce la superficie di attacco

In Moltworker, sia la persistenza dello stato sia le interazioni più delicate lato agente AI sono deliberate­mente spostate al di fuori del runtime di esecuzione, riducendo la fiducia accordata al codice dell’agente stesso.

La memoria operativa di Moltbot non risiede su file system locali o persistenti, ma viene conservata in Cloudflare R2, uno storage a oggetti esterno al ciclo di vita delle sandbox, accessibile esclusivamente tramite API controllate. In questo modo lo stato può essere mantenuto tra sessioni successive senza concedere la possibilità di manipolazioni.

Lo stesso principio di separazione vale per la navigazione Web: anziché eseguire un browser headless all’interno dell’ambiente dell’agente, Moltworker delega queste operazioni a Cloudflare Browser Rendering, un servizio isolato che consente automazioni Web senza esporre il sistema sottostante a exploit o contenuti malevoli.

A completare il modello, l’accesso amministrativo all’agente è protetto da Cloudflare Access, che applica autenticazione forte e politiche Zero Trust, impedendo l’esposizione diretta dell’agente su Internet e garantendo che ogni interazione avvenga sotto il controllo umano.

Perché gli agenti AI devono essere trattati come codice ostile

Moltworker non elimina tutti i rischi legati agli agenti AI, ma introduce una lezione architetturale chiara: non è realistico rendere “sicuro” un agente potente fidandosi del suo comportamento interno. La sicurezza deve essere imposta dall’esterno, attraverso isolamento, intermediazione e controllo delle superfici di interazione.

In questo senso, Moltworker va oltre Moltbot stesso. Mostra come gli agenti AI possano essere trattati efficacemente come entità inaffidabili, simili a workload potenzialmente ostili, pur continuando a offrire funzionalità avanzate.

Quello di Cloudflare è un modello che potrebbe diventare sempre più rilevante man mano che questi sistemi passeranno da esperimenti personali a componenti strutturali di infrastrutture reali.

Il repository GitHub di Cloudflare Moltworker contiene le istruzioni dettagliate per avviare l’installazione del middleware che permette di avviare un’istanza sicura di Moltbot.