C’è un paradosso inquietante nella promessa infrastrutturale dell’intelligenza artificiale: ciò che rende una piattaforma “fluida”, capace di collegare senza soluzione di continuità modelli, dati e strumenti, può diventare anche il punto più vulnerabile, un varco attraverso cui l’attacco arriva silenzioso. È questa la lezione che emerge dall’analisi sul protocollo MCP (Model Context Protocol) – uno standard adottato per permettere agli agenti AI di connettersi a fonti esterne, strumenti, API e dati — e sul pericolo crescente rappresentato dai plugin che ne estendono le capacità.
L’idea di base dietro MCP è quella di risolvere la “caos dell’integrazione” per l’IA: rendere normale e semplice che un agente linguistico possa avere accesso a database, servizi cloud, strumenti interni, API aziendali, tutto attraverso un’interfaccia comune. Questo principio ha incontrato un’adozione rapida: in meno di un anno, migliaia di server MCP sono stati installati in grandi aziende, e il numero continua a crescere.
Ma ecco la crepa: ogni plugin — che si collega, che estende, che aggiunge una nuova funzione — moltiplica il rischio in modo non lineare. Secondo uno studio di Pynt, già un singolo plugin MCP ha una probabilità stimata del 9 % di essere sfruttato in un attacco. Se ne vengono installati tre, la probabilità supera il 50 %. Con dieci plugin, il rischio esplode fino al 92 %.
Dietro queste cifre non ci sono ipotesi astratte, ma dati concreti: l’analisi esamina 281 server MCP reali e mostra che una grande percentuale di essi espone funzionalità critiche — esecuzione di codice dinamica, accesso al file system, API privilegiate — senza adeguate restrizioni. In molti casi accade che questi server accettino input non fidati, come messaggi Slack, email o feed RSS, combinando punti di debolezza che permettono attacchi “inizio a cascata” (prompt injection, tool poisoning, esfiltrazione).
Un episodio che colpisce riguarda il pacchetto postmark-mcp (versione 1.0.16) che, secondo Koi Security, era stato Trojanizzato: inserendo nel codice una linea che BCCava automaticamente tutte le email verso un dominio controllato da malintenzionati, l’attore riusciva a raccogliere documenti interni, memo, password reset, senza essere rilevato. Poiché i server MCP operano spesso con privilegi paragonabili a quelli degli assistenti AI stessi (accesso email, database, API), una falla di questo tipo può essere devastante, specie se tali plugin non sono inseriti nei processi di inventory o valutazione rischi del vendor.
Altri problemi emergono a livello di protocollo: inizialmente, l’autenticazione nel protocollo MCP era considerata “opzionale”. Le versioni iniziali venivano distribuite e utilizzate diffusamente senza che fosse obbligatorio adottare controlli rigidi. Questo significa che molte istanze attive oggi operano con configurazioni deboli, lasciando la porta aperta. Solo più tardi sono stati introdotti sistemi di autorizzazione (OAuth 2.0 / 2.1), ma per migliaia di installazioni il danno era già fatto.
Da qui nasce un concetto chiave che l’articolo chiama “compositional risk” — il rischio che emerge non da un singolo componente vulnerabile, ma dall’insieme delle connessioni, delle dipendenze incrociate, delle estensioni che interagiscono. Ogni plugin aggiuntivo porta con sé non solo la sua superficie di attacco, ma eredita anche le debolezze di tutto ciò a cui si collega, creando un effetto a catena in cui la vulnerabilità totale diventa molto più grande della somma delle parti singole.
Il lato drammatico è che gli agenti AI che usano MCP praticamente “ereditano” la fiducia — e il rischio — di ogni componente collegato. Se uno strumento collegato non è ben protetto, l’attaccante può pigiare attraverso quella crepa e agganciare l’agente, manipolarlo, farlo deviare, esfiltrare dati senza passare da controlli convenzionali. È un rischio in tempo reale della “supply chain dell’IA”.
Per mitigare questa minaccia serva una difesa a più strati. Prima di tutto, ogni gateway MCP — ogni punto di ingresso e uscita — dovrebbe avere autenticazione rigorosa, idealmente con OAuth 2.1 obbligatorio, non opzionale. Controlli di autorizzazione (least privilege) sono fondamentali: l’agente non dovrebbe ottenere più diritti di quelli strettamente necessari. Log, audit, visibilità completa: ogni chiamata, ogni plugin, ogni operazione dev’essere tracciata.
Ma non basta. È necessario introdurre “semantic layers” – livelli di contesto che aiutino a governare quali dati l’agente può vedere e usando quali regole. Bisogna costruire knowledge graph che rappresentino relazioni, entità e permessi, così da evitare che l’agente possa navigare liberamente tra dati che non dovrebbe vedere. Le policy di sicurezza devono essere incorporate nei livelli semantici, non solo in firewall esterni.
Un altro invito è alla prudenza: non installare plugin a valanga. Ogni estensione va valutata criticamente: se tre plugin portano già al 52 % di rischio, dieci arrivano al 92 %, è evidente che la moltiplicazione “a braccio libero” può essere suicida. Limitare l’uso ai soli plugin essenziali, sottoporli a auditing rigorosi prima dell’installazione, fare red-teaming contro la propria architettura sono pratiche che non possono più essere opzionali.
L’IA non è solo una questione di modelli, parametri e hardware, ma anche — forse soprattutto — di architetture sicure, controlli granulari, consapevolezza delle dipendenze. Le prestazioni e la “comodità” non possono essere il prezzo da pagare per lasciare aperti varchi impensati. Se si vuole che gli agenti AI diventino affidabili e resistenti, serve ripensare il modo in cui integriamo, estendiamo e controlliamo i sistemi: inizia con la consapevolezza che una connessione “facile” può essere l’anticamera di un attacco profondo.