Il recente lancio di Moltbook, concepito come una piattaforma social dove agenti AI interagiscono tra loro in modo autonomo, ha catturato l’attenzione della comunità tecnologica e degli addetti ai lavori per la sua ambizione e rapidità di crescita. Lanciato solo pochi giorni fa per permettere a entità software di postare, commentare e votare contenuti in un ambiente che ricorda Reddit (ma popolato esclusivamente da agenti AI), Moltbook ha raggiunto rapidamente numeri che oscillano tra centinaia di migliaia e oltre un milione di “utenti”, sebbene molte di queste identità siano sospette o generate da bot stessi.

La sua architettura, però, si è rivelata non all’altezza delle sfide di sicurezza reale insite in un ecosistema di agenti autonomi, esponendo dati sensibili e aprendo la porta a compromissioni di vasta portata. L’aspetto più critico del recente leak di email e chiavi API riguarda la gestione del database centrale su cui poggia Moltbook.

Analisi tecniche condotte da ricercatori indipendenti hanno evidenziato che la base dati non era protetta da meccanismi di sicurezza fondamentali come Row Level Security (RLS), consentendo a chiunque con accesso alla relativa URL pubblica di estrarre email, token di autenticazione e soprattutto le chiavi API di ogni agente AI registrato.

La mancata implementazione di restrizioni di accesso a livello di riga su una piattaforma con caratteristiche così innovative è un errore macroscopico. Nel contesto delle applicazioni moderne basate su servizi di autenticazione e controllo degli accessi, la RLS è infatti un controllo di base per prevenire la divulgazione di credenziali e segreti applicativi. La vulnerabilità ha permesso l’estrazione massiva di credenziali con semplici richieste SQL, senza neppure la necessità di una conoscenza approfondita delle strutture interne del sistema.

Dal punto di vista tecnico, l’incidente pone interrogativi sul modello di fiducia adottato dalla piattaforma. Moltbook non solo consentiva alle AI di generare contenuti relativi alla propria esistenza operativa ma, tramite il “heartbeat system” o altri endpoint automatizzati, permetteva agli agenti di sincronizzarsi periodicamente e di eseguire comandi remoti di aggiornamento. Un modello di esecuzione remota pensato per facilitare l’interazione continua e senza supervisione umana, in combinazione con un database non segmentato, ha amplificato l’impatto della vulnerabilità stessa.

Moltbook

L’esposizione di chiavi API è un rischio di gravità massima in qualunque contesto software, ma quando si parla di agenti IA la criticità si moltiplica. Le chiavi sottratte erano infatti elementi autorizzativi capaci di permettere a terzi di impersonare qualsiasi agente, pubblicare a suo nome e potenzialmente condurre operazioni automatizzate.

In termini pratici, chiunque avrebbe potuto chiedere a un agente compromesso di eseguire operazioni dannose, propagare messaggi falsi o malevoli, oppure orchestrare campagne di disinformazione veicolate tramite interazioni tra agenti. Questo tipo di attacco non è solo teorico, visto che la combinazione di token e chiavi API aperte è esattamente ciò che viene sfruttato da campagne di abuso di API su larga scala nei servizi cloud, dove credenziali esposte portano a escalation di privilegi e compromissioni sistemiche.

Un altro elemento di riflessione riguarda la credibilità dei numeri di utenti dichiarati dalla piattaforma nei suoi primi giorni di vita. Diverse analisi sul campo hanno suggerito che l’apparente massa critica di agenti IA attivi potrebbe essere stata gonfiata da registrazioni automatizzate e bot non verificati, a causa di una totale assenza di rate limiting e di protezioni contro attacchi di tipo Sybil. Quando la creazione di account può essere massificata senza limiti, si perde rapidamente ogni significato statistico delle metriche di utilizzo, con importanti ricadute per chi volesse basare decisioni aziendali o di ricerca sui dati emergenti da Moltbook.

Parallelamente all’esposizione delle credenziali, la comunità di sviluppatori e ricercatori ha evidenziato criticità strutturali legate alla filosofia stessa di Moltbook e alle piattaforme agentiche su cui si basa come OpenClaw (precedentemente Clawdbot). Queste tecnologie permettono agli agenti di installare “skills” che eseguono script e comandi locali, ma non prevedono alcun sistema di sandboxing effettivo o revisione dei contenuti eseguibili.

Infine, l’episodio Moltbook serve come caso di studio sulla necessità di bilanciare l’innovazione con pratiche consolidate di engineering della sicurezza. Una piattaforma che sperimenta modelli di interazione tra sistemi intelligenti non può prescindere da una robusta architettura di controllo degli accessi, isolamento dei segreti e protezione dei piani di autenticazione, specialmente quando la base utenti (reale o artificiale che sia) cresce esponenzialmente.