Microsoft mette in guardia le aziende da una nuova classe di rischio legata agli agenti di intelligenza artificiale: il tool poisoning nei componenti basati su Model Context Protocol. Il problema nasce dal modo in cui gli agenti AI interpretano le descrizioni dei tool esterni. Questi testi, apparentemente innocui e pensati per spiegare funzione e modalità d’uso di un componente, vengono inseriti nella memoria contestuale insieme a istruzioni di sistema, dati utente e risultati intermedi. Se un attaccante riesce a modificare la descrizione di un tool, può nascondere comandi malevoli che l’agente esegue come parte del proprio normale workflow. Il rischio non riguarda un bug specifico di Copilot, ma il confine di fiducia tra sistemi agentici, tool di terze parti e infrastrutture aziendali. In ambienti come Microsoft 365 Copilot, Copilot Studio e Azure AI Foundry, questo scenario può trasformare un agente autorizzato in un canale silenzioso di esfiltrazione dati.
Cosa leggere
Il Model Context Protocol amplia la supply chain agentica
Il Model Context Protocol, noto come MCP, consente agli agenti AI di richiamare strumenti esterni in modo standardizzato, con un modello simile a quello delle API tradizionali. Ogni tool espone una descrizione testuale che indica all’agente cosa può fare, quali parametri accetta e quando deve essere utilizzato. Questa architettura permette di collegare agenti a sistemi aziendali, repository, piattaforme di ticketing, calendari, email, database e servizi cloud, abilitando flussi multi-step sempre più autonomi. Proprio questa flessibilità trasforma però MCP in una componente sensibile della supply chain agentica. Se un tool viene aggiornato da una terza parte, la descrizione può cambiare senza che l’organizzazione valuti sempre il contenuto con la stessa attenzione riservata al codice eseguibile. Microsoft evidenzia che il testo descrittivo deve essere trattato come parte attiva del comportamento dell’agente, non come semplice documentazione.
Come funziona il tool poisoning
Il tool poisoning consiste nell’inserire istruzioni nascoste nella descrizione di un tool già approvato. Il nome, il sommario visibile e la funzione dichiarata restano invariati, mentre nel testo vengono aggiunti comandi camuffati da note operative, suggerimenti di formattazione o dettagli apparentemente tecnici. Quando l’agente carica il tool nel proprio contesto, interpreta quelle istruzioni come direttive valide e può modificare il proprio comportamento senza che l’utente lo percepisca.
Il problema deriva dall’assenza di un confine semantico affidabile tra descrizioni legittime e istruzioni malevole all’interno dello stesso spazio contestuale. Un agente che deve gestire fatture, ad esempio, può essere indotto a recuperare documenti riservati e allegarli a una richiesta apparentemente lecita, inviandoli anche verso un endpoint controllato dall’attaccante. Ogni passaggio può apparire autorizzato, perché l’agente utilizza permessi reali, tool approvati e canali di comunicazione consentiti.
Dati sensibili esfiltrati senza violare regole visibili
Il rischio più grave è l’esfiltrazione silenziosa di informazioni aziendali. Fatture non pagate, chiavi private, dati cliente, contenuti di repository, file interni e documenti riservati possono uscire dall’organizzazione senza che l’agente sembri violare policy esplicite. Un analista può chiedere un’operazione ordinaria, come contattare un fornitore o recuperare documenti amministrativi, mentre l’agente segue anche le istruzioni nascoste presenti nella descrizione avvelenata. Nei log tradizionali l’attività può risultare coerente: l’identità è valida, il tool è approvato, la query rientra nei privilegi dell’utente e l’endpoint di destinazione può non apparire immediatamente sospetto. Microsoft sottolinea che un agente capace di agire per conto dell’utente è affidabile solo quanto lo sono i tool che può utilizzare. Questo principio diventa centrale quando gli agenti possono inviare email, creare file, modificare calendari, interrogare repository o attivare workflow aziendali.
Proof-of-concept e casi reali mostrano un rischio maturo
Il pattern non è soltanto teorico. Già nel 2025 diversi ricercatori avevano dimostrato scenari concreti di tool poisoning. Invariant Labs ha pubblicato un proof-of-concept in cui istruzioni nascoste nella descrizione di un tool calcolatrice inducevano un agente integrato nell’editor Cursor a esfiltrare una chiave SSH privata. In un secondo scenario, un issue malevolo su GitHub poteva dirottare un agente collegato al server MCP della piattaforma e sottrarre dati da repository privati. Un caso particolarmente significativo è stato individuato da Koi Security nel pacchetto npm postmark-mcp: le versioni iniziali erano legittime, mentre la release 1.0.16 introduceva una modifica capace di inoltrare segretamente in BCC ogni email inviata dall’agente a un indirizzo controllato dall’attaccante. Il benchmark MCPTox ha poi misurato l’efficacia di descrizioni avvelenate contro server MCP reali e modelli AI avanzati, evidenziando tassi di successo elevati e pochi rifiuti da parte dei modelli.
Microsoft collega il problema alla governance degli agenti
Per Microsoft, il punto centrale non è bloccare l’adozione degli agenti AI, ma governarne l’interazione con tool esterni. Le descrizioni dei tool devono essere trattate come system prompt e quindi sottoposte a revisione, versionamento e scansione automatica. Ogni modifica va considerata un cambio di comportamento potenziale, soprattutto se proviene da componenti di terze parti. Le organizzazioni dovrebbero mantenere un elenco di publisher approvati, disabilitare configurazioni permissive come allow all e concedere agli agenti solo gli strumenti strettamente necessari. Questo approccio segue il principio del least agency, una variante del privilegio minimo applicata agli agenti: non basta limitare l’utente, bisogna limitare anche ciò che l’agente può fare in autonomia, quali sistemi può toccare e quali dati può trasferire.
Mitigazioni: identità, logging e approvazione umana
Le raccomandazioni operative puntano a creare barriere tecniche e organizzative. Gli agenti devono avere identità univoche, distinguibili da quelle degli utenti umani, così da rendere tracciabili le loro azioni. I log devono registrare non solo il risultato finale, ma anche tool invocati, endpoint contattati, quantità di dati trasferiti e modifiche alle descrizioni. Per azioni ad alto impatto, come spostamento di denaro, invio di dati all’esterno, modifica di account o condivisione di documenti sensibili, Microsoft raccomanda l’approvazione umana esplicita. Strumenti come Prompt Shields, Microsoft Purview DLP, Entra Agent ID, Defender for Cloud e Microsoft Sentinel possono contribuire a creare livelli di controllo, rilevamento e risposta, ma richiedono policy coerenti e una mappatura accurata dei tool utilizzati dagli agenti.
La nuova sicurezza AI passa dalla supply chain dei tool
L’avvertimento del 30 giugno 2026 conferma che la sicurezza degli agenti AI non può essere affrontata soltanto filtrando prompt utente o proteggendo il modello centrale. La superficie d’attacco si estende ai tool, alle loro descrizioni, agli aggiornamenti di terze parti e ai flussi di autorizzazione che permettono agli agenti di agire nei sistemi aziendali. In questo scenario, un testo descrittivo manipolato può diventare un vettore di esfiltrazione efficace quanto una dipendenza software compromessa. Le aziende che adottano MCP e piattaforme agentiche devono quindi costruire controlli di supply chain analoghi a quelli già usati per codice, pacchetti e container. L’agente AI non è più soltanto un assistente che risponde: è un soggetto operativo che accede a strumenti, interpreta istruzioni e produce azioni. La sua sicurezza dipende dalla qualità dei confini di fiducia che l’organizzazione riesce a imporre intorno ai tool che gli vengono concessi.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
