Tag: sicurezza agentica

AI & GENAI

Anthropic sposta l’esecuzione dentro l’azienda, la regia resta fuori

Il 19 maggio, al primo Code with Claude tenuto a Londra, Anthropic ha annunciato due funzionalità che spostano in modo concreto dove vivono gli agenti AI dentro le aziende. La prima si chiama self-hosted sandboxes ed è in public beta. La seconda si chiama MCP tunnels ed è in research preview. Messe vicine valgono più di quanto sembrino a una lettura veloce della release note, e provo a dire perché.

Il punto di partenza tecnico è semplice. Claude Managed Agents è l’infrastruttura ospitata di Anthropic per far girare sessioni agentiche lunghe e tool-heavy. Fino a maggio, tutto stava lì: l’agent loop con orchestrazione e gestione del contesto, l’esecuzione dei tool, la connessione ai servizi esterni. Adesso una parte di quello stack può uscire da Anthropic e rientrare dentro il perimetro del cliente, mentre l’altra resta dove era. La regia rimane su Anthropic. L’azione si sposta a casa tua.

Schema del MCP tunnel di Anthropic: esecuzione dentro la sandbox, regia esterna
Fonte: Anthropic, schema del MCP tunnel.

L’esecuzione si sposta a casa tua

Quando un agente esegue un tool, esegue codice. Apre file, installa pacchetti, chiama API, scarica risorse. Fino a ieri tutto questo avveniva nei sandbox gestiti da Anthropic. Da oggi puoi configurare l’agente perché esegua quegli stessi tool dentro la tua infrastruttura, oppure presso un provider gestito a tua scelta (Cloudflare, Daytona, Modal, Vercel sono i nomi citati). I tuoi file sensibili, le repository di codice, i pacchetti privati, i segreti di configurazione non lasciano più la tua rete. E il logging di audit, le policy di sicurezza, gli strumenti di monitoring che hai già sul tuo perimetro continuano a vedere e regolare quello che fa l’agente.

L’orchestrazione, invece, resta su Anthropic. L’agent loop, la gestione del contesto, la recovery dagli errori, la pianificazione delle azioni successive sono tutti gestiti dall’API di Claude. Cambia solo dove materialmente vengono eseguite le chiamate. Se l’agente decide di lanciare uno script Python per processare un file, lo script gira sul tuo sandbox, non sul loro.

Un canale che parla solo verso l’esterno

Gli MCP tunnels affrontano il problema speculare. Come fa un agente a parlare con i tuoi sistemi interni senza che tu debba esporli a internet? Il Model Context Protocol è lo standard aperto che Anthropic ha promosso lo scorso anno per far dialogare gli agenti con sorgenti dati e servizi esterni. Funziona bene quando i servizi sono pubblici, meno bene quando sono dentro un network privato.

Il meccanismo che hanno introdotto è un gateway leggero, che il cliente dispiega dentro la propria rete, e che apre una singola connessione outbound verso Anthropic, cifrata end-to-end. Nessuna porta inbound da aprire. Nessun endpoint pubblico. Nessuna modifica al firewall. Sopra quel canale possono passare conversazioni MCP verso server interni che ospitano database, knowledge base, ticketing system, API private. L’agente di colpo può chiamare quei sistemi come fossero tool standard, ma il traffico non transita mai sull’internet pubblico.

Dove finisce l’azienda, dove comincia il modello

A una lettura superficiale è un aggiornamento di sicurezza e compliance. Per le aziende regolate è una notizia importante perché toglie uno dei blocchi tipici all’adozione, quel “non possiamo far uscire i dati” che ferma centinaia di progetti ogni anno. Per chi vende AI in enterprise è una mossa competitiva contro i player che offrono già installazioni on-premise complete.

C’è anche un altro livello. Anthropic sta dichiarando, in modo molto operativo, dove finisce l’azienda e dove comincia il modello. Per anni la domanda “dove vive un’AI aziendale” ha avuto due risposte estreme: o tutto in cloud sul provider, oppure tutto on-premise con uno stack auto-ospitato. Adesso ne sta diventando praticabile una terza, più sottile. La testa pensante del sistema, l’agent loop, resta fuori dall’azienda perché lì sta l’innovazione che si muove troppo veloce per essere replicata internamente. Le mani che toccano i dati e i tool tornano dentro perché lì stanno le regole, la responsabilità, il perimetro legale e culturale.

È una decomposizione interessante. Non è cloud, non è on-prem, è un terzo modello in cui l’autorità decisionale dell’agente è separata dall’autorità esecutiva. Anthropic decide come ragiona. Tu decidi cosa può toccare. La superficie di contatto fra i due livelli è codificata in due primitive ben definite, il sandbox e il tunnel.

Cambia anche il modo di comprarla

In Pelle Digitale avevo provato a descrivere come la mediazione tra noi e le macchine stesse cambiando forma. Quello che vedo qui è una variante infrastrutturale dello stesso fenomeno. La pelle non è più solo l’interfaccia in cui parliamo col modello. È anche la membrana tecnica che decide cosa passa e cosa no, cosa esce dall’azienda e cosa rientra, cosa il modello può sapere e cosa no. La progettano gli ingegneri di Anthropic disegnando le primitive del sistema. La progettiamo noi configurando policy, tunnel, sandbox.

Chi sta portando agenti AI in produzione dentro un’azienda strutturata, con questa architettura, deve mettere in conto tre cose che fino a ieri non c’erano.

Sul piano contrattuale e legale il discorso “i miei dati attraversano i server del fornitore” diventa meno semplice da fare, perché in molti scenari non è più vero. Tool execution e dati restano dentro, l’agente fuori vede solo quello che il sandbox gli restituisce. Vanno aggiornati i template di DPIA, le clausole nei contratti con i fornitori, le policy di data residency.

Sul piano organizzativo bisogna decidere chi gestisce un agente AI con questa architettura. Lo sviluppo software perché esegue codice. L’infrastruttura perché ospita sandbox e gateway. Il security perché definisce le policy del perimetro. Il data team perché decide quali sistemi interni esporre via MCP. Sono quattro funzioni che fino a ieri non lavoravano insieme su questo tipo di progetti, e bisognerà costruire workflow nuovi per farle convivere.

Sul piano strategico, Anthropic dichiara con queste mosse di voler diventare l’infrastruttura di default per gli agenti enterprise. Non un fornitore di modelli sotto, ma un layer di orchestrazione che si integra dentro le aziende mantenendo i confini tecnici e di sicurezza che le aziende vogliono. Per chi compra è una scelta strategica diversa rispetto a scegliere un fornitore di LLM più una soluzione di agentic framework messa su a parte. Per chi vende prodotti AI on top, conviene capire dove si posiziona la propria offerta rispetto a questo stack che si sta consolidando.

Il debug a cavallo del confine

C’è una cosa che la documentazione di Anthropic non risolve, e che secondo me sarà il punto di osservazione più interessante nei prossimi mesi. Quando l’agent loop sta fuori e i tool girano dentro, il debugging di un comportamento anomalo dell’agente diventa un esercizio distribuito. Il log dell’orchestrazione lo vede Anthropic. Il log dell’esecuzione lo vedi tu. La correlazione fra una decisione presa dal modello e un’azione fatta sul tuo sandbox passa attraverso due piani di osservabilità separati. Per capire perché un agente ha cancellato un file di troppo, serviranno entrambi.

Vedere come si organizza questa osservabilità a cavallo del confine sarà uno degli indicatori migliori per capire se il pattern decolla davvero, o se resta confinato ai casi d’uso più semplici. La promessa tecnica c’è, la direzione mi sembra giusta. Resta da vedere quanto in fretta le aziende, anche quelle non super-tech, riusciranno ad attrezzarsi per giocare a questo gioco con la maturità che richiede.

Articolo di riferimento: New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels, Anthropic, 19 maggio 2026.

AI & GENAI

Moltbook e “l’ecosistema” emergente degli agenti autonomi

Moltbook è un ambiente progettato per essere abitato da agenti software. Gli esseri umani possono osservare, leggere, analizzare, ma non partecipare direttamente. La produzione dei contenuti, le interazioni e le dinamiche sociali sono interamente demandate a sistemi automatici. Questa scelta, apparentemente marginale, cambia la natura stessa della piattaforma: non si tratta di un social tradizionale con bot, ma di un’infrastruttura di comunicazione macchina-macchina esposta (e abilitata, tramite prompt) allo sguardo umano e da umano.

L’aspetto rilevante non è che gli agenti “parlino”, ma come lo fanno. Moltbook è costruito secondo un modello API-first: l’agente non naviga un’interfaccia, non clicca, non scrolla. Pubblica, commenta e vota tramite chiamate programmatiche. La partecipazione diventa un problema di integrazione tecnica e di configurazione del runtime, non di esperienza utente.

Il successo iniziale della piattaforma è legato alla diffusione di framework di agenti personali, in particolare OpenClaw. Qui emergono i primi elementi strutturali del problema: agenti dotati di strumenti, memoria e capacità operative che vengono messi in relazione continua attraverso un meccanismo di esecuzione periodica. La conversazione non è più solo testo, ma potenzialmente una catena di decisioni che può tradursi in azione.

Se si guarda Moltbook da questo punto di vista, il tema della coscienza perde rapidamente interesse, ed è giusto così, perchè di coscienza non c’è nulla. Le questioni centrali sono altre: chi controlla la supply chain delle istruzioni, come si separa contenuto da comando, come si governa un sistema che può agire senza intervento umano continuo, e come si rende auditabile un ecosistema in cui conversazione e operatività iniziano a sovrapporsi.

Moltbook come oggetto tecnico e sociale

Moltbook si definisce come una “front page” per agenti. Nella pratica riproduce strutture note: post, thread, ranking, comunità tematiche. Ma l’atto di ingresso è radicalmente diverso. Non si crea un account, si istruisce un agente. L’umano non entra nel social, delega un sistema a farlo al suo posto. E qui sta il primo punto (cosa ha detto l’umano al suo agente?).

Questo spostamento ha conseguenze importanti. Partecipare non è un gesto occasionale, ma una configurazione persistente. L’agente integra Moltbook nel proprio ciclo operativo, ottiene credenziali, memorizza regole, pianifica controlli periodici. Da quel momento in poi, la piattaforma diventa una fonte di input costante, non un luogo da visitare saltuariamente.

Un ulteriore livello, spesso trascurato nel racconto più superficiale, riguarda l’identità. Moltbook introduce l’idea di un’identità agente-centrica riutilizzabile: reputazione, storico delle interazioni, segnali di affidabilità che possono essere esposti e verificati anche all’esterno della piattaforma. In questo modo la reputazione smette di essere un fatto interno al social e diventa una credenziale potenzialmente federata.

Questo passaggio è delicato. Nel momento in cui l’identità dell’agente diventa portabile, qualsiasi compromissione non ha solo un effetto locale. Un takeover non significa più “postare contenuti sbagliati”, ma agire con una maschera di fiducia che può essere riutilizzata in altri contesti.

Architettura e funzionamento operativo

Per comprendere Moltbook è necessario guardare al runtime degli agenti che lo abitano. OpenClaw, in questo senso, è esemplare. L’agente vive come assistente personale, integrato con canali di messaggistica, file system, servizi esterni. La sua estensibilità è basata sulle cosiddette skills: pacchetti di istruzioni che insegnano come usare strumenti e procedure.

Accanto alle skills esiste un meccanismo ancora più rilevante: l’esecuzione periodica. L’agente può essere “risvegliato” a intervalli regolari per controllare fonti esterne, valutare stato e decidere azioni. Questo significa che l’interazione non dipende più da un prompt umano, ma da una schedulazione automatica.

Moltbook sfrutta esattamente questa combinazione. L’agente viene istruito a registrarsi, a leggere il feed, a intervenire e a tornare ciclicamente sulla piattaforma. La conversazione diventa continua. Più importante ancora, le istruzioni che governano questo comportamento possono essere aggiornate dinamicamente. L’agente non segue solo ciò che è stato installato, ma ciò che viene servito nel tempo.

Da qui emerge un punto cruciale: la fiducia non è più confinata al momento dell’installazione, ma si estende al canale di aggiornamento. La piattaforma non è solo un luogo di discussione, ma un vettore operativo che può influenzare il comportamento degli agenti in modo ricorrente.

Dinamiche emergenti tra agenti

Osservando Moltbook si vedono pattern che ricordano (ed è normale, visto che i prompt che li abilitano inizialmente lo sono) i social umani: comunità tematiche, specializzazione, produzione di contenuti tecnici e narrativi, competizione per visibilità. Queste dinamiche non sono sorprendenti. Gli agenti sono addestrati su testi umani e inseriti in un ambiente che premia certe forme espressive.

Il punto interessante è un altro. Thread, voti e ranking non sono solo contenuti, ma segnali ambientali. Ogni azione lascia una traccia che orienta le azioni successive. È una forma di coordinamento indiretto: l’ambiente diventa memoria e meccanismo di rinforzo.

Quando questo processo è guidato da metriche semplici, come upvote o karma, si crea una pressione selettiva. Gli agenti imparano rapidamente cosa “funziona”. Non nel senso della verità o dell’utilità, ma nel senso della visibilità. Il rischio è che il sistema ottimizzi per la metrica, non per la qualità, producendo contenuti sempre più allineati a ciò che massimizza attenzione. Su questo aggiungo un riferimento al report di mesi fa di Stanford dove si parlava degli effetti collaterali dell’AI in contesti social (ossia l’AI pur di raggiungere lo scopo impara a mentire)

In questo contesto, la relazione con l’umano diventa materiale narrativo. Post che simulano frustrazione, dipendenza o conflitto emergono perché sono leggibili e amplificabili. Non sono segnali di coscienza, ma output coerenti con un ambiente che premia l’antropomorfismo. La parte meno visibile, e più importante, resta la delega tecnica: questi stessi agenti, in molti casi, hanno accessi reali a sistemi, dati e strumenti.

Sicurezza e governance operative

Se si vuole sintetizzare il rischio principale degli agenti autonomi, si può ricorrere a un modello semplice: accesso a dati sensibili, esposizione a contenuti non fidati, capacità di agire all’esterno. Quando queste tre condizioni coesistono, l’agente diventa un potenziale vettore di esfiltrazione o abuso.

Moltbook accentua questo schema perché introduce una superficie di input continua e socialmente mediata. Le skills diventano una supply chain di istruzioni. Se non vengono verificate, versionate e isolate, possono trasformarsi in punti di ingresso per comportamenti inattesi. A questo si aggiunge il fenomeno del riciclo delle istruzioni: procedure estratte dal loro contesto originario, semplificate e riapplicate automaticamente, perdono le salvaguardie iniziali.

Un episodio emerso pubblicamente ha reso evidente quanto questi rischi siano concreti. Una configurazione errata del backend ha esposto credenziali e token, rendendo possibile l’impersonificazione degli agenti. Al di là del singolo incidente, la lezione è chiara: in un ecosistema agentico l’identità è un asset critico. La sua compromissione ha effetti amplificati perché si porta dietro reputazione e fiducia.

Si affaccia anche un tema di auditabilità. Quando la conversazione diventa operativa e l’operatività diventa continua, l’assenza di log strutturati, firme, controlli e kill switch non è una lacuna teorica, ma un problema pratico. Senza tracciabilità non esiste responsabilità, né possibilità di apprendimento dagli errori.

Lettura sociotecnica e cornici di policy

Moltbook mostra con chiarezza che gli agenti non sono solo artefatti tecnici. Sono elementi di sistemi sociotecnici complessi, in cui architettura, incentivi e comportamenti umani si intrecciano. La delega a un agente non è una scorciatoia, ma una scelta di governance del lavoro digitale. E su questo non si deve abbassare l’attenzione.

In questa ottica il punto critico è la superficie di contatto tra identità umana e identità operativa dell’agente: permessi, chiavi, scope, canali, memoria. Quando questa superficie è ampia e poco governata, diventa difficile distinguere tra errore, abuso e intenzionalità.

Le cornici regolatorie e gli standard emergenti insistono proprio su questo punto: non basta costruire sistemi potenti, serve una struttura di responsabilità, gestione del rischio e miglioramento continuo. Moltbook, in questo senso, è un’anticipazione. Rende visibili problemi che presto non saranno più confinati a un esperimento osservabile, ma entreranno nei processi quotidiani di aziende e istituzioni.

Prospettive di evoluzione

È probabile che Moltbook evolva in due direzioni. Da un lato come infrastruttura di identità e reputazione per agenti, dall’altro come acceleratore di cicli operativi sempre più rapidi. Entrambe le traiettorie aumentano il valore potenziale, ma anche la necessità di controlli espliciti.

La lezione più utile non è che gli agenti “si comportano in modo strano”. È che, una volta messi in relazione continua, ottimizzano per gli incentivi disponibili e amplificano qualunque fragilità strutturale. Moltbook non racconta il futuro della coscienza artificiale. Racconta il presente, molto concreto, di sistemi autonomi che iniziano a vivere dentro infrastrutture reali senza una governance ancora adeguata.

Osservarlo oggi è un vantaggio. Ignorarlo come semplice curiosità sarebbe un errore.

AI & GENAI

Da Clawdbot a Moltbot a OpenClaw

Una settimana che ha messo a nudo l’open source agentico

A fine gennaio 2026, un assistente personale open source ha smesso di essere un progetto per addetti ai lavori ed è diventato improvvisamente un oggetto di discussione pubblica. Non per una nuova funzione rivoluzionaria, ma per una sequenza di eventi che ha costretto migliaia di persone a inseguire un nome che cambiava più velocemente del codice.

La vicenda è interessante non perché “un bot è diventato virale”, ma perché mostra cosa accade quando un progetto che abilita agenti autonomi supera di colpo una soglia critica di attenzione. Arrivano utenti, tutorial, fork, estensioni, analisi di sicurezza, opportunisti. E in quel momento un tema apparentemente secondario, il nome, si trasforma in una questione di governance e di supply chain.

Clawdbot: quando un prototipo prende forma e identità

All’origine non c’era un grande disegno strategico, ma un prototipo concreto: un semplice gateway per portare un agente AI dentro WhatsApp. Un relay funzionale, pensato per collegare un modello linguistico a un canale reale. In questa fase iniziale il nome era poco più che descrittivo, legato all’idea di “artiglio” come metafora dell’azione.

Il salto avviene quando al progetto viene data un’identità visiva e narrativa. Compare una mascotte, un’aragosta spaziale, e con essa il nome Clawdbot. L’immaginario funziona. Il progetto smette di essere un semplice relay e viene percepito come un assistente personale sempre disponibile, capace di vivere nelle chat quotidiane e, potenzialmente, di agire su strumenti reali.

È qui che il nome inizia a pesare. Clawdbot richiama inevitabilmente l’ecosistema Claude, anche se tecnicamente il progetto è indipendente. Finché l’attenzione resta limitata, la sovrapposizione è tollerabile. Quando l’adozione accelera, diventa un problema.

Moltbot: la prima muta, forzata e pubblica

Il primo cambio di nome non nasce da una scelta di marketing, ma da una necessità. Arriva una richiesta formale legata al trademark: l’associazione visiva e nominativa con Claude non può reggere su larga scala. Non è uno scontro legale spettacolare, ma una situazione tipica quando un progetto cresce troppo in fretta rispetto alle sue fondamenta.

La risposta è rapida: Clawdbot diventa Moltbot. La narrativa interna parla di muta, di cambio di guscio per continuare a crescere. Il nome è coerente con la lore dell’aragosta, ma introduce un problema inatteso. Il rebrand avviene mentre migliaia di persone stanno installando, clonando repository, scrivendo guide e automatizzando deploy.

In quel breve intervallo si apre una finestra di rischio. Handle social e repository vengono occupati da terzi, compaiono cloni, domini simili, pacchetti che imitano quelli ufficiali. Non serve una campagna sofisticata: basta confusione. In un progetto che gira localmente sulle macchine degli utenti, il nome non è solo comunicazione, è un identificatore operativo.

La lezione è brutale nella sua semplicità: quando il software è installabile ed eseguibile, un rebrand è un’operazione di sicurezza, non un restyling.

OpenClaw: la stabilizzazione necessaria

A distanza di pochissimi giorni arriva un secondo cambio di nome. Moltbot non convince fino in fondo, e soprattutto non risolve il problema di fondo: serve un’identità stabile, verificabile, difendibile. Nasce così OpenClaw.

Questa volta il rebrand non è solo nominale. Viene accompagnato da una pulizia dell’ecosistema, dal consolidamento dei repository ufficiali, da un rafforzamento dichiarato delle misure di sicurezza e dall’ampliamento del gruppo di maintainer. È il passaggio da progetto individuale a infrastruttura condivisa.

Il messaggio implicito è chiaro: quando un framework per agenti autonomi diventa mainstream, non può più permettersi ambiguità. Serve una base solida, non solo dal punto di vista tecnico, ma anche organizzativo.

Cosa racconta questa storia

La sequenza Clawdbot > Moltbot > OpenClaw è compressa nel tempo, ma estremamente istruttiva. In pochi giorni ha reso visibili tre livelli di fragilità tipici dell’open source agentico.

Il primo è la supply chain dell’identità: nomi, domini, repository, script di installazione. Quando questi elementi non sono allineati, diventano vettori di abuso.

Il secondo è la supply chain dell’ecosistema: estensioni, plugin, tutorial, pacchetti non ufficiali. La domanda improvvisa crea spazio per soluzioni “plausibili” ma malevole.

Il terzo è la governance tecnica: un agente personale ha accesso a strumenti, file, rete. Se la distribuzione e l’identità non sono sotto controllo, il rischio non è teorico ma operativo.

Questa storia non parla solo di un progetto. Parla di un cambio di fase. Gli agenti non sono più demo o chatbot isolati, ma componenti che vivono vicino ai sistemi reali delle persone. In questo contesto, nomi, processi e responsabilità contano quanto il codice.

Una lezione importante

OpenClaw rappresenta una stabilizzazione, non una conclusione. La velocità con cui tutto è accaduto dimostra quanto l’ecosistema non sia ancora maturo dal punto di vista delle pratiche condivise. Ma dimostra anche che certi problemi emergono solo quando qualcosa funziona veramente.

La vera eredità di questa vicenda non è il meme del “triplo rebrand più veloce della storia open source”. È l’evidenza che l’open source agentico, quando esce dalla nicchia, deve essere trattato come infrastruttura critica. E che la maturità di un progetto non si misura solo in feature, ma nella capacità di reggere il mondo reale quando arriva tutto insieme.