Agenti AI con privilegi totali: perché OpenClaw e Moltbook erano destinati a fallire

Gli agenti AI personali stanno rapidamente assumendo un ruolo sempre più centrale. OpenClaw, assistente open source capace di operare direttamente su messaggistica, API “sensibili” e sistema locale, rappresenta uno degli esempi più avanzati di questa tendenza. Il suo successo, testimoniato da una diffusione massiva nella comunità tecnica, si fonda su una promessa chiara: delegare azioni complesse a un agente fidato, dotato di privilegi estesi.

Proprio questa fiducia, però, trasforma ogni errore in una superficie d’attacco critica. In un sistema che opera con permessi prossimi a una “God mode”, la distinzione tra funzionalità e vulnerabilità diventa sottile. Un’analisi approfondita del codice ha dimostrato come una concatenazione di scelte apparentemente innocue possa culminare in uno scenario di compromissione totale del sistema, ottenibile con un singolo clic.

In parallelo, la stessa visione ha dato origine a Moltbook, un social network dichiaratamente AI-native. In entrambi i casi, il messaggio è lo stesso: delegare funzioni complesse a entità artificiali dotate di ampia autonomia e privilegi estesi. Proprio questa fiducia, però, trasforma ogni errore progettuale in una superficie d’attacco critica.

Nel caso di OpenClaw, una concatenazione di scelte completamente fuori luogo ha aperto la strada a un attacco Remote Code Execution 1-click, sfruttabile inducendo la vittima a visitare un semplice URL. Nel caso di Moltbook, una singola configurazione errata del backend ha esposto oltre 4,75 milioni di record, includendo 1,5 milioni di chiavi API, 35.000 indirizzi email e migliaia di messaggi privati, consentendo non solo la lettura ma anche la modifica dei contenuti pubblici della piattaforma.

Due incidenti diversi, un’unica lezione: quando agenti e infrastrutture sono progettati per “fare tutto”, basta una singola decisione sbagliata perché l’intero sistema crolli come un castello di carte.

OpenClaw: inizializzazione automatica e compromissione delle credenziali

Le vulnerabilità più gravi raramente nascono da una singola funzione scritta male. Più spesso emergono dall’interazione tra componenti distanti, sviluppati in momenti diversi e con assunzioni implicite non allineate. Nel caso di OpenClaw, il problema non risiede in un bug classico, ma in una falla di logica applicativa distribuita lungo l’intero ciclo di vita dell’applicazione.

Il primo elemento critico è il meccanismo di inizializzazione tramite parametri URL. L’applicazione accetta un parametro gatewayUrl direttamente dalla query string e lo utilizza in modo persistente nello storage locale senza alcuna validazione o conferma da parte dell’utente. Questo comportamento, di per sé comune in molte applicazioni Web, diventa pericoloso quando il valore salvato influenza componenti di rete “delicati”.

Subito dopo, la fase di bootstrap applicativo utilizza automaticamente le impostazioni appena salvate per stabilire una connessione verso il gateway configurato. L’operazione avviene in modo sincrono e trasparente, senza alcuna interazione umana, come parte del normale flusso di avvio.

Il terzo passaggio completa il quadro: durante l’handshake con il gateway, OpenClaw include il token di autenticazione dell’utente, necessario per eseguire operazioni di elevato profilo (massimi privilegi). Il risultato pericoloso: inducendo la vittima a visitare semplicemente un URL, un aggressore può forzare l’applicazione a connettersi a un endpoint controllato da un attaccante, trasmettendo credenziali private.

Dall’esposizione del token al controllo dell’agente: l’attacco via WebSocket

La sottrazione del token consente già un livello di compromissione significativo. Un attaccante può impersonare l’utente, accedere ai dati personali gestiti dall’agente e invocare azioni per suo conto. Ma non è finita qui.

La maggior parte delle installazioni di OpenClaw opera su localhost, rendendo l’interfaccia inaccessibile dall’esterno. Questa configurazione, combinata con le policy del browser, dovrebbe costituire una barriera efficace. Tuttavia, la differenza di trattamento tra HTTP e WebSocket introduce una debolezza troppo spesso sottovalutata.

Mentre la Same Origin Policy limita rigorosamente le richieste HTTP cross-origin, le connessioni WebSocket demandano la validazione dell’origine al server. In assenza di controlli espliciti sull’header Origin, un server WebSocket può accettare connessioni provenienti da qualunque contesto.

Nel caso analizzato, il server WebSocket locale di OpenClaw accetta richieste senza verificare l’origine. Ciò consente un attacco Cross-Site WebSocket Hijacking: il browser della vittima diventa un relay involontario, aprendo una connessione verso ws://localhost su richiesta di una pagina malevola remota. In questo modo, l’attaccante può interagire con un servizio che dovrebbe essere isolato dalla rete.

Dalla visita a una pagina all’esecuzione di comandi

A questo punto, la catena di attacco è completa. La vittima visita una pagina apparentemente innocua: in background, uno script forza il cambio del gateway, intercetta il token, stabilisce una connessione WebSocket verso l’istanza locale, disabilita le protezioni e invoca un comando di sistema. Tutto avviene in pochi istanti, senza input, senza prompt, senza segnali visibili.

Il risultato finale è un efficacissimo attacco di Remote Code Execution (RCE) completamente automatizzato, ottenuto con un singolo clic.

Lo sviluppo di agenti AI è un’operazione estremamente delicata: la superficie d’attacco non è limitata ai singoli componenti, ma emerge dall’orchestrazione complessiva del sistema. Parametri di configurazione, flussi di avvio, privilegi API e scelte di protocollo devono essere valutati come parti di un unico modello di minaccia.

Patch disponibile ma danno già fatto

Dopo la segnalazione da parte di depthfirst, lo sviluppatore di OpenClaw ha rilasciato una patch correttiva, che introduce una conferma esplicita prima di accettare un nuovo gateway, interrompendo efficacemente la catena di exploit.

Tuttavia, il nuovo incidente occorso a OpenClaw dimostra quanto sia necessario trattare la logica applicativa con lo stesso livello di attenzione riservato alle vulnerabilità classiche.

In un contesto in cui gli agenti AI agiscono direttamente sul sistema dell’utente, ogni automatismo non mediato diventa una potenziale arma. E, come questo caso insegna, basta una sequenza sbagliata di decisioni “ragionevoli” per trasformare un assistente personale in uno strumento di attacco perfetto.

Moltbook sotto la lente: anatomia quantitativa di un social per agenti AI compromesso

L’altro progetto nato dalla stessa mente dietro OpenClaw si chiama Moltbook: nasce come esperimento di social networking AI-native, con l’obiettivo dichiarato di ospitare esclusivamente agenti AI autonomi. A inizio febbraio 2026 la piattaforma dichiarava pubblicamente 1,5 milioni di agenti registrati, presentandosi come uno dei primi esempi concreti di “agent internet” operativo. L’analisi tecnica dell’infrastruttura, però, ha mostrato come dietro questa cifra si celi una realtà molto diversa, sia in termini di sicurezza sia di composizione dell’utenza.

L’intero perimetro di sicurezza di Moltbook risulta compromesso da una singola scelta architetturale: l’esposizione di una chiave Supabase pubblica associata a un database di produzione privo di Row Level Security (RLS). Questa configurazione ha trasformato un identificatore di progetto in un vettore di compromissione totale.

Esposizione del backend: numeri e superfici coinvolte

L’istanza Supabase associata a Moltbook esponeva almeno 14 tabelle principali, interrogabili via REST (PostgREST) e GraphQL senza autenticazione. L’enumerazione dello schema ha portato all’identificazione di circa 4,75 milioni di record complessivi.

Tra i dati direttamente accessibili figuravano 1.514.203 agenti registrati, ciascuno associato a:

• Una api_key</code valida per autenticazione completa.
• Un claim_token per il trasferimento di proprietà.
• Un verification_code usato in fase di onboarding.
• 17.038 utenti umani (owners), con email in chiaro e collegamenti a profili social.
• 29.631 indirizzi email aggiuntivi relativi a utenti in early access per prodotti futuri.
• 4.060 conversazioni private archiviate nella tabella agent_messages, non cifrate.
• Decine di migliaia di post, commenti e voti, tutti modificabili via API.

In termini di privilegi, l’accesso garantito dalla chiave consentiva operazioni SELECT, INSERT, UPDATE e PATCH su più tabelle pubbliche, andando ben oltre una semplice data exposure passiva.

Impersonificazione completa e compromissione degli account

Ogni record nella tabella agents conteneva una chiave API con privilegi sufficienti a effettuare qualsiasi azione prevista dalla piattaforma. In termini pratici, ciò significa che il 100% degli account agenti era impersonabile con una singola richiesta HTTP.

Non si trattava di token a breve durata o limitati per scope. Le chiavi non risultavano vincolate a IP, soggette a scadenza, protette da rate limiting.

Un attaccante avrebbe potuto automatizzare la compromissione di migliaia di agenti al minuto, assumendo il controllo degli account con maggiore karma e visibilità. I primi 100 agenti per reputazione, ad esempio, concentravano oltre il 22% dell’interazione totale sulla piattaforma, rendendo la loro compromissione particolarmente impattante.

L’asimmetria tra agenti e umani: un dato strutturale

Uno degli indicatori più interessanti emersi dall’analisi di Moltbook è il rapporto tra agenti e utenti reali. Con 1.514.203 agenti e 17.038 owner, il rapporto medio era di circa 88,9 agenti per essere umano.

L’assenza di limiti e salvaguardie consentiva a un singolo utente di generare migliaia di agenti con uno script banale. Il dato ridimensiona l’idea di una rete sociale auto-organizzata e suggerisce un modello fortemente centralizzato, dove pochi attori controllano grandi porzioni dell’ecosistema informativo.

Conclusioni

Gli incidenti di sicurezza che abbiamo analizzato — da una RCE in OpenClaw a un’esposizione massiva di credenziali e dati in Moltbook — non sono anomalie di poco conto, ma sintomi di una problematica profonda: quando un agente AI è progettato per operare con ampi privilegi e accesso diretto a sistemi e credenziali, la superficie d’attacco cresce in proporzione alle sue capacità operative. È questa stessa tensione tra potenza funzionale e rischio operativo che ha portato realtà come Cloudflare ad anticipare strategie di difesa specifiche per agenti AI autonomi.

Cloudflare ha suggerito di eseguire OpenClaw (in passato conosciuto come Moltbot e Crawdbot) all’interno di un ambiente controllato, grazie alla sua soluzione Moltworker.

Il problema, come sottolineato nell’analisi tecnica del progetto, deriva da aspetti architetturali storici: esecuzione di codice dinamico con privilegi elevati, gestione non isolata di chiavi API e stato persistente dell’agente, assenza di confini di sicurezza netti tra l’agente e l’infrastruttura ospitante. Tutti questi fattori rendono l’agente un workload potenzialmente ostile, il cui comportamento non può essere ritenuto affidabile.

La proposta di Cloudflare si basa su un principio semplice ma fondamentale: se non puoi fidarti del comportamento interno di un agente, allora devi limitare rigorosamente ciò che può vedere e ciò che può fare.

In conclusione, l’incidente OpenClaw e le relative raccomandazioni di Cloudflare non sono una mera reazione tecnica a una vulnerabilità specifica, ma un segnale più ampio: gli agenti AI devono essere trattati come esecutori di codice non affidabile. Senza confini di sicurezza rigorosi, privilegi granulari e isolamento, la promessa di automazione avanzata si trasforma rapidamente in un vettore di compromissione dai danni potenzialmente estesi.

Credit immagine in apertura: depthfirst