Tag: sicurezza agentica

AI & GENAI, TECH & BUSINESS

Chi può ancora dire di no

Sta diventando normale vedere un agente che si mette in moto da solo, magari perché è arrivata una nuova richiesta o perché qualcosa nel lavoro si è bloccato, prende in carico il compito, lo divide in molte parti più piccole e le affida ad altrettanti agenti che procedono in parallelo, ognuno nel suo spazio isolato, mentre lui tiene d’occhio quello che producono e rilancia i pezzi che si inceppano, fino a tornare con una proposta di modifica pronta da rivedere. Ai tavoli dove passo le giornate incontro sempre più persone che lavorano in questo modo, coordinando decine di agenti su progetti veri senza quasi più scrivere codice a mano.

Davanti a una scena del genere la domanda che viene subito è quanto sia autonomo il sistema, e per rispondere si è diffusa l’abitudine di usare una scala che assegna un numero e ti dice quanto sei avanti nel lavorare con l’AI. Quel numero è comodo proprio perché è uno solo, e per un po’ ha funzionato come misura veloce del rischio, ma finisce per nascondere la cosa che conta di più dentro un’impresa cognitiva, e cioè chi, in mezzo a tutto questo, può ancora dire di no e con quanta rapidità riesce a farlo.

Quanto lo lasci andare, quanti ne tieni insieme

La scala più citata è quella proposta da Steve Yegge in «Welcome to Gas Town», costruita su un asse solo che sale dal basso verso l’alto, da quando l’agente si limita a suggerire fino a quando arriva a gestire l’intera baracca per conto suo. Come modo per dire quanta fiducia riponi in un singolo agente funziona ancora bene, ma nel frattempo il lavoro è cambiato e la leva più importante è diventata un’altra, perché conta meno fino a che punto lasci andare un singolo agente e conta molto di più quanti agenti riesci a coordinare nello stesso momento. Sono due cose diverse, e Addy Osmani ha fatto bene a tenerle separate, mettendo su un asse l’autonomia del singolo e sull’altro la capacità di orchestrarne molti, dato che una persona bravissima a far lavorare in sicurezza cinquanta agenti in parallelo può benissimo restare prudente su quanto si fida di ciascuno di loro preso da solo.

Questo spostamento cambia il modo di ragionare sull’autonomia. Non è un livello da raggiungere né una medaglia da esibire mentre si sale di grado, è piuttosto un permesso, e come ogni permesso si concede quando serve e si ritira quando serve. Davanti a un compito, allora, la domanda giusta smette di essere quanto in alto posso spingermi e diventa quanto rischio quel compito è capace di sopportare, e quale prova mi permette di difendere la scelta di lasciarlo correre da solo.

Conta quanto pulito torni indietro

Per capire se un sistema sta lavorando con un’autonomia davvero alta mi appoggio a tre domande che devo a Osmani, e riguardano tutte la possibilità di correggere il tiro: con quanta rapidità mi accorgo se sta sbagliando, con quanta facilità posso annullare quello che ha fatto, e che cosa mi dimostrerebbe invece che sta andando nella direzione giusta. Quando le risposte sono che me ne accorgo tardi, che tornare indietro è complicato e che in fondo mi sto fidando del riassunto, di autonomia alta è rimasto soltanto il nome, e sotto c’è un azzardo con un cruscotto messo lì a rassicurare.

È qui che l’idea del permesso revocabile diventa concreta. La sovranità di un’organizzazione sui propri processi si misura da quanto in fretta riesce a fermarli e a riportare le cose com’erano senza fare danni, molto più che dal numero di agenti che riesce a mettere in moto. Un intervento delicato come la riscrittura del motore dei pagamenti, se è protetto da verifiche serie, da agenti che controllano il lavoro di altri agenti e da un ritorno indietro pulito, può sopportare un’autonomia molto più alta di un compito che tocca dei contenuti senza avere una fonte certa con cui confrontarsi. Il livello di autonomia dipende dal processo di verifica che gli abbiamo costruito attorno, molto più che dal nome che diamo al compito.

Il debito nascosto nel riassunto

Man mano che l’agente si prende carico di compiti ben delimitati, la verifica smette di passare dai tuoi occhi e si sposta sulle prove che l’agente stesso produce, come le verifiche automatiche che vanno a buon fine, le schermate, le registrazioni di quello che è successo e le istruzioni per riprodurre un problema. Da un lato è un guadagno, perché nel frattempo puoi occuparti d’altro o semplicemente andare a dormire, dall’altro è un rischio, perché la scorciatoia è sempre a portata di mano, e cioè prendere il riassunto che l’agente ti consegna e usarlo al posto della revisione vera, dando per scontato che basti.

Questa scorciatoia, nei miei appunti, ha un nome e si chiama debito cognitivo. Ogni volta che accetto un riassunto senza pretendere lo stesso corredo di prove che chiederei a una revisione fatta a mano, e cioè il confronto delle modifiche, le verifiche, le registrazioni e i rischi rimasti scoperti, contraggo un debito che prima o poi qualcuno dovrà ripagare, con gli interessi. Per questo, in un’organizzazione che lavora con gli agenti, la verifica diventa una forma di capitale, qualcosa che va costruito, va mantenuto e quando manca si nota subito. Nessun modello te la regala già pronta, è una capacità che l’impresa coltiva nel tempo. In «Pelle Digitale» ho provato a raccontare proprio questa membrana sottile che ci separa dalla macchina che agisce al posto nostro, ed è lì che il debito cognitivo comincia ad accendersi.

Anthropic ha misurato tutto questo osservando circa quattrocentomila sessioni di lavoro con Claude Code, raccolte tra l’ottobre del 2025 e l’aprile del 2026, e ne è uscito un quadro abbastanza chiaro, perché nella sessione tipica sono le persone a prendere circa il settanta per cento delle decisioni di pianificazione, quelle su cosa fare e su quando considerare finito il lavoro, mentre è il modello a prendere circa l’ottanta per cento delle decisioni di esecuzione, quelle su quali file toccare e quale comando eseguire. Letta con questi numeri, l’autonomia alta non toglie le persone dal processo ma le sposta di posto, portandole dal compiere ogni singolo passo al decidere in che direzione muovere quello successivo, e chi porta con sé più competenza del proprio ambito ottiene di più da ogni istruzione e se la cava meglio quando l’agente si blocca, perché sa rimettere a fuoco il problema invece di lasciar perdere.

Il contratto prima della corsa

Prima di lasciar partire un agente conviene mettere per iscritto, in modo breve, che cosa dovrà cercare di ottenere. Non serve un documento burocratico, basta un foglio chiaro che chiunque, compreso un altro agente, possa leggere per capire dove passano i confini. Osmani ne propone una forma pratica che trovo solida, e la riprendo adattandola al modo in cui ragiono io sui permessi.

La prima cosa da fissare è l’obiettivo, che va detto come risultato e non come attività, quindi non «usa questa tecnica» ma «porta il tempo di caricamento sotto il secondo». Attorno all’obiettivo si dispone tutto il resto, e cioè il perimetro entro cui l’agente può muoversi insieme alle cose che invece deve lasciar stare, i permessi con cui gli è concesso toccare il mondo fuori dal suo recinto, la condizione che gli dice quando fermarsi e che è meglio sia misurabile, le prove che confermano il risultato in modo indipendente da lui, il momento e la persona a cui deve passare la mano quando qualcosa si complica, e infine un limite prefissato di tempo, di tentativi e di token, che per questi sistemi sono la moneta con cui pagano il lavoro che fanno.

Su come funzionano davvero il runtime, il contesto e i permessi degli agenti mi sono già soffermato di recente, e non torno qui sui dettagli. Senza un contratto del genere, comunque, l’autonomia alta resta soltanto un atto di fede, e gli atti di fede, quando finiscono in produzione, prima o poi si pagano.

Più agenti lanci e più serve chi controlla

Il gradino più alto assomiglia a una piccola fabbrica. C’è un agente che fa da manager e si attiva quando arriva un compito, distribuisce il lavoro agli altri agenti, ne segue l’avanzamento, rilancia le parti fallite e porta all’attenzione di una persona soltanto le decisioni che richiedono davvero un occhio umano, mentre in ingresso riceve la coda del lavoro, che sia una lista di lavori da fare o un registro delle segnalazioni, e in uscita restituisce attività chiuse e proposte di modifica accompagnate dalle loro prove. Attorno a impostazioni di questo tipo stanno nascendo specifiche di orchestrazione costruite intorno a una lavagna dei compiti, in cui ogni problema riceve il proprio spazio di lavoro e il proprio agente, e la frontiera, per come la racconta Osmani, sono ormai fabbriche che non si fermano mai, con centinaia o addirittura migliaia di agenti al lavoro insieme.

A questa scala due trappole si aprono quasi da sole. La prima è un parallelismo solo apparente, che scatta quando lanci trenta agenti su porzioni di lavoro che si sovrappongono e invece di moltiplicare i risultati ti ritrovi con conflitti da risolvere e con decisioni prese due volte. La seconda è più insidiosa e riguarda noi, perché la tentazione è continuare a coordinare a mano ogni singola dipendenza mentre decine di agenti girano, un po’ come se ci ostinassimo a dirigere il traffico a un incrocio che ormai ha già i semafori. Sul mestiere del manager che passa dal gestire persone al gestire agenti ho scritto di recente, perché è lì che si decide la partita organizzativa più difficile.

Più agenti metti in campo e più diventa vitale una verifica che sia indipendente, con chi implementa tenuto separato da chi rivede, con chi prepara le prove distinto da chi ne controlla la qualità e con dei passaggi di approvazione diversi per accettare il lavoro finito. Le organizzazioni cognitive che vedo nascere si riconoscono proprio da questo, dal fatto che riescono a far lavorare molti agenti insieme e nello stesso tempo a tenere il permesso sempre revocabile, a ogni anello della catena.

Quanti agenti sai ancora fermare

Alla fine il vero collo di bottiglia resta sempre la verifica, più che l’ambizione o il numero di agenti che riusciamo a far girare, perché tutto si gioca su quanto in fretta ci accorgiamo di aver sbagliato e su quanto puliti riusciamo a tornare sui nostri passi. La postura più matura, per chi lavora con gli agenti, è un’autonomia calibrata, che sale di un gradino soltanto dopo che le prove per reggere quel gradino si sono accumulate e che accetta di restare bassa proprio là dove tornare indietro sarebbe difficile.

Mi porto dietro dai tavoli dove lavoro una convinzione che col tempo si è fatta netta. Il giorno in cui ci vanteremo di far girare mille agenti, la prova di essere davvero avanti starà tutta nella rapidità con cui possiamo ancora fermarli. Finché quella rapidità tiene il passo del lavoro che si avvia da solo il permesso resta revocabile e siamo al sicuro, e conviene costruire i processi perché resti così: il giorno in cui la lasciamo indietro avremo soltanto una fabbrica che non sappiamo più spegnere.

Lo spunto di partenza è l’articolo di Addy Osmani «Agentic Autonomy Levels». Le tre domande sulla reversibilità e la forma del contratto d’esecuzione vengono dal suo pezzo, mentre la lettura in chiave di permesso revocabile e di debito cognitivo è mia.

AI & GENAI

Harness engineering: runtime, contesto, permessi

Il modello non è quasi mai il problema. Adnan Masood, in un’analisi dell’aprile 2026 sul control plane degli agenti, riporta che il 65% dei fallimenti dei progetti AI in azienda non nasce da carenze di ragionamento del modello, ma da difetti dell’infrastruttura che gli sta intorno, dal contesto che va alla deriva agli schemi disallineati, fino allo stato che degrada nel tempo senza che nessuno se ne accorga. Lo stesso numero gira in più rassegne di settore, e dice una cosa scomoda per chi compra licenze guardando solo i benchmark. La parte che fa fallire i progetti sta altrove, in un livello, l’harness engineering, che fino a diciotto mesi fa nessuno chiamava per nome.

Adesso un nome ce l’ha. Si chiama harness engineering, ed è diventato il mestiere che separa una demo che impressiona in riunione da un agente che regge tre mesi in produzione senza che qualcuno debba riavviarlo a mano ogni venerdì.

Harness engineering, cosa c’è davvero intorno al modello

L’harness è l’infrastruttura di runtime che avvolge il loop di ragionamento di un LLM. Salesforce lo descrive bene con un’immagine edilizia: il framework, LangChain o un agent builder qualsiasi, è il progetto dell’edificio, l’harness è il cantiere dove l’agente lavora davvero. Un paper su arXiv di marzo 2026 sull’architettura degli agenti da terminale lo definisce come il livello che coordina, a runtime, la spedizione degli strumenti, la gestione del contesto, l’applicazione delle regole di sicurezza e la persistenza dello stato fra un turno e l’altro.

Tradotto per chi deve decidere: il modello è il motore, l’harness è tutto il resto dell’auto. Senza, hai un blocco di potenza che gira a vuoto.

Dentro questo livello vivono sei o sette sottosistemi che lavorano insieme. L’assemblaggio del contesto, che decide cosa entra nella finestra del modello a ogni passo. I contratti degli strumenti, gli schemi che il modello deve rispettare quando chiede un’azione. La memoria, che tiene insieme un compito lungo. L’osservabilità, che permette di capire cosa è successo quando qualcosa va storto. Il recupero degli errori e l’orchestrazione, che governano la danza tra modello, strumenti e dati. Ognuno di questi è un punto dove un prototipo elegante diventa fragile.

System design per un runtime che hallucina

C’è un’obiezione che chi ha background da systems engineer fa appena sente “harness engineering”: questo lo facciamo da decenni. Loop che persistono lo stato tra una chiamata e l’altra, validazione degli input prima dell’esecuzione, retry on failure, log per l’audit. È esattamente quello che scrivi quando avvolgi un’API esterna e pensi “forse dovrei gestire il timeout”.

Akshay Kokane, in un’analisi che gira molto tra chi costruisce sistemi agentici, mette la questione in modo diretto: l’harness engineering è al 90% system design che conosci già, applicato a un substrato nuovo. Il 10% rimanente è genuinamente diverso, perché il tuo sistema ora ha al centro un componente non deterministico che può hallucinar una tool call, restituire una risposta semanticamente sbagliata o perdere il filo dell’obiettivo dopo quaranta turni di conversazione.

La differenza concreta sta in un solo punto: con un’API tradizionale validi il formato dell’output, con un agente devi validare l’intento. La pipeline di permessi di Claude Code non controlla solo se una tool call è sintatticamente valida, controlla se il modello è autorizzato a volere quello che vuole. Il vecchio stack retry-and-log non basta più perché il problema non si trova nella risposta, si trova nella richiesta, prima che qualcosa venga eseguito.

Questo spiega anche perché il nome è arrivato adesso, e perché conviene tenerlo anche se sa di marketing. Chi entra nell’AI engineering senza anni di systems engineering alle spalle ha bisogno di un vocabolario per afferrare questi pattern. Chi conia quel vocabolario si prende conferenze, SEO e mindshare, certo, ma distribuisce anche conoscenza che altrimenti resterebbe dispersa nei thread di GitHub. Il termine vale la pena impararlo per ciò che descrive, non per chi lo promuove.

La regola che cambia tutto

C’è un principio che ricorre in ogni guida seria sull’argomento, e vale la pena fermarsi: il modello non deve mai eseguire direttamente uno strumento. Mai. Il modello restituisce una richiesta di azione strutturata, l’harness valida lo schema, controlla i permessi, esegue, e reinietta il risultato.

Sembra un dettaglio implementativo. È invece il punto in cui si gioca la sicurezza di un sistema agentico in azienda. Se l’agente può chiamare arbitrariamente comandi, basta una prompt injection ben costruita dentro un documento che l’agente legge, e quel comando viene eseguito con i permessi dell’agente. Il livello di mediazione, la validazione tra l’intenzione del modello e l’azione sul mondo, è ciò che distingue un assistente da un rischio operativo che gira con le credenziali aziendali.

Le tassonomie di rischio più mature classificano le azioni: sola lettura, finanziarie, distruttive. Per ognuna una matrice di permessi diversa. È il tipo di ingegneria noiosa che non finisce nei keynote e che decide se il progetto sopravvive al primo incidente.

Quattordicimila parole perse in un colpo solo

Avevo costruito un agente editoriale che lavora sul mio blog via MCP, e per settimane ha funzionato. Poi un giorno, su un articolo molto lungo, una singola operazione ha sovrascritto un post intero perché lo strumento che usavo riscriveva l’intero corpo invece di toccare il blocco giusto. Quattordicimila parole perse in un colpo. Il modello aveva ragionato benissimo, l’harness intorno non aveva il vincolo che serviva.

Da lì ho imparato sulla mia pelle quello che le aziende stanno scoprendo su scala enterprise: la fragilità non sta nell’intelligenza del modello, sta nell’assenza di guardrail attorno alle sue azioni. Avevo dovuto cambiare strategia, passare a edit chirurgici con verifica a vuoto prima di ogni scrittura, salvare lo stato prima di toccarlo. Harness engineering applicato a una redazione di una persona sola.

Birgitta Böckeler, in un modello mentale pubblicato ad aprile 2026, descrive l’harness come una combinazione di guide in avanti e sensori di ritorno che si autocorreggono prima che l’output arrivi sotto gli occhi di un umano. Distingue i controlli computazionali, i linter, i test, dalle verifiche inferenziali, un modello che giudica un altro modello. Chiude con una proposta netta: la harnessability, la capacità di un sistema di essere imbrigliato in modo affidabile, dovrebbe diventare un criterio di prima classe nelle decisioni di architettura. Alla pari del costo e delle prestazioni.

L’etica nascosta in un livello di software

Qui il discorso esce dall’ingegneria ed entra in un territorio che mi interessa da tempo. In Pelle Digitale ho provato a descrivere lo strato sottile dove l’umano e la macchina si toccano, la mediazione che decide cosa passa e cosa no. L’harness è esattamente questo, portato dentro l’azienda: il punto in cui decidiamo quanta autonomia diamo a un sistema, dove mettiamo i confini, cosa l’agente può fare da solo e cosa deve passare da una mano umana.

Le scelte che sembrano tecniche sono scelte di governance: quali azioni richiedono conferma, quali log conservare e per quanto tempo, visto che la memoria di un agente che processa dati personali resta soggetta a GDPR come qualsiasi altro trattamento, e chi risponde quando l’agente sbaglia. Domande che nessun modello, per quanto grande, risolve da solo: si affrontano progettando con cura il guscio che gli sta intorno.

Avevo già osservato come Anthropic abbia spostato l’esecuzione degli agenti dentro l’azienda lasciando la regia fuori, con sandbox self-hosted e tunnel MCP. Quella mossa ha senso solo se chi la riceve sa costruire l’harness dalla propria parte del confine. Il fornitore ti dà il motore e parte dell’infrastruttura, il resto è responsabilità tua.

Prodotto, non collante

La soglia di accesso a un harness funzionante è più bassa di quanto sembri. Nick T., ricercatore che ha documentato la costruzione di un harness senza toccare una riga di codice, mette la cosa in modo diretto: chiunque può aggiungere file Markdown a un repository e sentire la differenza già dalla sessione successiva. Il CLAUDE.md o l’AGENTS.md nella root del progetto viene caricato dal modello all’avvio come un briefing. Le convenzioni di naming, i comandi di build, le cose da non fare: tutto scritto una volta, disponibile a ogni sessione senza doverlo ripetere. Primo strato, non l’intero edificio, ma quello che separa il ripartire da zero ogni volta dall’avere un agente che sa già dove si trova.

Trattate l’harness come prodotto, non come collante. La tentazione è incollare insieme un framework open e qualche script. Funziona finché non smette, di solito al primo carico reale. Le aziende che scalano comprano la plumbing commodity, runtime gestiti e telemetria di base, e costruiscono in casa la parte proprietaria che riguarda i loro dati e i loro permessi.

Mettete l’osservabilità prima dell’autonomia. Un agente che fa cose senza che voi possiate ricostruire cosa ha fatto è un debito tecnico travestito da innovazione. Prima i log strutturati e i sensori, poi l’allargamento dei poteri.

Testate l’harness, non solo il modello. Le valutazioni di sicurezza serie non si limitano a controllare le risposte del modello: provano l’infrastruttura con injection, timeout, sovraccarico di strumenti. Il punto debole è quasi sempre lì.

L’harness engineering non elimina i rischi degli agenti autonomi, li rende governabili. È una differenza che conta, perché governabile significa che qualcuno può rispondere delle decisioni del sistema, e in azienda è esattamente la domanda da cui parte tutto il resto. Quanta autonomia dare a un sistema di cui capiamo fino in fondo solo il guscio è una scelta di governance, e la maturità di un’organizzazione si vede da quanto sa tenerla bassa proprio dove tornare indietro costa di più. Se l’argomento vi tocca da vicino, è il terreno su cui lavoro con CEO e CTO ogni settimana.

Spunto dall’analisi di Adnan Masood sul control plane degli agenti, dal modello mentale di Birgitta Böckeler sull’harness engineering e dall’analisi di Akshay Kokane su Agent Harness Is Just System Design With a New Name (Level Up Coding) e dall’analisi pratica di Nick T. su Harness Engineering: A Deep Dive Into the Buildable Harness via Markdown Files (AI Advances).

Schema del MCP tunnel di Anthropic: esecuzione dentro la sandbox, regia esterna
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.