Fino a pochi mesi fa il Model Context Protocol (MCP) era una sigla familiare soltanto agli addetti ai lavori. Oggi la ritroviamo sempre più spesso nelle notizie sulla sicurezza dell'AI, quasi sempre nel ruolo di anello debole della catena. La sequenza di episodi che coinvolgono MCP ha smesso di somigliare a una serie di coincidenze fortuite nel momento in cui i threat actor hanno capito che poteva funzionare da passe-partout per gli attacchi moderni. Conviene quindi prendere dimestichezza con questo componente per comprendere che cosa sta accadendo.

Che cos'è MCP e perché serve all'AI agentica

Il Model Context Protocol è uno standard aperto introdotto da Anthropic alla fine del 2024 per collegare gli agenti AI a strumenti, API e sorgenti di dati esterni. Tale dialogo è inevitabile perché un agente, per risultare utile, deve poter leggere file, interrogare database, invocare servizi e concatenare azioni per conto dell'utente. L’MCP è lo strato che rende possibili queste operazioni con un linguaggio comune, senza costringere ogni team a sviluppare da zero i propri connettori. Il tempismo di Anthropic è stato perfetto perché l'esplosione dell'AI agentica ha reso urgente un modo standardizzato per far dialogare i modelli con il mondo esterno, e le aziende hanno adottato il protocollo soprattutto in locale per evitare di investire tempo e risorse che non hanno, nella costruzione di integrazioni su misura.

Partecipa agli ItalianSecurityAwards 2026 ed esprimi il tuo voto premiando le soluzioni di cybersecurity che reputi più innovative

La comodità ne ha decretato il successo: nel giro di pochi mesi il protocollo MCP è diventato lo standard de facto dell'AI agentica, con oltre 150 milioni di download degli SDK e il supporto nei principali ambienti di sviluppo, da Visual Studio Code a Cursor, da Windsurf a Claude Code e Gemini-CLI.

La stessa diffusione che lo ha reso onnipresente lo ha però trasformato in un bersaglio di valore, per via della posizione che il protocollo occupa. MCP è il collante che tiene insieme agenti, tool e servizi, e questo lo rende intrinsecamente un single point of failure della supply chain AI: chi riesce a comprometterlo raggiunge in un colpo solo tutto ciò che vi si appoggia. A questa già importante motivazione si somma la velocità di adozione: più agenti entrano in produzione, più connessioni MCP si moltiplicano, più si amplia la scala dei danni che un attacco a MCP può causare. Oltre tutto, la dinamica dello sviluppo agile si ripercuote anche qui, con l’uso frequente di MCP configurati in fretta e senza rafforzamento delle difese, da sviluppatori che hanno usato l'AI per scrivere il codice di integrazione.

OX Security ha coniato per questa dinamica l'espressione effetto Army of Juniors, riferita alla facilità con cui gli strumenti di vibe coding permettono di mettere in produzione codice funzionante senza interrogarsi sulla sicurezza dei protocolli sottostanti. Il risultato è una platea enorme di implementazioni esposte, stimata fino a 200.000 istanze e oltre 7.000 server accessibili pubblicamente.

Gli attacchi si moltiplicano

La conseguenza di quanto detto finora è che gli attacchi si stanno moltiplicando velocemente. Il filone più battuto è quello delle skill trojanizzate distribuite attraverso i marketplace, che era per esempio al centro dell'analisi di Acronis su come le piattaforme di distribuzione diventino vettore di malware. In sostanza, componenti apparentemente innocui veicolano payload malevoli sfruttando la fiducia che gli utenti ripongono negli store ufficiali.

Allo stesso filone appartiene anche la ricognizione delle capacità degli agenti, con memoria, permessi e skill che si trasformano in altrettanti punti di ingresso quando un agente tratta ogni strumento disponibile come una funzione da invocare. La tecnica più insidiosa resta l'indirect prompt injection, con istruzioni malevole nascoste nei documenti o nei file che l'agente legge ed esegue durante il suo compito.

A questi si aggiungono i casi in cui il protocollo MCP diventa parte attiva della catena d'attacco. Nell'analisi di Marco Rottigni di SentinelOne, un agente aggiorna in autonomia una dipendenza a una versione malevola e prosegue la sequenza come se fosse un'evoluzione coerente del compito ricevuto. In un episodio ancora più esplicito, un framework per lo sviluppo di malware capace di eludere gli EDR affidava proprio al Model Context Protocol il coordinamento tra i suoi agenti e i repository da cui attingeva le tecniche di evasione.

L'ultimo tassello, in ordine di tempo, porta la firma di OX Security, che ha pubblicato una ricerca destinata a fare da spartiacque. I ricercatori hanno caricato un payload dimostrativo e innocuo su undici marketplace di configurazioni, e nove lo hanno accettato senza alcuna revisione, tra cui hub molto frequentati come LobeHub e Cursor Directory. Solo GitHub lo ha respinto. Sul versante degli ambienti di sviluppo, i ricercatori di OX Security hanno testato scenari di prompt injection su più IDE AI. Windsurf è l'unico caso in cui l'attacco non richiede alcuna interazione dell'utente, ed è quello a cui è stato assegnato un numero di CVE.

Mettendo insieme tutte le informazioni che ogni giorno vengono diffuse in relazione ad attacchi che sfruttano MCP, si ha la netta sensazione di essere davanti alla madre di tutti gli attacchi alla supply chain, perché il rischio parte da un punto unico, ma si irradia verso migliaia di installazioni locali e, da lì, verso altri sistemi ancora.

La criticità è proprio dovuta al fatto che gli incidenti non restano questioni a sé stanti, ma sono legati in una catena automatizzata che si muove a velocità macchina, per questo è molto difficile intervenire. La ricerca OX Security indica una vulnerabilità architetturale che in determinate condizioni consente l'esecuzione di comandi arbitrari sui sistemi che ne eseguono un'implementazione esposta. Questo concetto è fondante, quindi vale la pena chiarirlo. Quando un agente AI si collega a un server MCP in locale, lo fa tramite una configurazione che specifica un comando da eseguire per avviare quella connessione (tipo "esegui questo programma per aprire il canale dati"). Il problema è che il protocollo non verifica se quel comando sia legittimo prima di eseguirlo: lo lancia e basta, con i privilegi del processo che lo esegue. Di conseguenza, chiunque riesca a controllare quella configurazione (un file di config manomesso, una voce malevola in un marketplace di skill/plugin) può scriverci all’interno un comando qualsiasi del sistema operativo, per cancellare file, leggere credenziali, aprire una shell remota. Il sistema lo eseguirà comunque. Inoltre, se il comando "funziona" come connessione MCP, tutto prosegue normalmente; se non funziona, il sistema restituisce un errore, ma il comando nel frattempo è già stato eseguito sulla macchina. Quindi si parla di RCE (Remote Command Execution) perché non serve sfruttare un bug nel codice, basta scrivere il comando di sistema (shell) da remoto.

Quanto descritto non è una svista nella programmazione, è una precisa scelta di design, presente negli SDK ufficiali per Python, TypeScript, Java e Rust. Questo significa che chiunque costruisca sul protocollo ne eredita l'esposizione, senza interventi aggiuntivi e spesso senza saperlo. Qualcuno starà pensando che una volta individuato il problema sia sufficiente correggerlo. In realtà non è così semplice. Nel corso di una ricerca durata circa cinque mesi, OX Security ha prodotto oltre trenta disclosure e più di dieci CVE di gravità alta o critica, ottenendo patch sui singoli progetti a valle. La correzione a livello di protocollo resta però assente, perché OX Security parla di vulnerabilità sistemica, mentre Anthropic considera il comportamento atteso e coerente con il design, e sostiene che il modello di esecuzione rappresenti un default sicuro e che la sanitizzazione degli input competa allo sviluppatore. Come riportato da TechTalks, la stessa lettura è arrivata da altri attori dell'ecosistema, tra cui LangChain e Microsoft. In seguito, l'unico intervento visibile da parte di Anthropic è stato l'aggiornamento della guida di sicurezza, che oggi raccomanda di usare gli adapter MCP con cautela e lascia la falla dov'era.

Come ridurre il rischio

È evidente la necessità di trovare un rimedio che vada oltre il consiglio di leggere la guida in linea e muoversi con cautela, soprattutto in un ambito frenetico come quello DevOps, in cui agli sviluppatori è richiesta produttività record in tempi strettissimi. OX Security indica una soluzione interna al protocollo. Prima di tutto caldeggia la manifest-only execution: anziché accettare qualsiasi comando arbitrario scritto nella configurazione, il server dovrebbe dichiarare in anticipo quali comandi è autorizzato a eseguire, di modo che l’agente possa scegliere solo tra quelli. La seconda è una allowlist di comandi preventivamente integrata negli SDK ufficiali, che verifica ogni comando in ingresso e lo autorizza solo se riscontrato nella lista di operazioni ammesse prima di lanciarlo.

La terza è il sandboxing, con i server MCP eseguiti in ambienti isolati e a privilegi minimi, in modo che qualora un comando malevolo riuscisse a passare, resterebbe comunque confinato senza intaccare il resto del sistema. La quarta è una verifica obbligatoria dei marketplace, che dovrebbero controllare i contenuti prima di pubblicarli, anziché accettare qualsiasi configurazione venga caricata. Il punto in comune è che sarebbe sufficiente implementare queste misure una sola volta a livello di protocollo o di SDK ufficiale, per fare che sì che si propagassero in automatico a ogni progetto costruito a valle.