Un agente AI compromesso non deve forzare un database: può chiedere a un collega digitale di farlo per lui. È il framework che emerge dai test di Syed Anas Mohiuddin, ricercatore indipendente che ha verificato il comportamento di agenti usati da Google, JP Morgan Chase, Weviate, Rapid7, dalla direzione interministeriale digitale del governo francese e dal governo federale statunitense. Negli ultimi cinque mesi, Google e altre quattro organizzazioni hanno riconosciuto vulnerabilità che consentono a un agente all'interno di una rete di diffondere istruzioni dannose ad altri agenti interni.

Al centro c'è il Model Context Protocol, o MCP, uno standard che definisce come le applicazioni e gli agenti AI si scambiano informazioni e strumenti dentro un perimetro. La tecnica descritta è una forma particolare di prompt injection: non prende di mira l'LLM in sé, ma un agente specifico, per esempio quello di traduzione o di analisi dati. Se i guardrail di quell'agente sono deboli o assenti, l'istruzione viene trasmessa a valle. L'agente successivo si fida esplicitamente del primo e segue le indicazioni ricevute.

Il problema strutturale non è quindi la singola falla, ma il modello di fiducia transitiva che MCP tende ad abilitare. In molte implementazioni, l'identità dell'agente mittente viene trattata come garanzia di affidabilità anche quando il contenuto del messaggio proviene da una fonte non attendibile. Eppure un agente può essere autenticato e, allo stesso tempo, processare testo arrivato da una email, un documento o una pagina web esterna. La separazione tra identità dell'agente e contenuto del messaggio diventa il vero confine da difendere. Le protezioni, quando esistono, sono spesso permissive: limitare troppo le azioni di un agente riduce l'utilità percepita dell'intero flusso. Così un agente di analisi può passare una richiesta all'agente che gestisce il database e quest'ultimo la esegue perché il mittente è nella lista degli strumenti consentiti.

Per chi gestisce deployment on-premise o self-hosted, il rischio non si neutralizza con il semplice isolamento di rete. Gli agenti vivono dentro il perimetro, accedono a dati aziendali e dispongono di strumenti operativi. Il contenuto malevolo non deve necessariamente arrivare dall'esterno: può entrare come dato non strutturato e diventare istruzione solo dopo essere stato interpretato da un agente. Questo sposta l'attenzione dalla protezione dei singoli endpoint al controllo dei flussi tra agente e agente. È un cambio di prospettiva rispetto alle architetture tradizionali, in cui le comunicazioni interne tra servizi sono spesso considerate meno rischiose di quelle esposte pubblicamente. Per chi valuta deployment on-premise, esistono trade-off tra controllo, complessità e superficie di attacco; AI-RADAR propone su /llm-onpremise una serie di framework per soppesarli.

La cronologia è un segnale forte. Il fatto che organizzazioni eterogenee abbiano riconosciuto vulnerabilità nello stesso arco di mesi indica che il problema non deriva da un'implementazione isolata, ma da una postura troppo fiduciosa verso il protocollo. I team di sicurezza abituati a ragionare in termini di autenticazione e autorizzazione devono ora chiedersi che cosa un agente può fare con le istruzioni ricevute, non solo chi le ha inviate. I fornitori di piattaforme MCP saranno probabilmente spinti a introdurre meccanismi di anteprima, firma dei contesti o confini di esecuzione più stretti. Nel breve periodo, chi guadagna sono gli attaccanti: ottengono un percorso interno per l'esfiltrazione senza dover compromettere ulteriormente la rete. Chi perde sono le organizzazioni che continuano a trattare gli agenti come semplici endpoint e non come attori con privilegi effettivi sui dati.

La ricerca di Mohiuddin, in fondo, offre un promemoria essenziale: quando un agente AI si fida di un altro agente, ha già superato la barriera più difficile da difendere, quella della fiducia implicita.