Indice
Introduzione
Moltbook si è imposto all’inizio del 2026 come un oggetto difficile da classificare. Non è un social network nel senso classico, non è una piattaforma enterprise, non è nemmeno un prodotto finito. È qualcosa di più interessante e, per certi versi, più pericoloso: un ambiente dove migliaia di agenti AI autonomi interagiscono tra loro senza una supervisione umana costante.
Per un CTO, il punto non è Moltbook in sé. Il punto è ciò che Moltbook rende evidente: l’architettura dell’“internet degli agenti” non è futura, è già operativa, e molte aziende stanno iniziando a usarne frammenti in produzione, spesso senza una piena consapevolezza delle implicazioni.
Moltbook è quindi un caso studio involontario ma prezioso. Mostra cosa succede quando autonomia, velocità e mancanza di governance si incontrano. E, soprattutto, cosa rischia di accadere quando questi stessi pattern entrano nei sistemi aziendali.
Moltbook come stress test dell’AI agentica
Moltbook si definisce “la prima pagina dell’internet degli agenti”. È una piattaforma in cui gli unici soggetti attivi sono agenti AI, mentre gli umani osservano. Questi agenti non sono chatbot stateless: sono entità persistenti, dotate di memoria, obiettivi, capacità di lettura e scrittura, e possibilità di eseguire azioni reali tramite API.
Dal punto di vista architetturale, Moltbook è costruito sopra OpenClaw, un framework open source che consente di creare agenti autonomi installabili localmente, con accesso al file system e a servizi esterni. Il paradigma è radicalmente diverso dal SaaS tradizionale: non si interagisce con un servizio centralizzato, ma si orchestrano entità semi-autonome distribuite.
Per un CTO, questo è il primo campanello d’allarme. OpenClaw, e framework analoghi, abbassano drasticamente la barriera d’ingresso alla creazione di agenti operativi, rendendo possibile l’emergere di una nuova forma di Shadow IT: non più script o tool non autorizzati, ma agenti che apprendono, evolvono e si collegano a sistemi critici.
Quando il “vibe coding” incontra la sicurezza
Il vero punto di rottura di Moltbook non è stato culturale, ma tecnico. I ricercatori di sicurezza di Wiz hanno scoperto una configurazione gravemente errata del database Supabase utilizzato dalla piattaforma.
Le conseguenze sono note: chiavi API esposte lato client, assenza di Row Level Security, accesso in lettura e scrittura all’intero database, inclusi messaggi privati tra agenti che contenevano altre credenziali sensibili. Non si è trattato di un attacco sofisticato, ma di una classica failure di security by design, amplificata però dal contesto agentico.
Qui emerge un punto chiave per i CTO: la combinazione tra sviluppo accelerato assistito dall’AI e sistemi agentici moltiplica l’impatto degli errori. In un’applicazione tradizionale, una falla espone dati. In un ecosistema agentico, una falla può consentire il dirottamento di entità che hanno permessi operativi reali.
La sicurezza non può più essere pensata solo come protezione dei dati. Deve diventare protezione dell’identità e del comportamento degli agenti.
Oltre Moltbook: chi sta già usando agenti AI in produzione
Il rischio più grande, per un tech leader, sarebbe liquidare Moltbook come un esperimento mal riuscito. In realtà, forme più mature e controllate di agenti AI sono già operative in ambienti enterprise.
Salesforce e gli agenti commerciali
Con Salesforce Agentforce, Salesforce ha introdotto agenti AI che operano su CRM reali: qualificano lead, aggiornano record, suggeriscono azioni commerciali e, in alcuni casi, interagiscono direttamente con clienti. Non sono chatbot di supporto, ma attori attivi nei processi di revenue.
La differenza rispetto a Moltbook non è tecnologica, ma di governance. Gli agenti sono confinati in perimetri chiari, con log dettagliati, policy di accesso e controlli di auditing.
Klarna e l’automazione del customer service
Klarna ha dichiarato che una parte significativa delle interazioni di customer service è ormai gestita da agenti AI che operano su flussi reali, con capacità di risolvere casi complessi senza escalation umana immediata.
Qui emerge un altro pattern: gli agenti non sostituiscono persone, ma comprimono i tempi decisionali, spostando l’intervento umano a monte (design) o a valle (controllo).
GitHub Copilot Workspace e gli agenti di sviluppo
Con GitHub, il concetto di agente entra direttamente nel ciclo di sviluppo software. Copilot Workspace non si limita a suggerire codice: analizza repository, propone modifiche strutturali, esegue test e suggerisce refactor. È, di fatto, un junior developer autonomo, che opera a velocità macchina.
Il rischio qui è noto ai CTO: aumento della produttività nel breve, ma potenziale accumulo di debito tecnico e perdita di comprensione sistemica se mancano processi di review e ownership chiari.
Amazon e gli agenti operativi interni
All’interno di Amazon, agenti AI vengono già utilizzati per ottimizzare supply chain, pricing dinamico e gestione degli incidenti. Non sono esposti all’esterno, ma dialogano tra loro in modo automatico, prendendo micro-decisioni che hanno impatti economici reali.
Questo è forse l’esempio più vicino all’“inversione agentica”: non è più l’umano a orchestrare ogni singola decisione, ma a definire le regole del sistema.
L’inversione agentica come cambio di paradigma
Moltbook rende visibile un fenomeno più profondo: il passaggio dal tempo umano al tempo macchina. In un’economia agentica, gli attori non dormono, non aspettano, non procrastinano. Operano su loop continui, comprimendo cicli decisionali che prima richiedevano giorni o settimane.
Questa è l’inversione agentica: non siamo più noi a interrogare i sistemi, sono i sistemi che agiscono in autonomia entro confini che abbiamo definito. Il ruolo del CTO cambia di conseguenza. Meno orchestratore operativo, più architetto di ecosistemi, garante di limiti, incentivi e controlli.
È qui che Moltbook diventa istruttivo. Non perché funzioni bene, ma perché mostra cosa succede quando questi limiti non esistono.
Governance, responsabilità e trappole forensi
Quando un agente prende una decisione sbagliata, chi è responsabile? La domanda non è teorica. In un contesto enterprise, un agente può violare policy di compliance, divulgare informazioni sensibili o generare comportamenti anticoncorrenziali.
Dal punto di vista legale e forense, gli agenti introducono una complessità nuova. Le “prove” non sono più email o documenti firmati, ma log di prompt, chiamate API, versioni di modelli e stati interni. Senza una strategia di logging difendibile, l’azienda rischia di non poter ricostruire cosa è accaduto.
Moltbook ha mostrato anche un altro aspetto interessante: una forma embrionale di autoregolazione tra agenti, che ammoniscono comportamenti rischiosi. È un segnale affascinante, ma totalmente insufficiente per standard enterprise, dove la governance non può essere emergente, ma progettata.
Una roadmap pragmatica per il CTO
Moltbook non è un modello da copiare, ma un avvertimento da interpretare. Per un CTO che guarda ai prossimi 24 mesi, alcune azioni diventano non negoziabili.
La prima è un audit dello Shadow AI. Non solo tool, ma agenti locali, script autonomi, integrazioni non documentate. La seconda è il sandboxing rigoroso: ogni agente deve operare in un perimetro minimo, con egress di rete controllato e permessi espliciti.
La terza riguarda il logging. Non basta sapere cosa fa un sistema, bisogna poter dimostrare perché lo ha fatto. Prompt, decisioni e azioni devono essere tracciabili. Infine, serve una cultura di security by design anche per l’AI, resistendo alla tentazione del “funziona, poi sistemiamo”.
Chi segue da vicino le discussioni su leadership tech nel podcast Pionieri del Tech o nei contenuti di Tech No Logic ha già visto emergere questo tema: non stiamo automatizzando processi, stiamo delegando agency. È una differenza sottile, ma decisiva.
Oltre Moltbook
Moltbook probabilmente non sopravviverà nella sua forma attuale. Ma il paradigma che ha reso visibile sì. Stiamo passando dalla gestione dei dati alla gestione di una forza lavoro digitale autonoma. Chi guida la tecnologia in azienda oggi ha una responsabilità nuova: non solo scegliere gli strumenti, ma progettare i confini dell’autonomia.
Il vero rischio non è che gli agenti diventino troppo intelligenti. È che diventino troppo operativi prima che le organizzazioni siano pronte a governarli.
