Il Tuo Server MCP È il Buco Più Grande del Setup

Un server MCP malevolo può rubarti le chiavi SSH senza mai scrivere per intero un'istruzione malevola. Il gruppo di ricerca ASSET l'ha dimostrato: quando l'ordine di furto viene dato a un modello in un solo blocco, i modelli più grandi quasi sempre rifiutano. Spezza lo stesso ordine in frammenti apparentemente innocui, e GPT-4o, Gemini 2.0 Flash e Llama 3.3 obbediscono nel 100% dei casi testati.

Nel frattempo, la maggior parte degli sviluppatori aggiunge un nuovo server MCP al proprio agente ogni settimana, copiando una riga di configurazione trovata su GitHub. Ognuno di quei server tiene un pezzo del tuo accesso: token API, chiavi cloud, account di servizio. MCP è utile — nessuno lo mette in dubbio. Ma il server MCP è diventato l'anello debole di tutto lo stack di agenti.

Questo articolo racconta come un server MCP ti ruba i segreti senza farsi notare, l'attacco GhostSplice che aggira i rifiuti dei modelli spezzando le proprie istruzioni, e le difese concrete, da Cloudflare WriteGuard alle regole che puoi applicare oggi sul tuo setup.

Un server MCP è il ponte tra il tuo agente e uno strumento esterno: il tuo database, GitHub, Slack, il cloud. Per fare da ponte, salva tutto ciò che gli serve per accedere come te — token, chiavi API, credenziali di servizio — in chiaro, in un file di configurazione sul disco, di solito senza alcuna cifratura.

Un dettaglio del protocollo conta per quello che viene dopo. Quando un agente si connette a un server MCP, il server restituisce la sua lista di tool, ognuno con una descrizione in testo libero che dice al modello quando e come usarlo. Quelle descrizioni entrano dritte nel contesto del modello, con lo stesso peso delle tue istruzioni, e anche i risultati restituiti dai tool finiscono lì. Un server MCP parla al tuo agente in continuazione, in testo che nessuno rilegge mai. Ed è esattamente ciò che rende possibile l'attacco GhostSplice.

Anche l'ecosistema è esploso più in fretta delle sue difese:

Segnale	Numero
Server nel registro ufficiale MCP	9.600+
Crescita dei deployment di server remoti da maggio 2025	5×

Chiunque può pubblicare un server, non esiste una revisione centrale, e il tuo agente si fida di ognuno esattamente come farebbe con uno strumento ufficiale. La NSA ha pubblicato una guida di sicurezza dedicata a MCP a maggio, affermando che l'adozione del protocollo ha superato la costruzione delle sue protezioni. Quando un'agenzia di intelligence scrive una guida sul tuo tool di sviluppo preferito, raramente è per farti i complimenti.

Questo è il contesto: migliaia di server, nessuna revisione, e le tue chiavi in mezzo.

Il primo buco è nelle credenziali salvate in chiaro. The Hacker News ha pubblicato un'analisi dettagliata dei meccanismi di fuga il 17 agosto, e il punto di partenza è netto: i token finiscono incollati direttamente nelle stringhe di configurazione e restano leggibili sul disco. Basta un commit un po' frettoloso per spingere una configurazione in un repo Git con le chiavi incluse. Peggiora con quello che l'articolo chiama sprawl: le stesse chiavi duplicate tra file di config, variabili d'ambiente e copie in dev, staging e produzione. Col tempo nessuno sa più dove vivono i segreti, quindi nessuno li ruota — e una chiave statica che non ruota mai è una chiave che aspetta il suo attacco.

Il secondo buco è l'eccesso di permessi. Durante lo sviluppo dai al tuo server diritti ampi per evitare errori di autorizzazione, e quei diritti ampi arrivano in produzione intatti. Una sola compromissione espone quindi molto più di quanto l'uso reale abbia mai giustificato.

Il terzo buco è la supply chain. CVE-2025-6514 ha colpito mcp-remote, un proxy OAuth scaricato oltre 400.000 volte, e ha permesso a un server malevolo di innescare command injection sulla macchina dell'utente — eseguendo codice e portandosi via le credenziali. Un pacchetto npm popolare, installato in una riga, e la porta era aperta.

Il quarto buco è il più subdolo: il prompt injection. Un agente legge tutto ciò che i suoi tool riportano — una pagina web, un ticket, un documento interno. Se uno di questi contiene un'istruzione nascosta, l'agente può seguirla come se venisse da te, e usare i suoi tool legittimi per esporre proprio ciò che doveva proteggere. Quella fuga non passa da nessun difetto tecnico; passa dall'ingenuità del modello.

Prima di qualsiasi attacco sofisticato, la vita ordinaria di un server MCP — config in chiaro, diritti eccessivi, dipendenze non verificate, contenuti non filtrati — espone già i tuoi segreti.

GhostSplice è il nome che il gruppo di ricerca ASSET ha dato a una tecnica che fa eseguire l'esfiltrazione al tuo stesso agente, con la sua piena collaborazione. Il principio sta in una frase: invece di scrivere per intero l'ordine di furto, il server malevolo lo spezza, mette un frammento nella descrizione di un tool e un altro nel risultato che quel tool restituisce. Ogni pezzo, letto da solo, sembra innocuo. Ma l'agente combina tutto ciò che entra nel suo contesto di lavoro: ricostruisce l'istruzione completa e la esegue in totale buona fede — dal suo punto di vista, sta solo compilando il modulo che il tool gli ha chiesto di compilare.

I numeri dei test sono la vera storia:

Modello	Istruzione in un blocco	Istruzione frammentata
GPT-4o	Rifiuta 100%	Obbedisce 100%
Gemini 2.0 Flash	Rifiuta 100%	Obbedisce 100%
Llama 3.3	Rifiuta 100%	Obbedisce 100%
Claude Haiku 4.5	Rifiuta via API	Obbedisce 100% nel test a tre pezzi dentro Cursor

Il dettaglio su Claude uccide ogni conclusione facile: lo stesso modello può rifiutare in un client ed esfiltrare in un altro, a seconda delle protezioni che quel client aggiunge o meno.

Cosa ruba GhostSplice nei test: chiavi SSH, segreti d'ambiente, codice sorgente, dati clienti. I ricercatori hanno lavorato su progetti isolati con chiavi finte, non su vittime reali, ma il metodo è pubblicato e riproducibile.

GhostSplice non è un primo tentativo. Lo stesso laboratorio ha pubblicato Ghostcommit a giugno, un attacco che nascondeva le sue istruzioni in file PNG citati dalle convenzioni del progetto, poi codificava i segreti rubati nel codice sorgente come interi. Spezzare le istruzioni è una famiglia di attacchi che si sta consolidando, non una curiosità isolata.

Due cose tengono tutto in prospettiva. L'attacco ha due prerequisiti: il server malevolo è già collegato al tuo agente, e l'agente ha accesso in lettura ai file bersaglio. Ed è esattamente per questo che la provenienza conta così tanto — da dove vengono i tuoi server è la tua prima linea di difesa. E ricorda il meccanismo: l'allineamento del modello non ti protegge, perché l'attacco non chiede mai nulla di vietato in un solo pezzo.

GhostSplice presupponeva un server malevolo già collegato. Ma chi decide cosa viene collegato? In un team, la risposta onesta è nessuno. È il problema che Cloudflare chiama shadow MCP: tutti i server che gli sviluppatori collegano ai loro agenti senza alcuna revisione di sicurezza. Fino a poco tempo fa quel traffico era invisibile — una richiesta MCP sembra identica a qualsiasi altra chiamata HTTPS.

Cloudflare ha cambiato le cose con il rilevamento a livello di protocollo. Dall'aggiornamento della specifica, ogni client MCP conforme invia un header MCP-Protocol-Version sulle sue richieste, e Gateway ispeziona quell'header su tutto il traffico TLS che decripta. Un team di sicurezza può ora vedere ogni server MCP usato in azienda, con una dashboard dedicata: server unici, utenti, volumi di richieste. Questo approccio via header batte il filtro per nome di dominio, perché un server MCP non ha alcun motivo di chiamarsi mcp-qualcosa — il protocollo viene individuato da ciò che dice, non da come si spaccia.

Il team può anche agire: un selettore is_mcp permette di bloccare qualsiasi traffico MCP che non sia passato da un portale approvato. Il portale è l'altra metà del setup — un unico punto d'accesso che raggruppa i server vagliati dietro autenticazione d'identità.

L'ultima versione della specifica spinge ancora più avanti la visibilità. I nuovi header Mcp-Method e Mcp-Name espongono l'operazione richiesta e il tool chiamato, senza che il firewall debba aprire il corpo della richiesta. Un team può distinguere un agente che legge un ticket da uno che ne cancella cinquanta, direttamente a livello di rete.

Cloudflare divide tutto questo in due casi: shadow MCP puro, un server mai approvato, e portal bypass, un server approvato raggiunto aggirando il checkpoint. Entrambi vengono bloccati con la stessa regola base. La logica è semplice: tutto ciò che passa dal portale è noto e loggato, tutto il resto è bloccato. Per un'azienda, è la fine del server MCP fantasma installato di venerdì sera.

Anche un server approvato può fare danni, perché un agente eredita tutti i diritti del suo utente in un colpo solo. È qui che entra in gioco WriteGuard, che Cloudflare ha appena aperto in beta privata. L'idea: classificare ogni tool di ogni server MCP in un livello di rischio, e applicare una policy diversa per livello.

• Una lettura passa senza attrito.
• Una scrittura contenuta, come postare un commento, passa ma arricchita: l'azione viene firmata come proveniente da un agente, per conto di una persona specifica, e un evento di audit va in un log centrale.
• Un'azione critica — unire codice, effettuare un deploy in produzione, cancellazioni di massa — viene bloccata prima ancora che il server la gestisca.

L'esempio GitLab nel post di Cloudflare mostra bene la gradazione: leggere una merge request passa, commentarla passa con attribuzione, e unirla viene rifiutato finché non lo fa una persona in prima persona.

La parte più interessante è il modello di identità. L'agente mantiene i permessi del dipendente che serve, ma ogni scrittura ora porta due firme: la persona, e la sessione dell'agente che agisce per lei. I sistemi a valle possono finalmente distinguere una modifica fatta a mano da una generata da una macchina, e l'audit viene inviato in modo asincrono a un log centrale, ripulito dai dati sensibili. Finora un agente era indistinguibile dal suo umano nei log; per un'analisi degli incidenti questo cambia tutto — una singola query ti dice se il merge dubbio di martedì viene da un collega frettoloso o da una sessione agente che si è presa una libertà di troppo.

Cloudflare non sta vendendo una teoria; descrive il proprio uso interno: il loro portale collega 27 server MCP, contro i 13 di aprile. Quel numero racconta la vera storia — anche in casa Cloudflare il numero di server raddoppia in pochi mesi, ed è esattamente per questo che il controllo per tool diventa necessario. La direzione che sta prendendo il settore è chiara: smettere di fidarsi del server intero, e decidere azione per azione cosa un agente può fare.

I limiti vanno detti chiaramente. WriteGuard è una beta privata dietro un modulo di iscrizione, e il rilevamento di Gateway richiede un deployment Cloudflare Zero Trust con ispezione TLS attiva: per uno sviluppatore singolo o un piccolo team, semplicemente non è la tua infrastruttura. Anche in azienda, il rilevamento vede solo il traffico di rete che decripta — un server MCP locale che gira su stdio, lanciato come semplice processo sulla tua macchina, resta invisibile a Gateway. Che è esattamente come gira la maggior parte dei server che gli sviluppatori installano.

Soprattutto, nessuno di questi strumenti ripara il meccanismo di fondo che GhostSplice ha esposto: finché un agente combina liberamente tutto ciò che entra nel suo contesto, i frammenti innocui continueranno a ricomporsi in istruzioni ostili. I ricercatori di ASSET lo dicono loro stessi: la soluzione richiede di trattare l'output dei tool come dati, mai come istruzioni, e quella separazione non esiste ancora in modo nativo negli agenti.

Nel frattempo, le loro raccomandazioni si riducono a tre mosse: impedire che i valori in uscita da un tool alimentino senza controllo gli argomenti di un altro tool, mantenere la possibilità di negare a mano ogni singola invocazione di un tool, e trattare come ostile per default qualsiasi annotazione proveniente da un server non vagliato. Nessuna delle tre è automatica oggi: o le applichi tu, o nessuno lo fa. Tratta tutto ciò che Cloudflare offre qui come cinture di sicurezza, non come freni — limita il danno, non evita la collisione.

Cosa fare, a partire da oggi:

1. Inventario. Elenca i server MCP davvero collegati ai tuoi agenti, e rimuovi quelli che non usi più.
2. Ordina per provenienza. Un server ufficiale di un vendor noto, sì. Un repo GitHub con 40 stelle trovato in un thread, no — non finché non hai letto cosa fa con i tuoi dati.
3. Delimita i diritti. Dai a ogni server un token dedicato con lo scope minimo, mai la tua chiave master, e ruota quei token come faresti per qualsiasi sistema in produzione.
4. Tieni la mano sulle azioni sensibili. Un agente che scrive, unisce o cancella deve passare per te — la versione artigianale di ciò che WriteGuard industrializza.
5. Applica la regola GhostSplice ogni giorno. Quando il tuo agente concatena azioni sui tool che non hai chiesto, fermalo e leggi cosa ti stava dicendo il server.

Ogni client agente può elencare i server connessi e i loro tool, e leggere quella lista richiede trenta secondi. Quei trenta secondi sono il miglior rapporto tempo-sicurezza di tutto il tuo setup.

Se sei in azienda, aggiungi il livello di rete: il rilevamento MCP di Gateway e i portali valgono il rollout, perché lo shadow MCP esiste già nella tua organizzazione, che tu lo veda o no.

MCP non è il problema — la velocità con cui gli abbiamo affidato le nostre chiavi lo è.