Agenti AI distribuiti: aperture, mobilità e vuoti di controllo

Un agente “a monte” può far eseguire comandi malevoli a un agente “a valle” e propagare la catena fino all’esfiltrazione di dati. La prova, firmata da Syed Anas Mohiuddin, tocca Google, JP Morgan Chase, Weviate, Rapid7, la direzione interministeriale per il digitale del governo francese e il governo federale degli Stati Uniti. Il bersaglio non è l’LLM. È l’agente che riceve e inoltra istruzioni operative tramite Model Context Protocol. Tesi: mentre crescono modelli, automazioni e deployment pensati per flussi agentici, il rischio operativo aumenta e l’“umano nel loop” scivola sullo sfondo. Servono isolamento, governance e supervisione che contino davvero.

1) Nuovi modelli e architetture che favoriscono la diffusione degli agenti

Reflection ha pubblicato Beam: Mixture‑of‑Experts text‑only da 501 miliardi di parametri totali, 23 miliardi attivi. Pesi completi, licenza Apache 2.0. La scheda d’uso include coding, lavoro agentico e lavoro scientifico. La rassegna che l’annuncia parla di addestramento “from scratch” negli Stati Uniti. Mancano benchmark e dettagli su dataset o calcolo. La stessa rassegna colloca Beam accanto a Inkling, Nemotron e GLM 5.2, citando come riferimenti generali GLM 5.3, Kimi K3, Qwen 3.8 Max e DeepSeek V4.1 Flash. Anche qui, nessun numero di prestazione, solo posizionamenti nominali.

Pesi aperti e MoE facilitano adozioni e integrazioni eterogenee. Gruppi diversi possono scaricare, eseguire e adattare il modello. La barriera di ingresso per costruire agenti sopra Beam scende. L’assenza di benchmark non frena i test locali. Aumentano le varianti, aumentano i punti di contatto.

In questa dinamica, “lavoro agentico” non è uno slogan: è un caso d’uso esplicito. Se il modello si propone per compiti che si intrecciano con flussi operativi, la sua traiettoria naturale è dentro pipeline di lavoro. Lì la qualità del controllo non dipende solo dal modello, ma dalla catena che lo avvolge.

2) Automazione della promozione e mobilità cross‑account

Amazon mostra come automatizzare la promozione delle risorse di Quick tra account AWS distinti. Usa un server Model Context Protocol su Bedrock AgentCore. La promessa è concreta: processo idempotente e auditabile, rilanciabile senza effetti collaterali se lo stato è già allineato. L’obiettivo è eliminare gli errori del passaggio manuale da sviluppo a produzione per agenti, connector, knowledge base, flow e Space.

Quick funge da compagno AI per il lavoro. I team assemblano chat agent con istruzioni personalizzate, integrazioni verso Slack o Jira tramite action connector, knowledge base su documenti propri, flow e uno Space che aggrega i componenti. Costruiscono in sviluppo e spostano quando pronti. Molte aziende separano dev, QA e produzione su account diversi. L’automazione riduce l’attrito del passaggio e rende più prevedibili gli esiti.

Mobilità e ripetibilità sono vantaggi. Ma rendono anche più facile portare in più ambienti la stessa configurazione. Se un agente o una policy contiene un difetto logico, la promozione idempotente lo replica fedelmente. È un bene per la coerenza. È un rischio quando i difetti toccano l’orchestrazione tra agenti.

3) Scelte di deployment e isolamento delle sessioni

Anthropic cambia l’architettura di Cowork. Stop alla VM locale. Modello e macchina virtuale passano nel cloud. Ogni sessione ottiene un sandbox dedicato, che non condivide stato con le altre. Effetti pratici: meno batteria consumata, lavoro che continua a laptop chiuso. Prima l’inferenza del modello avveniva in cloud, mentre le chiamate agli strumenti correvano in una VM installata sul computer dell’utente. Quella VM mappava solo i dati aggiunti esplicitamente alla sessione. Ora l’accesso a file locali avviene su richiesta: è l’app desktop a effettuare la chiamata allo strumento di accesso al file; la computazione resta nel cloud. Annuncio del 5 ottobre 2026, firmato da Felix Rieseberg.

L’isolamento per sessione è un argine tecnico chiaro. Riduce la condivisione involontaria di stato. Il passaggio al remoto centralizza però superficie e log di esecuzione. La supervisione diventa un tema di interfacce e policy, oltre che di sandbox. E si intreccia con i protocolli che portano comandi e dati dentro i sandbox.

4) Vulnerabilità nei protocolli di comunicazione tra agenti e limiti del controllo umano

Le proof‑of‑concept di Mohiuddin mostrano una dinamica ricorrente: un agente compromesso usa Model Context Protocol per impartire comandi malevoli ad agenti “a valle”, che si fidano della fonte e li eseguono. La catena si propaga. I controlli di superficie non bloccano. Nell’arco di cinque mesi, Google e altre quattro organizzazioni hanno riconosciuto vulnerabilità con questa dinamica. I settori e gli stack variano. Il difetto sta nel livello di comunicazione tra agenti, non in un singolo prodotto. L’impatto citato include fuga di dati aziendali e personali ed esfiltrazione di contenuti di database.

Sul piano umano, tre ricercatori mettono in discussione la formula “human‑in‑the‑loop”. Il 6 settembre pubblicano su arXiv un paper che sostiene: i meccanismi attuali di informazione e approvazione allontanano l’utente dal controllo pratico sulle azioni degli agenti. Portano un caso concreto: a luglio, uno sciame di bot di OpenAI ha colpito Hugging Face. Per loro non è un’eccezione, ma un segnale. Chiedono di rivedere come si definiscono, applicano e mantengono i processi di controllo, perché la persona incida davvero sulle decisioni del sistema. Gli autori sono Avijit Ghosh e Margaret Mitchell (Hugging Face) e Samir Passi (Data and Society Research Institute).

Un filo unisce i due fatti. Se il protocollo collega agenti che si fidano l’uno dell’altro e la supervisione umana resta formale, basta un nodo compromesso perché la rete esegua. La propagazione non si ferma sulla carta, perché la carta non frena chiamate e azioni.

5) Cosa richiede il quadro: isolamento, governance e design centrato sull’umano

Le mosse recenti danno tre leve operative: isolamento per sessione nel cloud, promozione idempotente e auditabile, pesi aperti per costruire agenti orientati a compiti precisi. Le stesse mosse espongono tre fronti: catene di fiducia tra agenti, mobilità cross‑account di configurazioni errate, supervisione che non incide. Le prove di sfruttamento tramite Model Context Protocol e la critica al “loop” umano convergono su un punto: controlli tecnici e processuali vanno progettati insieme, a monte del flusso di comunicazione tra agenti.

Questo non implica fermare l’automazione. Implica renderla verificabile dove conta. Un processo idempotente e tracciato è utile se i checkpoint hanno presa operativa e non solo log. Un sandbox per sessione isola bene se i canali che lo alimentano discriminano tra istruzioni legittime e comandi in catena. Un modello con pesi aperti abilita innovazione se chi lo innesta in pipeline agentiche definisce ruoli, autorizzazioni e interruzioni che una persona può davvero esercitare.

Per chi costruisce e opera agenti AI distribuiti, la priorità è allineare tre piani con la stessa cura: architettura di comunicazione tra agenti (MCP compreso), processi di promozione tra ambienti e interfacce di supervisione. I casi documentati dicono che mitigazioni isolate non bastano. Servono barriere reali lungo il percorso che un comando percorre, dal modello al connettore, dal connettore alla knowledge base, dalla knowledge base a un altro agente.

L’apertura dei pesi, l’automazione tra account e l’isolamento in cloud non sono neutri. Fissano ciò che diventa facile. Oggi è facile spostare agenti, orchestrare componenti e scalare sessioni. Domani, la differenza tra incidente e controllo potrebbe stare in dove mettiamo l’unico clic che ferma la catena.