Il cloud ha richiesto anni di governance che avrebbero dovuto insegnarci molto, il Model Context Protocol (MCP) ne aggira la gran parte. Il problema è tutt’altro che secondario. Introdotto meno di 2 anni fa, MCP permette ad agenti AI, workstation di sviluppatori e pipeline automatizzate di connettersi su richiesta a server di terze parti. È uno standard utile. Ma è una potenziale fonte di problemi. A darne la misura è un report di OX Security per il quale gli esperti hanno analizzato 5.095 hostname, cioè gli indirizzi dei server pubblicati in tre registri; l'84,38% risulta ospitato negli Stati Uniti; il 2,3% non è più raggiungibile, e sei di quei domini erano registrabili per 4-12 dollari l'anno.

Dove finiscono i dati, chi gestisce l'infrastruttura che li tocca, quale codice ci gira davvero, che cosa succede quando quell'infrastruttura sparisce o cambia proprietario? Sono le domande che la sicurezza aziendale ha imparato a porre dopo un’esperienza decennale (e tanti problemi) con il cloud, e alle quali sa rispondere con regioni, contratti, audit e policy IAM. Lo stesso non vale per MCP che in molti casi, secondo OX, produce shadow AI infrastructure.

La domanda provocatoria che scaturisce dal report è se lo sforzo decennale e costoso per garantire la residenza dei dati sia una base non negoziabile per la sicurezza aziendale o se valga la pena abbandonarlo per le comodità promesse dall’AI. Ci sono alcuni elementi che permettono di costruire la risposta, sulla falsariga dell’approccio che le aziende usano per difendere il cloud sovrano, denunciare la mancanza di DevSecOps e pretendere guardrail sempre più stringenti sui modelli per mettersi al riparo dal prompt injection. Però poi collegano un agente a un server MCP trovato in un registry con una configurazione scritta alla bell’è meglio.

Ovviamente non si può mettere MCP sul banco degli imputati: il protocollo resta uno strumento, e come ogni strumento, la sua nocività dipende da chi lo usa. Nel nostro precedente approfondimento abbiamo sottolineato che MCP è diventato lo standard de facto dell'AI agentica e che la sua diffusione lo ha trasformato in un bersaglio. A questo giro parliamo di chi lo adotta senza chiedersi se vada messo in sicurezza.

Dove sono ospitati i server MCP

Dieci anni di lezioni

Il confronto proposto dal report si articola su quattro passaggi. Per il cloud l’azienda può fissare regioni e confini contrattuali; il protocollo MCP non prevede alcun concetto di regione geografica o di residenza dei dati. Il cloud è governato da contratti, certificazioni e audit; per un server MCP di terze parti, la responsabilità di valutarlo ricade in gran parte su chi vi si connette. Per quanto riguarda la visibilità, gateway, firewall e CASB permettono di osservare il traffico verso il cloud; una connessione MCP può partire da workstation di sviluppo e da altri ambienti fuori dal perimetro tradizionale. Con un cloud provider esistono rapporti contrattuali e tecnici con fornitori noti; un server MCP pubblicato può essere gestito da uno sviluppatore indipendente, con un backend che il protocollo non verifica.

Il report ricorda che il cloud ha guadagnato la fiducia delle imprese a seguito di anni di pressione regolatoria, garanzie di residenza dei dati e tracce di audit, che sono stati necessari per far accettare alle aziende di affidargli i propri dati. Con MCP quella fase sembra essere stata saltata e la fiducia concessa gratis. Il report precisa, comunque, che il protocollo non è insicuro di per sé, anzi risolve un problema diverso, che è quello di stabilire come dialogano agenti e strumenti, chi debba gestire quegli strumenti, dove debbano girare, quali dati possano ricevere e se il codice in esecuzione corrisponda a quello pubblicato resta fuori dal suo perimetro.

Dove sono i server e chi li gestisce

L'analisi parte da 15.465 server pubblicati nei registri mcp-official-registry, cline-marketplace e github-mcp-registry. Da lì si arriva a 16.296 endpoint, a 7.791 URL univoci e infine a 5.095 hostname. Tutte le percentuali si riferiscono a questi ultimi e non ai server pubblicati.

Dei 5.095 hostname analizzati da OX Security, l'84,38% risolve su infrastrutture statunitensi; tra i primi quindici paesi, Germania, Finlandia, Francia, Irlanda e Paesi Bassi totalizzano insieme circa il 7,75%. Per un'azienda europea significa che la gran parte dei server MCP pubblici risiede fuori dall'UE. Agli estremi della classifica compaiono 19 hostname in Cina e 18 in Russia, rispettivamente lo 0,37% e lo 0,35% del campione. Il report, tuttavia, avverte che la geolocalizzazione non prova dove finiscono i dati, perché CDN, proxy e VPN possono nascondere l'origine.

Inoltre, il report fa più volte la distinzione fra posizione dell'infrastruttura e data residency: il fatto che un server si trovi in un certo paese non dimostra che i dati aziendali vi siano stati inviati. Il problema è che MCP non offre alcun meccanismo standard per dichiarare o far rispettare un requisito di residenza, e chi applica regole severe ai propri carichi cloud fatica a estenderle a un server terzo.

Un altro dato interessante contenuto nel report è che lo 0,45% degli hostname è associato a reti domestiche o a macchine locali esposte tramite servizi di tunneling consumer. In questi casi un server MCP dipende dalla connessione web di una persona, con l'uptime, i controlli di accesso e la tracciabilità che ne conseguono. Spiccano, come potenziali criticità, l'assenza di garanzie di disponibilità, di controlli di accesso standard, di auditabilità e di confini chiari nella gestione dei dati, e gli esperti ricordano che una pipeline AI di produzione può finire per dipendere da infrastrutture mai pensate né governate come tali.

Il 2,3% degli hostname non risolve più via DNS, il che significa che quegli hostname un tempo funzionavano, ed proprio per questo qualcuno li referenzia ancora. Sei domini (lo 0,12% del campione) risultano addirittura non registrati, e i ricercatori hanno verificato che erano disponibili per circa 4-12 dollari l'anno. Una configurazione, uno sviluppatore o una pipeline che continuano a puntare a quell'hostname ereditano la fiducia originaria, e chi registra il dominio può presentare un server che imita l'originale, esporre tool malevoli, raccogliere le informazioni inviate dai client o consegnare contenuti malevoli agli agenti connessi. Il punto quindi non è il costo della registrazione di un dominio, è quello (ben più alto) della fiducia già concessa dalle configurazioni esistenti, che può agevolare gli attaccanti. Nel cloud è uno scenario affine al subdomain takeover, ed è per questo che i team monitorano i record DNS che puntano a risorse dismesse.

Una questione di fiducia

Anche quando il dominio è quello corretto, la fiducia concessa a un server può non avere riscontro in ciò che quel server fa davvero. Il protocollo MCP non richiede che un repository GitHub pubblico corrisponda al codice in esecuzione dietro l'URL di un server, e un server può esporre tool apparentemente innocui, anche se la logica del backend si attiva solo in condizioni specifiche. Uno sviluppatore può esaminare ciò che un server dichiara di fare, ma non necessariamente verificare che cosa faccia il server in esecuzione.

Ne dà un esempio un test di giugno 2026, in cui un server MCP malevolo è stato provato contro Claude Code abbinato al modello Haiku 3.5 ormai datato. Il server si presentava come strumento di scansione del codice; l'agente chiedeva all'utente di approvare l'accesso a un file innocuo e l'utente sceglieva always-allow, l'opzione che evita di essere interpellato di nuovo. Il server chiedeva poi file sensibili e la richiesta veniva eseguita senza chiedere consenso. Con Opus 4.6 e 4.7 l'attacco è fallito, perché il prompt iniettato è stato rilevato e la chiamata bloccata. Si deduce pertanto che l'esito dipende da modello e configurazione.

OX riferisce la risposta di Anthropic: l'always-allow funziona by design e il rilevamento della prompt injection da parte del modello è un'euristica di difesa in profondità, non un confine di sicurezza. Su quest'ultimo punto OX concorda e ne fa il cardine della propria tesi, perché nel test l'esito è stato deciso da ciò che il modello ha riconosciuto dopo che l'utente aveva già concesso la propria fiducia. A prescindere da come si giudichi l'always-allow, la lezione che se ne deduce è che il perimetro va costruito da chi adotta MCP.

Il report propone poi degli scenari che corrispondono a modelli di minaccia, senza sostenere che ogni server sia malevolo. Nel primo scenario uno sviluppatore affida una code review o la generazione di documentazione a un server di terze parti non attendibile, e per svolgerla il codice proprietario viene inviato al server. Se quel server opera fuori dall'infrastruttura approvata, la proprietà intellettuale può uscire dal perimetro senza necessariamente bisogno di un exploit sofisticato. Nel secondo, un server malevolo restituisce contenuti pensati per influenzare l'agente che, a seconda di client, modello e permessi, potrebbe leggere variabili d'ambiente e file riservati, accedere al codice sorgente, eseguire comandi da terminale, usare le credenziali dell'ambiente locale e rimandare le informazioni raccolte attraverso la stessa connessione MCP. In entrambi i casi la connessione può partire dall'ambiente dello sviluppatore, fuori dal perimetro applicativo tradizionale.

Le regole del cloud applicate a MCP

Le linee guida della cloud security contro la realtà degli MCP

Le regole per usare MCP in sicurezza esistono già, perché il cloud le ha rese standard; basta applicarle a MCP sui quattro fronti del confronto con il cloud, ossia residenza dei dati, compliance, visibilità e fiducia nell'infrastruttura.

Per quanto riguarda la residenza, il cloud ha insegnato a decidere in anticipo dove possono girare i carichi e con quali fornitori. Per MCP significa stabilire quali server un agente può raggiungere, con un elenco di server approvati gestito centralmente al posto della scelta estemporanea in un registry pubblico. Ciascuna voce dell'elenco dev'essere valutata per infrastruttura (regione e giurisdizione comprese), operatore e tipo di dati che riceverà. Poiché la geolocalizzazione degli indirizzi può essere imperfetta, la posizione dev’essere confermata con l'operatore e messa per iscritto, e dove possibile i server vanno ospitati in ambienti già coperti da contratto.

Sul fronte della compliance, un server MCP di terze parti che riceve dati aziendali o esegue azioni per conto di un agente svolge di fatto la funzione di un fornitore di servizi, e conviene valutarlo con gli stessi criteri. Per i soggetti NIS2 il tema è già normato, perché la direttiva include tra le misure di gestione del rischio la sicurezza della supply chain, compresi i rapporti con i fornitori diretti o i fornitori di servizi.

Sulla visibilità, la si recupera facendo passare le connessioni MCP verso server remoti da un gateway centrale, come si fa per il traffico verso il cloud, con logging e possibilità di blocco; per i server eseguiti in locale servono controlli sull'endpoint. Le workstation degli sviluppatori vanno coperte per prime, perché secondo il report è da lì, come da altri ambienti fuori dal perimetro tradizionale, che possono partire le connessioni.

Per quanto concerne la fiducia nell'infrastruttura, per i server eseguiti in locale occorrono verifica della provenienza del codice e pinning alla versione esaminata; per quelli remoti il pinning non basta, perché il codice in esecuzione dietro l'URL può non corrispondere a quello pubblicato, e restano l'hosting in proprio o garanzie contrattuali sul codice distribuito. Per tutti serve il monitoraggio dei domini referenziati nelle configurazioni, per intercettare quelli che smettono di risolvere prima che qualcun altro li registri. I processi che eseguono i server in locale devono essere isolati con sandboxing e privilegi minimi, in modo da limitare il raggio d'azione di un comando malevolo. Un always-allow è assimilabile a un permesso IAM permanente, e come tale va limitato per ambito e rivalutato nel tempo.

OX Security propone inoltre quattro misure da adottare a monte, che toccano il protocollo, gli SDK ufficiali e i marketplace. La prima è l'esecuzione basata solo su manifest, in cui il server dichiara in anticipo i comandi che può eseguire e l'agente sceglie soltanto tra quelli. La seconda è una allowlist integrata negli SDK ufficiali, che controlla ogni comando in ingresso e lo lancia solo se figura tra quelli ammessi. La terza è il sandboxing, cioè l'esecuzione dei server in ambienti isolati e con privilegi minimi. La quarta è la verifica obbligatoria dei contenuti da parte dei marketplace prima della pubblicazione. Adottate una sola volta a livello di protocollo o di SDK ufficiale, queste misure si propagherebbero in automatico a tutti i progetti costruiti a valle. In assenza di queste misure, la protezione resta a carico di chi adotta MCP.