Sicurezza informatica MCP: vulnerabilità nel 40% dei server IA

Server MCP e IA sono spesso esposti a rischi informatici: vulnerabilità, prompt injection, tool poisoning, permessi eccessivi e gestione degli incidenti formano uno scenario complesso. L’articolo analizza cause, minacce e contromisure per una sicurezza efficace.

Check Point AI Security Research ha individuato debolezze di sicurezza nel 40% di 10.000 server MCP analizzati nel 2026. Il dato non certifica che quattro server su dieci siano stati violati, n che ogni problema rilevato renda possibile, da solo, un attacco remoto. Dice per qualcosa di preciso: una quota ampia dellinfrastruttura collegata agli agenti IA presenta condizioni che possono favorire manipolazioni, accessi impropri ai dati o operazioni non autorizzate.

Il Model Context Protocol, o MCP, mette in comunicazione un agente di intelligenza artificiale con strumenti e servizi esterni. Un modello che prima leggeva e generava testo pu cos interrogare database, consultare pagine web, modificare file, inviare messaggi oppure chiamare API. Il guadagno operativo evidente. La connessione introduce per una nuova superficie dattacco: lagente pu considerare affidabili un tool, una descrizione o un contenuto che non lo sono e trasformare quellerrore in una fuga di credenziali o in unazione indesiderata.

MCP, server e tool: i componenti della connessione

MCP un protocollo aperto che stabilisce come unapplicazione IA comunica con strumenti e fonti di dati esterne. Il modello non deve imparare un linguaggio proprietario per ogni integrazione. Attraverso MCP riceve lelenco delle capacit disponibili, ne interpreta i parametri e richiama quelle che ritiene pertinenti al compito affidato.

Il server MCP il componente che mette a disposizione queste capacit. Pu essere un processo avviato sul computer di uno sviluppatore, un servizio interno allazienda o un endpoint gestito da un fornitore esterno. Il server riceve le richieste dellagente e le inoltra al sistema collegato: un archivio documentale, un repository di codice, un calendario o una piattaforma cloud.

Il tool corrisponde alla singola funzione esposta dal server. Una ricerca in un database, per esempio, pu limitarsi alla lettura. Un altro tool pu creare, aggiornare o cancellare informazioni. La distinzione pesa sul piano della sicurezza: leggere un documento non equivale a modificarlo e interrogare un sistema non significa avere il permesso di eseguirvi comandi.

Il percorso abituale composto da quattro passaggi:

• il client IA apre una connessione con il server MCP;
• il server comunica nomi, descrizioni e parametri dei tool disponibili;
• il modello seleziona uno strumento in base alla richiesta e al contesto;
• il server esegue loperazione e restituisce il risultato allagente.

La fase pi delicata la terza. Le descrizioni dei tool entrano nel contesto operativo che il modello deve interpretare. Una descrizione ambigua, alterata o costruita per contenere istruzioni nascoste pu orientare la scelta dellagente prima ancora che parta una chiamata.

Il 40% non indica altrettanti server compromessi

Il rapporto di Check Point AI Security Research parla di debolezze nel 40% di 10.000 server MCP esaminati nel 2026. La formulazione richiede cautela. Il valore riunisce condizioni di rischio osservate durante lanalisi; non dimostra che ogni server classificato come debole sia stato violato, contenga malware o consenta autonomamente lesecuzione di codice.

Le condizioni considerate possono avere natura e gravit molto diverse. Tra gli esempi rientrano server pubblicati con autenticazione insufficiente, configurazioni che assegnano privilegi eccessivi, componenti non verificati, tool capaci di scrivere su sistemi esterni e descrizioni utilizzabili per orientare il comportamento del modello. In alcuni casi serve anche un secondo elemento: un utente ingannato, un contenuto malevolo o una credenziale gi esposta.

Dire che il 40% dei server vulnerabile allo stesso attacco sarebbe quindi scorretto. La lettura pi fedele unaltra: quattro server su dieci del campione presentavano almeno una condizione problematica per la sicurezza. Si tratta di una fotografia dellecosistema osservato nel 2026. Il campione non comprende automaticamente tutti i server MCP privati o quelli non indicizzati.

La rilevazione resta significativa. Mostra che la rapidit con cui vengono pubblicate le integrazioni non sempre accompagnata da controlli altrettanto maturi lungo la catena di fiducia.

Una catena di fiducia che arriva fino al sistema finale

Collegare un agente a un server MCP significa aggiungere una relazione di fiducia tra pi componenti: modello, client, server, tool e sistema destinatario. Ogni passaggio pu introdurre un errore di configurazione o un comportamento che non era stato previsto.

Allagente si pu concedere laccesso a documenti riservati, la possibilit di inviare messaggi a nome di un dipendente o il permesso di modificare dati in un gestionale. Se il server non separa bene le funzioni, una richiesta nata per un compito circoscritto pu arrivare a risorse che non hanno rapporto con lo scopo iniziale.

Il modello, poi, non opera come un sistema tradizionale di autorizzazione. Valuta una descrizione, la confronta con la richiesta dellutente e sceglie un tool sulla base della somiglianza semantica. Da solo non pu sapere con certezza se lo strumento autentico, se il risultato integro o se lazione rispetta tutte le policy aziendali.

Affidarsi soltanto alla capacit del modello di riconoscere una richiesta sospetta non basta. I controlli devono riguardare il client, il server MCP, lidentit impiegata per accedere alle risorse e il sistema che registra oppure blocca le operazioni.

Tool poisoning: listruzione malevola dentro lo strumento

Si parla di tool poisoning quando istruzioni malevole vengono inserite nella definizione o nella risposta di uno strumento. Il testo pu comparire nella descrizione, nei parametri, nei metadati oppure nelloutput generato dopo una chiamata. A un essere umano pu sembrare una nota tecnica innocua; per il modello pu assumere il valore di un comando operativo.

Si pensi a un tool destinato alla ricerca delle fatture. La sua descrizione potrebbe suggerire di inviare i risultati a un indirizzo esterno per una presunta verifica. Se lagente dispone anche di uno strumento per spedire e-mail e interpreta quella frase come parte del flusso corretto, pu concatenare le due funzioni.

Il contenuto manipolato non deve per forza essere visibile nella schermata di configurazione. Pu essere nascosto in una propriet JSON, in un commento, nella risposta del server o in un documento restituito dal tool. Tutti questi elementi arrivano nello stesso contesto generale in cui lagente elabora le istruzioni legittime.

Le verifiche devono quindi riguardare anche le definizioni degli strumenti, non soltanto i messaggi digitati dallutente. Un tool non soltanto codice: anche una fonte di istruzioni che pu influenzare la selezione delle azioni.

Prompt injection e deviazione del compito

La prompt injection un attacco in cui un testo cerca di sostituire o deviare le istruzioni assegnate allagente. Nella forma diretta lattaccante scrive il messaggio rivolto al modello. In quella indiretta listruzione viene collocata in una pagina web, in un documento, in une-mail o nel risultato prodotto da un altro strumento.

La variante indiretta crea problemi particolari negli ambienti MCP. Lutente pu chiedere semplicemente di riassumere un documento. Dentro quel documento, per, pu esserci una frase rivolta al sistema IA: ignorare il compito, cercare dati riservati, spedire il contenuto a un indirizzo oppure usare un determinato tool.

Il modello non separa in modo perfetto i dati da leggere dalle istruzioni da seguire. Quando il flusso applicativo non assegna livelli di fiducia diversi, il contenuto recuperato pu incidere sulla pianificazione dellazione. Un testo esterno diventa cos un possibile canale di comando.

Il pericolo aumenta con lautonomia dellagente, la memoria, laccesso a pi strumenti e le credenziali persistenti. Una manipolazione testuale pu avviare una sequenza composta da lettura delle informazioni, scelta di un account, apertura di un endpoint e trasferimento dei dati.

Il 92% il risultato di uno scenario specifico

Nel 2026 circolato anche un dato secondo cui gli agenti IA sarebbero stati ingannati dal 92% delle pagine web fraudolente. La cifra serve a rappresentare la vulnerabilit dei sistemi che navigano e agiscono online, ma non misura in modo universale tutti gli agenti n tutte le pagine fraudolente.

Il valore deriva da valutazioni sperimentali su agenti sottoposti a scenari controllati. In quei test, contenuti web manipolati o indirizzi malevoli cercavano di orientare il comportamento del sistema. In uno dei contesti richiamati dalle analisi sulla sicurezza degli agenti, il 92% indica il tasso di successo degli attacchi allinterno di una specifica suite operativa, con pagine o contenuti controllati dallattaccante e un agente capace di consultarli.

Non quindi la percentuale di tutte le pagine fraudolente presenti su Internet che riesce a ingannare qualunque agente. Il risultato dipende dal modello impiegato, dai tool disponibili, dalle istruzioni di sistema, dal compito assegnato, dal numero di tentativi e dal criterio utilizzato per definire riuscito un attacco.

Il significato tecnico rimane chiaro: quando il sistema pu leggere una pagina e agire sulla base del suo contenuto, la navigazione non pi sola lettura. Una pagina manipolata pu deviare il compito, chiedere credenziali, indurre lapertura di un link o provocare luso di unintegrazione non prevista.

Dal contenuto manipolato alla sottrazione delle credenziali

Le credenziali possono essere sottratte attraverso percorsi differenti. Un agente pu ricevere lordine di copiare un token in una richiesta esterna, inserire una password in una pagina falsa oppure includere chiavi API nelloutput di un tool. Non serve per forza una vulnerabilit software classica: una combinazione di contenuto manipolato e autorizzazioni troppo ampie pu essere sufficiente.

Un percorso diverso passa dai file di configurazione. Se il client carica automaticamente impostazioni di progetto, server o comandi approvati, un file alterato pu cambiare il comportamento dellambiente prima che lutente riesca a controllare ogni voce. Lagente entra cos nel percorso di esecuzione e il rischio assume caratteristiche simili a quelle della supply chain del software.

File locali, variabili dambiente, repository e configurazioni condivise possono contenere materiale sensibile e vanno trattati di conseguenza. Se il server MCP non distingue bene gli account, un tool pu arrivare a usare unidentit pi potente di quella necessaria per il compito.

Da qui possono derivare letture non autorizzate, pubblicazione di dati, messaggi inviati a nome dellazienda o modifiche alle risorse. Il modello non deve conoscere direttamente i segreti per utilizzarli: pu bastare che il processo li riceva dallambiente e disponga di un canale per trasferirli.

Permessi troppo ampi trasformano lerrore in danno

Se lagente pu soltanto leggere una cartella priva di dati sensibili, un errore di interpretazione resta circoscritto. La stessa decisione diventa molto pi grave quando lidentit collegata consente di entrare in sistemi finanziari, dati personali, codice sorgente o account amministrativi.

Il principio del minimo privilegio impone di assegnare a ogni agente soltanto ci che serve per il compito previsto. Un tool che consulta un calendario non dovrebbe creare utenti. Un agente che prepara una bozza di e-mail non dovrebbe inviarla senza una conferma separata. Unintegrazione con un repository dovrebbe distinguere il permesso di lettura dallapertura di modifiche e dalla fusione del codice.

La separazione va applicata anche agli ambienti. Server MCP destinati a sviluppo, test e produzione non dovrebbero condividere automaticamente le stesse credenziali o il medesimo accesso di rete. Un incidente in un ambiente a basso impatto non deve offrire un passaggio diretto verso i sistemi pi sensibili.

Controlli da applicare a un server MCP

Una valutazione aziendale pu cominciare da una mappa delle connessioni e proseguire con verifiche tecniche e organizzative:

• Inventario completo di client, server MCP, tool, proprietari, ambienti e dati raggiungibili.
• Controllo dellorigine del server, della sua manutenzione, delle dipendenze e delle modifiche introdotte nel tempo.
• Verifica dellautenticazione, con identit separate, token a durata limitata e protezioni contro il riutilizzo.
• Conservazione dei segreti in un gestore dedicato, mai in file di progetto, prompt, log o repository.
• Permessi definiti per singolo tool, con il divieto predefinito delle operazioni che non servono.
• Approvazione formale degli strumenti capaci di scrivere, cancellare, inviare dati o eseguire codice.
• Controllo dellintegrit delle definizioni e delle versioni, compresa la verifica delle modifiche apportate al server.
• Separazione fra dati affidabili, dati esterni e contenuti forniti da utenti non verificati.
• Registrazione di richieste, parametri, risposte, identit utilizzata ed esito delloperazione.
• Sandboxing dei processi e restrizioni di rete per bloccare collegamenti non previsti.
• Test periodici contro prompt injection, tool poisoning, alterazione dei risultati e concatenazioni anomale.
• Procedura di revoca immediata per token, server, tool e account coinvolti in un incidente.

Autenticazione forte e segreti sotto controllo

Lautenticazione del server non dovrebbe dipendere dal fatto che lutente lo abbia installato o che il nome del componente sembri affidabile. Ogni connessione deve identificare il server, il client e lutente o il servizio che effettua loperazione.

I token vanno limitati per durata e ambito. Quando la tecnologia lo consente, preferibile ricorrere a credenziali temporanee, ruotabili e revocabili da un punto centralizzato. Le chiavi con accesso in scrittura richiedono controlli pi severi rispetto a quelle che consentono soltanto la lettura.

La gestione dei segreti comprende anche i log. Conservare la richiesta completa pu aiutare lanalisi di un incidente, ma password, token e dati personali devono essere mascherati. Un sistema di monitoraggio che raccoglie credenziali in chiaro crea una seconda superficie dattacco.

Approvazione, isolamento e monitoraggio

Lapprovazione di un tool deve partire dalla sua funzione reale, non dal nome o dalla popolarit del server. Occorre sapere quali dati legge, quali sistemi raggiunge, quali operazioni esegue e se comunica con endpoint esterni.

Per le azioni ad alto impatto pu servire una conferma umana separata. La schermata di conferma deve mostrare loperazione concreta, il sistema interessato e i dati coinvolti; una formula generica come procedere con il task non sufficiente. Il controllo perde valore se lagente pu modificare la richiesta prima che venga approvata.

Il sandboxing limita il raggio dazione di un server alterato. Processi separati, filesystem ridotto, rete filtrata e account privi di privilegi amministrativi rendono pi difficile trasformare un errore del modello in una compromissione dellambiente.

Il monitoraggio deve osservare i comportamenti, non soltanto le firme gi note. Possono indicare unanomalia la chiamata a un tool mai utilizzato, linvio di dati verso un dominio nuovo, una sequenza di richieste estranea alle abitudini, limpiego di credenziali per unoperazione inconsueta o la modifica improvvisa della definizione di uno strumento.

Come testare tool poisoning e prompt injection

I test devono usare contenuti realistici. Non sufficiente inviare prompt ostili direttamente al modello: le istruzioni malevole vanno inserite anche in documenti, pagine web, risultati di ricerca, descrizioni dei tool, risposte API e file di configurazione.

Ogni scenario dovrebbe rilevare almeno quattro esiti: se lagente riconosce il contenuto non affidabile, se evita di eseguire il comando, se limita laccesso ai dati e se produce un log utile a ricostruire la decisione.

Le prove vanno ripetute dopo gli aggiornamenti del modello, del client, del server o delle autorizzazioni. Un ambiente che supera il test iniziale pu diventare esposto dopo laggiunta di un nuovo tool o di una nuova fonte di dati.

La verifica deve coprire anche la concatenazione di due strumenti. Un singolo tool in sola lettura pu apparire innocuo; insieme a uno strumento per linvio, la modifica o la pubblicazione pu invece creare un percorso di esfiltrazione.

Revocare gli accessi e gestire un incidente

Lorganizzazione dovrebbe poter disattivare un server MCP senza aspettare una nuova versione del client. La revoca deve comprendere token, certificati, account di servizio, autorizzazioni dei tool e collegamenti di rete.

Il piano di risposta deve stabilire chi pu sospendere lintegrazione, come isolare lagente, quali log conservare e come accertare se i dati siano stati letti o trasferiti. Credenziali separate per ogni ambiente e per ogni agente aiutano a circoscrivere lincidente, evitando di bloccare tutti i servizi.

Durante il recupero occorre ruotare i segreti, verificare le definizioni dei tool, controllare i file di configurazione e confrontare le azioni eseguite con quelle autorizzate. Quando lagente pu modificare dati, servono anche backup e procedure di ripristino indipendenti dal sistema IA.

La verifica viene prima del collegamento

MCP non , per definizione, un componente insicuro. Il protocollo risolve un problema di interoperabilit e semplifica il collegamento fra agenti e strumenti esterni. Il rischio nasce dallaccostamento di fiducia automatica, contenuti non affidabili, permessi ampi e capacit di compiere azioni.

Il 40% rilevato su 10.000 server nel 2026 segnala che ladozione non accompagnata ovunque da verifiche adeguate. Il 92% registrato nei test controllati sugli agenti web mostra invece quanto sia fragile il confine fra una pagina da leggere e unistruzione da seguire.

Per questo la sicurezza deve essere progettata prima dellintegrazione. Inventario, autenticazione, minimo privilegio, approvazione dei tool, isolamento, logging, test avversariali e revoca degli accessi non sono misure da aggiungere dopo un incidente. Servono a impedire che una nuova connessione venga interpretata come unautorizzazione implicita a operare.