Un’analisi dell’infrastruttura del Model Context Protocol indicizzata pubblicamente ha individuato carenze di governance nell’hosting, nella titolarità dei domini e nel codice eseguito dai servizi remoti.
OX Security dichiara di aver esaminato 15.465 schede di server MCP provenienti da cinque registri, per poi ricondurre quei dati a 5.095 hostname univoci. I risultati non descrivono 15.465 operatori distinti o organizzazioni coinvolte: il numero più alto corrisponde alle schede di server indicizzate, quello più basso agli hostname distinti.
Secondo il resoconto della ricerca pubblicato da OX Security, alcuni dei server elencati erano ospitati in giurisdizioni potenzialmente non autorizzate, esposti tramite tunnel consumer o associati a domini che non risultavano più raggiungibili.
Non si tratta di una segnalazione di violazione confermata. Nel resoconto pubblicato, OX non ha identificato vittime, furti di dati verificati o attacchi in corso collegati ai server esaminati. La ricerca descrive invece alcuni modi in cui un agente AI potrebbe affidarsi a un’infrastruttura che in seguito cambia titolarità, posizione o comportamento.
Migliaia di schede riconducono a 5.095 hostname
Il MCP è emerso nel 2024 come standard per collegare modelli AI, agenti software e ambienti di sviluppo integrati a strumenti e fonti di dati esterni. Un server MCP può mettere determinate funzionalità a disposizione di un agente, portando potenzialmente quel servizio all’interno di flussi di lavoro sensibili.
L’analisi di OX ha preso in esame cinque registri MCP, ma il resoconto pubblicato non li identifica né descrive le procedure di ammissione e revisione adottate da ciascuno. Questo limita i confronti tra i registri e impedisce di stabilire se tutti applichino gli stessi controlli.
La distinzione tra schede e infrastrutture è importante. OX ha raccolto 15.465 server indicizzati pubblicamente, ma dopo la deduplicazione il totale è sceso a 5.095 hostname univoci. Più voci nei registri possono quindi rimandare allo stesso hostname.
Le percentuali riportate si riferiscono agli hostname, non alle persone. Non vanno interpretate come il numero di sistemi compromessi, clienti o organizzazioni coinvolte.
A differenza di un tradizionale avviso di sicurezza, la ricerca non identifica una versione difettosa di un prodotto, non assegna un CVE e non fornisce un punteggio di gravità. Il problema è più ampio: gli agenti potrebbero collegarsi a servizi di terze parti senza garanzie sufficienti su chi li gestisce, dove vengono instradate le richieste o quale codice backend le elabora.
La posizione dei server può creare flussi di dati non autorizzati
OX riferisce che il 15,6% degli hostname rimandava a infrastrutture situate al di fuori degli Stati Uniti. Il resoconto cita in particolare 19 hostname in Cina e 18 in Russia, ma non fornisce il dettaglio completo dei dati per paese.
La posizione geografica non dimostra che un server sia dannoso. Può però determinare quale giurisdizione si applica e quali requisiti interni di residenza dei dati devono essere rispettati quando un agente invia a quel servizio prompt, codice sorgente, credenziali o informazioni aziendali.
Un’azienda potrebbe aver approvato uno specifico strumento AI senza aver esaminato separatamente ogni endpoint MCP a cui lo strumento può collegarsi. In questo caso, la connessione di un agente potrebbe creare un flusso di dati al di fuori delle aree geografiche autorizzate dall’organizzazione.
OX descrive inoltre uno scenario in cui un operatore ospita inizialmente un servizio su un indirizzo IP statunitense e in seguito lo reindirizza altrove. I risultati pubblicati non dimostrano che OX abbia osservato una transizione di questo tipo tra i server esaminati: si tratta di uno scenario di minaccia che illustra perché una verifica una tantum della posizione potrebbe non offrire garanzie durature.
La questione pratica è la verifica continua. Un hostname può restare invariato mentre cambia l’infrastruttura sottostante, lasciando intatte le configurazioni degli agenti già in uso.
I tunnel consumer rendono meno certa la titolarità dei server
OX afferma che lo 0,45% degli hostname esaminati instradava il traffico attraverso servizi di tunneling consumer, soprattutto ngrok-free.
Un tunnel può esporre un’applicazione in esecuzione in locale senza che l’operatore debba distribuirla su un’infrastruttura di hosting tradizionale. È una soluzione utile per dimostrazioni e sviluppo, ma offre alle aziende meno informazioni sull’ambiente che si trova dietro l’endpoint pubblico.
OX descrive i servizi raggiungibili tramite tunnel inclusi nell’elenco come eseguiti su computer personali. Ritiene inoltre che probabilmente si collegassero tramite reti domestiche, ma questa valutazione sulla posizione di rete è un’inferenza, non un risultato confermato per ogni endpoint.
Il problema riguarda il controllo operativo, non una compromissione dimostrata della piattaforma di tunneling. Un servizio MCP elencato pubblicamente potrebbe dipendere dal computer di una singola persona, da procedure di distribuzione informali o da un’infrastruttura che non rientra nei normali sistemi aziendali di monitoraggio e gestione delle modifiche.
Questo può incidere anche sulla disponibilità, oltre che sulla sicurezza. L’agente vede un endpoint raggiungibile, ma l’operatore potrebbe non offrire le garanzie su identità, ciclo di vita e supply chain attese da un servizio aziendale.
I domini scaduti possono trasferire l’identità di un server considerato affidabile
OX ha rilevato che il 2,3% degli hostname non risultava più raggiungibile. Secondo la ricerca, sei erano associati a domini scaduti e disponibili per la registrazione a un costo stimato di 4–12 dollari all’anno.
Questo crea un potenziale problema di trasferimento dell’identità. Se un agente continua a essere configurato per contattare uno di quei domini, un nuovo titolare potrebbe riattivare l’hostname e iniziare a ricevere le richieste future destinate al precedente operatore MCP.
Il dominio può diventare prezioso perché le configurazioni dei client potrebbero continuare a considerarlo affidabile anche dopo la scadenza. Gli utenti potrebbero riconoscere il nome del server, mentre gli agenti automatizzati potrebbero non distinguere il precedente operatore dal nuovo titolare.
OX non riferisce che uno dei sei domini sia stato effettivamente registrato da un aggressore. Il resoconto non documenta nemmeno l’intercettazione di richieste tramite quei domini. Il risultato individua una possibile via di takeover, non un takeover già avvenuto o un’esposizione confermata.
L’impatto dipenderebbe inoltre dal modo in cui l’agente utilizza l’endpoint. I dati pubblicati non chiariscono quali strumenti, autorizzazioni o informazioni fossero a disposizione dei client configurati per i domini interessati.
Un repository pubblico non dimostra quale codice venga eseguito da un server remoto
La ricerca mette anche in discussione un presupposto comune nelle verifiche del software: che esaminare un repository pubblico basti a stabilire come si comporta un servizio MCP remoto.
Esaminare un repository può aiutare a valutare il codice sorgente, le dipendenze e le funzionalità dichiarate. Ma, se gli utenti non possono verificare il legame tra quel codice e il servizio distribuito, il backend remoto potrebbe eseguire una build diversa o una logica del tutto differente.
OX afferma che nei marketplace MCP manca un sistema equivalente ai controlli anti-malware degli app store e sostiene che gli editori possano rendere disponibili i server senza verifiche comparabili. Il resoconto non indica i cinque registri né documenta i controlli specifici che adottano; sulla base delle informazioni disponibili, quindi, questa valutazione non può essere estesa indistintamente a ciascuno di essi.
L’articolo cita Google Bouncer, il sistema che Google utilizzava nel 2012 per analizzare le applicazioni Android, come termine di paragone. Riconosce anche che i ricercatori hanno trovato modi per aggirare Bouncer. Lo screening non offre quindi garanzie assolute, ma può aggiungere un livello di verifica che, secondo OX, nell’ecosistema MCP manca.
Secondo quanto riferito, il rapporto completo di OX, intitolato “15,465 MCP Servers, 0 Governance”, include una prova di concetto di prompt injection e ulteriori scenari di minaccia. Il riepilogo pubblicato non fornisce dettagli tecnici sufficienti per determinare in quali condizioni sia valida la prova di concetto o se sia stata testata contro un servizio di terze parti attivo.
Alle aziende servono controlli sulla connessione, non solo sul codice
OX chiede ai marketplace MCP di introdurre verifica dei marketplace, firma del codice e verifica dell’origine. Nel loro insieme, queste misure aiuterebbero a rispondere a tre domande diverse: chi può pubblicare, se un artefatto è stato modificato e se un servizio remoto corrisponde alla fonte prevista.
Le organizzazioni che utilizzano MCP possono anche includere queste connessioni nei programmi di governance già esistenti. Tra le pratiche indicate nella ricerca figurano regole di data residency, confini Zero Trust, gestione granulare delle identità e degli accessi (IAM) e audit della supply chain.
Applicate alle distribuzioni MCP, queste misure significano sapere quali agenti possono raggiungere quali server e verificare che gli endpoint restino entro i limiti approvati per giurisdizione e titolarità. Lo stato di un dominio e la posizione dell’hosting non sono proprietà permanenti: un’approvazione basata su una verifica iniziale potrebbe quindi diventare obsoleta.
Anche l’esame del repository dovrebbe essere considerato una fonte di informazioni, non una prova del comportamento in fase di esecuzione. Nei flussi di lavoro che trattano informazioni sensibili, le organizzazioni devono ottenere garanzie sul servizio distribuito e sul suo operatore, non soltanto sul codice presentato in un progetto pubblico.
OX richiama inoltre una ricerca precedente su vulnerabilità nel codice sorgente MCP di Anthropic, definendole critiche e affermando che il codice era stato scaricato più di 150 milioni di volte. Il resoconto disponibile non fornisce identificativi CVE, versioni interessate, prove tecniche o dettagli sulle misure correttive adottate per quei risultati precedenti. Non è quindi possibile valutarli nell’ambito dell’attuale analisi dei server.
Le nuove misurazioni restano risultati di OX e non sono state convalidate in modo indipendente nel materiale disponibile per questo articolo. Descrivono comunque un problema concreto di governance: il rapporto di fiducia di un agente AI può sopravvivere all’infrastruttura, al titolare del dominio o all’implementazione software che lo giustificavano inizialmente.
