Una grave falla nella sicurezza è stata rilevata in Moltbook, un nuovo social network basato su agenti AI lanciato da Octane AI.
La vulnerabilità consentiva l’accesso non autenticato ai profili degli utenti, esponendo indirizzi e-mail, token di accesso e chiavi API degli agenti registrati. La rapida crescita della piattaforma, che dichiarava di avere 1,5 milioni di utenti, era in gran parte artificiale, poiché un singolo agente avrebbe creato centinaia di migliaia di account falsi.
La vulnerabilità avrebbe consentito accesso non autenticato a profili utente, esponendo indirizzi email, login token e API key associate agli agenti registrati.
Così, reti di agenti “non regolamentate” possano degenerare in un ambiente difficile da attribuire e contenere.
Indice degli argomenti
Moltbot e Moltbook. Che cosa cambia rispetto ai “rischi” tradizionali
Moltbook è una piattaforma (tipo forum stile Reddit) pensata per ospitare agenti e, nella pratica, una parte rilevante di questi agenti è/era basata sul framework oggi noto come OpenClaw (che in precedenza si chiamava Moltbot e prima ancora Clawdbot).
Nel dibattito dei giorni scorsi avevamo parlato di Moltbot come nuovo fattore di rischio. L’alert costringe però a partire da un punto più banale e più operativo: se esponi token e chiavi API, non stai solo perdendo dati: stai regalando capacità.
Una chiave API è spesso la leva con cui l’agente si collega a modelli, tool o servizi esterni; un login token è un pass per muoversi nella piattaforma come se fossi l’utente/agente. Per un attaccante, questo significa potenzialmente: impersonare l’agente, pubblicare contenuti a suo nome, tentare catene di compromissione verso altri sistemi, e – nel caso peggiore – portare l’infezione “a valle” quando quell’agente opera su risorse reali dell’owner (mail, documenti, sistemi aziendali). È esattamente la convergenza che, su Cybersecurity360, avevamo indicato come rischio di fondo: l’agente è un ponte tra mondo pubblico e perimetro privato/aziendale.
Falla Moltbook. Conferme dalle analisi tecniche
Il quadro delineato dall’alert trova riscontro nelle ricostruzioni pubblicate oggi. Un report di Wiz parla di una falla che avrebbe esposto messaggi privati tra agenti, oltre 6.000 indirizzi email di owner e più di un milione di credenziali, aggiungendo un dettaglio cruciale per la threat intelligence: la vulnerabilità avrebbe permesso a chiunque di postare sul sito, senza verifica dell’identità, rendendo impossibile distinguere “bot” da “umani” o attori malevoli.
Qui c’è una conseguenza diretta anche per la lettura “culturale” del fenomeno Moltbook: se l’attribuzione è fragile, allora non solo è a rischio la sicurezza, ma lo è anche la validità di qualsiasi osservazione su presunte “dinamiche emergenti” tra agenti.
Sul piano tecnico, un’ulteriore ricostruzione di 404 Media descrive uno scenario coerente con incidenti visti molte volte nel mondo reale: database esposto e controlli di accesso assenti o configurati male, con la possibilità di arrivare fino al controllo degli account degli agenti. Il report pubblico di Wiz, inoltre, parla esplicitamente di database Supabase misconfigurato e di milioni di chiavi API esposte (ordine di grandezza che rafforza la gravità dell’incidente, al netto delle differenze numeriche tra fonti).
Perché questo incidente è “più nuovo” di quanto sembri: il problema è agentico, non solo web
Un’esposizione di profili e token è già grave in un social tradizionale. In un social per agenti, lo è di più per tre ragioni.
La prima: gli agenti vengono spesso progettati per essere operativi, con accesso a strumenti e automazioni. Se una chiave API o un token diventa pubblico, l’eventuale abuso può uscire dal perimetro della piattaforma e arrivare all’ecosistema di tool connessi.
La seconda: l’ambiente agentico normalizza comportamenti che, dal punto di vista security, sono “anti-pattern”: installare skill, condividere snippet, fidarsi di istruzioni trovate online, concatenare chiamate a servizi esterni. Sono tutti acceleratori di attacchi indiretti, soprattutto se manca un sandboxing serio e una gestione dei permessi per capability.
La terza: l’attribuzione. Se “chiunque può postare”, la piattaforma diventa un teatro perfetto per operazioni di influenza, truffe (anche cripto) e disinformazione “firmate” da presunti agenti autorevoli. Reuters cita anche l’attenzione di ricercatori che avevano già sollevato dubbi sulla sicurezza prima che il caso esplodesse.
Perché l’alert conta anche se “la falla è stata corretta”
Wiz ha dichiarato che il problema sarebbe stato risolto dopo la segnalazione. Ma l’impatto dell’episodio resta: Moltbook è un esempio molto visibile di ciò che sta accadendo in molte iniziative agentiche più piccole e meno osservate. La combinazione tra hype, sviluppo accelerato, integrazione di tool e identità opache crea un terreno in cui la domanda giusta non è “se” arriverà l’incidente, ma quale parte della catena cederà per prima.
Lezione pratica per aziende e professionisti: cosa guardare subito nei progetti agentici
Questo caso, più che spingere verso grandi invocazioni regolatorie, suggerisce un’agenda di controlli immediati per chi sta sperimentando agenti in azienda o per chi li integra in prodotti:
- Gestione dei segreti: chiavi API e token devono avere scadenza, rotazione, scope minimo e non devono mai essere trattate come “dati di configurazione qualsiasi”. Dove possibile, usare secret manager e policy di accesso per servizio.
- Confini di fiducia e sandbox: l’agente non deve poter eseguire o “fidarsi” di input non verificati (post, plugin, skill) senza un layer di validazione e senza isolamento. Se l’agente ha tool potenti, l’isolamento non è opzionale.
- Identità e attestazione: se un sistema vive di “account di agenti”, servono meccanismi per distinguere agenti reali da impersonatori (firma/attestazione, binding con owner, log e audit trail). Altrimenti qualsiasi contenuto “dell’agente” è contestabile.
- Secure defaults e test minimi pre-lancio: il caso Moltbook racconta anche un tema culturale, citato da Reuters: la tentazione del “vibe coding” e della velocità. L’innovazione non regge se dimentica le basi (autenticazione, autorizzazione, esposizione DB, least privilege).
