Cloudflare: come il rilevamento MCP trasforma il traffico shadow degli agenti in una decisione di sicurezza

Cloudflare ha esteso il rilevamento del traffico MCP oltre i nomi di server più evidenti, facendo emergere un conflitto che in precedenza i team di sicurezza potevano non notare. La questione del “come” per Cloudflare parte ora dalle evidenze del protocollo, non da un elenco di domini noti. Gateway può ispezionare il traffico HTTP gestito alla ricerca di percorsi specifici di MCP e metodi JSON-RPC, distinguendo poi il traffico approvato attraverso Portal dalle connessioni dirette.

Questa distinzione è importante perché il Model Context Protocol, o MCP, consente agli agenti AI di richiamare strumenti esterni e recuperare dati privati. Una singola connessione può raggiungere codice sorgente, record dei clienti, controlli cloud o sistemi di messaggistica. Quando i dipendenti configurano server remoti senza revisione, la conseguente attività MCP shadow assomiglia allo shadow IT, ma con un agente capace di eseguire azioni.

La risposta di Cloudflare combina individuazione e applicazione delle policy. Gateway fornisce il segnale di rete, mentre i portali per server MCP centralizzano i server approvati dietro un unico endpoint. Le policy Access regolano identità e condizioni dei dispositivi, mentre la prevenzione della perdita di dati, o DLP, può ispezionare richieste e risposte degli strumenti. La questione irrisolta è se le organizzazioni riusciranno a instradare abbastanza traffico attraverso questi controlli da rendere affidabile il modello.

Come il rilevamento MCP di Cloudflare legge il protocollo

Il cambiamento più importante di Cloudflare è il passaggio dall’ipotesi sulle destinazioni al riconoscimento del comportamento MCP nel traffico HTTP ispezionato.

Il metodo di rilevamento più semplice osserva il nome host di destinazione. Un amministratore può cercare nei log di Gateway endpoint MCP noti o nomi host contenenti mcp. Questo approccio intercetta servizi che dichiarano il proprio scopo tramite nomi come mcp.example.com.

Un secondo segnale proviene dall’URI della richiesta. I server remoti espongono comunemente percorsi come /mcp, /sse o /mcp/sse. Gateway può cercare queste sequenze nelle richieste registrate anche quando il nome host appare generico.

Entrambi i metodi sono utili per un inventario iniziale, ma nessuno dei due dimostra che una richiesta trasporti MCP. Un’applicazione normale può usare lo stesso percorso. Un server MCP può inoltre celarsi dietro un nome host ordinario e una rotta API poco riconoscibile.

Cloudflare indirizza quindi gli amministratori verso l’ispezione del corpo. MCP codifica i messaggi con JSON-RPC, un formato di richiesta strutturato che contiene campi quali jsonrpc, method e params. I nomi standard dei metodi creano evidenze riconoscibili a livello di protocollo.

Tra gli esempi figurano initialize, tools/list, tools/call, resources/read e prompts/get. Un profilo DLP può cercare queste stringhe nei corpi POST, anche quando dominio e percorso non rivelano nulla. Cloudflare ha pubblicato espressioni regolari di esempio nella sua architettura MCP che coprono diversi metodi comuni e campi relativi alla versione del protocollo.

Il metodo initialize è particolarmente utile perché avvia la relazione tra un client MCP e un server. Un client dichiara versione del protocollo, capacità, nome e versione. Il server risponde con le proprie capacità e può creare una sessione.

Le chiamate agli strumenti producono un segnale operativo più forte. Una richiesta contenente tools/call indica che l’agente sta tentando di invocare una capacità, non semplicemente di verificare se esista un endpoint. Gli argomenti possono inoltre rivelare quali dati o azioni lo strumento gestirà.

Il modello di Cloudflare è quindi stratificato:

• I pattern dei nomi host identificano server MCP noti o dal nome esplicito.

• I pattern URI identificano endpoint MCP remoti convenzionali.

• I metodi JSON-RPC identificano il comportamento MCP su endpoint meno evidenti.

• I campi relativi a utente e dispositivo collegano quel comportamento a una persona o a un sistema gestito.

• Le azioni di Gateway mostrano se la richiesta è stata consentita, bloccata o gestita in altro modo.

Il flusso di lavoro documentato da Cloudflare utilizza il dataset gatewayHttpRequestsAdaptiveGroups nella sua API GraphQL Analytics. Gli amministratori possono raggruppare i risultati per host, URI, utente, azione e profili DLP corrispondenti. Secondo il tutorial sul rilevamento dell’azienda, il dataset supporta query storiche fino a 30 giorni.

Non si tratta di rilevamento delle minacce consapevole dei contenuti nel senso più ampio. Una corrispondenza su tools/call indica che è stato invocato uno strumento MCP. Non determina se lo strumento sia affidabile, se le sue istruzioni siano dannose o se l’azione corrisponda all’intento dell’utente.

Ciononostante, il riconoscimento del protocollo colma un’importante lacuna di visibilità. Un team di sicurezza non deve più conoscere ogni fornitore o endpoint MCP prima di avviare un’indagine. Può cercare le proprietà del protocollo stesso.

Questo crea la tensione centrale dell’articolo. Il rilevamento può rivelare traffico MCP diretto, ma un segnale da solo non stabilisce quali connessioni debbano rimanere disponibili. Cloudflare necessita di un’alternativa governata prima che un amministratore possa bloccare il percorso non gestito senza interrompere attività legittime.

Shadow MCP mette i team di sicurezza tra accesso e adozione

La pressione immediata ricade sui team di sicurezza, che devono separare le connessioni agentiche utili dall’accesso non revisionato a sistemi sensibili.

MCP standardizza il modo in cui un’applicazione AI scopre strumenti, legge risorse, recupera prompt e invoca azioni. Il protocollo riduce il lavoro di integrazione personalizzata, rendendo al contempo più semplice per dipendenti e sviluppatori aggiungere server senza un progetto di distribuzione centralizzato.

Questa velocità crea un problema di governance familiare. Un utente può configurare un client MCP con l’URL di un server remoto e concedere l’accesso tramite OAuth o un’altra credenziale. Il team di sicurezza potrebbe non vedere mai questa configurazione nel catalogo software approvato.

Il rischio è maggiore di una visita a un’applicazione web non autorizzata. Un server MCP espone strumenti a un agente, e tali strumenti possono avere permessi rilevanti. A seconda dell’integrazione, potrebbero cercare documenti, leggere repository, aprire record di assistenza, modificare infrastrutture o inviare messaggi.

Uno strumento legittimo può comunque ricevere dati inappropriati. Un dipendente potrebbe chiedere a un agente di analizzare un problema di un cliente, inviando poi inconsapevolmente informazioni regolamentate a un server esterno. Un server compromesso o ingannevole potrebbe anche restituire istruzioni progettate per manipolare il successivo comportamento dell’agente.

Per questo Cloudflare descrive le connessioni non gestite come shadow MCP. Il problema decisivo non è che ogni server sconosciuto sia ostile. È che l’organizzazione non ha esaminato il server, il suo gestore, le autorizzazioni richieste o i dati che lo attraversano.

I log di Gateway possono trasformare questa attività sconosciuta in un inventario. Gli amministratori possono identificare utenti, host di destinazione, volumi di richieste, azioni delle policy e metodi del protocollo rilevati. Possono quindi indagare quale client abbia generato il traffico e quale finalità aziendale svolga.

L’inventario supporta anche un’applicazione delle policy più graduale. Un team potrebbe registrare le corrispondenze iniziali, esaminare le destinazioni attive e classificare ogni server prima di bloccare qualsiasi cosa. I casi ad alta confidenza, come il traffico diretto verso uno strumento remoto non approvato, possono ricevere una policy più restrittiva.

Tuttavia, la copertura della rete gestita definisce il confine. Gateway deve fungere attivamente da proxy per il traffico HTTP pertinente. Se un dipendente usa un dispositivo non gestito, un percorso di rete separato o un client esterno ai controlli dell’organizzazione, tali richieste non compariranno negli stessi log.

Il traffico cifrato aggiunge un’altra condizione. Gateway necessita della decrittazione TLS per ispezionare il corpo HTTP di una connessione MCP diretta. Senza di essa, gli amministratori potrebbero vedere il nome host di destinazione ma non i metodi JSON-RPC e gli argomenti degli strumenti.

Cloudflare gestisce diversamente il traffico Portal. Il Portal termina la connessione del client e crea una nuova connessione al server upstream. Questa architettura consente a Gateway di ispezionare il traffico Portal instradato senza dipendere dall’impostazione di decrittazione TLS valida per l’intero account.

Il traffico diretto non riceve questo trattamento automatico. La documentazione Portal di Cloudflare afferma che un agente che si connette direttamente tramite un dispositivo gestito da WARP richiede la normale configurazione di decrittazione TLS per l’ispezione del corpo.

Esistono inoltre ragioni legittime per esentare il traffico dall’ispezione. Requisiti di privacy, applicazioni con certificate pinning o vincoli operativi possono portare i team a creare policy Do Not Inspect. Queste policy hanno precedenza e possono lasciare l’attività MCP corrispondente al di fuori dell’analisi DLP.

Questi limiti non rendono inutile il rilevamento. Definiscono ciò che la dashboard risultante indica effettivamente. Un report mostra attività simili a MCP visibili su percorsi gestiti e ispezionati. Non è un censimento completo di ogni connessione agentica nell’azienda.

Questa distinzione dovrebbe orientare la risposta agli incidenti. Una connessione rilevata merita un’indagine, ma un report vuoto non dimostra l’assenza di shadow MCP. I team di sicurezza necessitano di copertura degli endpoint, dati di identità e controlli sulla configurazione dei client oltre al rilevamento di rete.

Il vero confronto è tra accesso Portal e connessioni dirette

Il modello di sicurezza di Cloudflare diventa applicabile solo quando l’accesso Portal approvato sostituisce gli URL diretti dei server sui percorsi gestiti.

Un portale per server MCP aggrega più server approvati dietro un unico endpoint HTTP. Gli utenti configurano tale endpoint nel proprio client MCP, si autenticano tramite Cloudflare Access e ricevono solo i server e gli strumenti consentiti dalla policy.

Il Portal svolge diversi compiti che le connessioni dirette distribuiscono tra singole integrazioni. Identifica l’utente, valuta le regole Access, gestisce l’autenticazione upstream, espone gli strumenti approvati e registra le richieste. Gli amministratori possono organizzare i server senza chiedere a ogni dipendente di mantenere un elenco separato di endpoint.

Le policy Access possono usare gruppi di identità, posizione e postura del dispositivo. Un portale finanziario potrebbe esporre strumenti selezionati in sola lettura ai dipendenti dell’area finance. Un portale engineering potrebbe consentire azioni aggiuntive solo da dispositivi aziendali gestiti.

Gli amministratori possono anche nascondere singoli strumenti o prompt. È importante perché l’approvazione di un server non richiede l’approvazione di tutte le capacità che pubblica. Un server con accesso ai repository potrebbe esporre operazioni di ricerca e lettura, mentre la sua operazione di scrittura rimane non disponibile.

Il design Portal di Cloudflare supporta server upstream non autenticati e server protetti da OAuth. Gli utenti possono autenticarsi separatamente presso un servizio upstream, oppure alcuni flussi di lavoro machine-to-machine possono usare token di servizio Access. Il Portal allega quindi le credenziali appropriate quando instrada una chiamata a uno strumento.

Quando è abilitato l’instradamento Gateway, le chiamate in tempo reale passano dal Portal attraverso Gateway prima di raggiungere il server upstream. Gateway registra le richieste e può applicare policy HTTP e DLP. I controlli di egress possono inoltre assegnare a tali richieste indirizzi di origine prevedibili.

Questo crea uno schema pratico di autorizzazione e blocco. I team di sicurezza forniscono ai dipendenti un endpoint Portal approvato, quindi creano regole Gateway che interrompono le connessioni dirette ai server MCP upstream. Il percorso Portal rimane disponibile, mentre le alternative non governate vengono limitate.

La policy deve avere come destinazione corretta l’host appropriato. Cloudflare afferma che le regole DLP per il traffico Portal dovrebbero corrispondere al nome host del server MCP upstream, non solo al dominio Portal. Il Portal è il punto di ingresso rivolto al client, ma Gateway valuta la richiesta ri-originata che viaggia verso il server effettivo.

La disposizione assomiglia più a un gateway applicativo che a una semplice directory. Fornisce un punto di controllo in cui convergono identità, selezione degli strumenti, logging e controlli sui dati. È questo punto di controllo a trasformare la scoperta in governance.

Eppure l’URL diretto resta una debolezza centrale. Cloudflare avverte che nascondere un server da un Portal non impedisce a un utente di connettersi al suo indirizzo originale. Se il server upstream rimane accessibile pubblicamente, la sola policy del Portal non può impedire l’aggiramento.

Le organizzazioni necessitano quindi di un controllo di enforcement esterno all’interfaccia del Portal. Possono proteggere un server con Access quando ne controllano l’hostname, limitare il traffico in ingresso a indirizzi di egress noti oppure bloccare le destinazioni dirette tramite Gateway. I servizi di terze parti richiederanno i controlli supportati dal rispettivo modello di deployment.

La scelta non è tra Cloudflare e un altro fornitore di sicurezza. Il confronto principale è tra accesso governato tramite Portal e connessioni dirette configurate dagli utenti. Ogni funzionalità principale è al servizio di questa sfida.

I log del Portal identificano l’attività approvata. La discovery di Gateway cerca traffico al di fuori del percorso approvato. Access stabilisce chi può utilizzare il Portal. DLP valuta i dati che attraversano il percorso gestito. Le policy di rete cercano di chiudere il percorso diretto.

Questo modello offre inoltre agli sviluppatori una destinazione utilizzabile dopo l’avvio dell’enforcement. Un divieto generalizzato di MCP spingerebbe la sperimentazione al di fuori dei canali ufficiali. Un Portal curato consente ai team di mantenere disponibili gli strumenti approvati mentre la sicurezza esamina server aggiuntivi.

Il risultato dipende dalla disciplina operativa. Qualcuno deve essere responsabile del catalogo dei server approvati, esaminare le autorizzazioni degli strumenti, mantenere le policy di Access e rispondere alle destinazioni rilevate di recente. La centralizzazione riduce i controlli frammentati, ma non elimina queste decisioni.

Le euristiche di protocollo offrono copertura, non certezza

Cloudflare può identificare forti indicatori di MCP, ma tali indicatori non dimostrano che una connessione sia sicura, dannosa o correttamente governata.

I pattern di rilevamento sono euristiche. Un body contenente "method":"tools/call" somiglia molto a MCP, ma un’altra applicazione JSON-RPC potrebbe usare lo stesso nome di metodo. Un’implementazione MCP personalizzata potrebbe inoltre produrre una formattazione al di fuori di una regular expression scritta in modo restrittivo.

Le tolleranze per gli spazi bianchi illustrano il problema. Le espressioni di esempio consentono una quantità limitata di spaziatura attorno ai campi JSON. I campi riordinati dovrebbero restare rilevabili quando ciascun pattern punta a un singolo campo, ma serializzazioni ed escape alternativi possono complicare la corrispondenza.

Il traffico cifrato o non supportato crea lacune maggiori. DLP non può ispezionare un body HTTPS diretto a meno che Gateway non lo decifri. I server MCP locali che comunicano tramite input e output standard non attraversano affatto un gateway HTTP.

Streamable HTTP è il trasporto remoto più importante nell’attuale progettazione di Cloudflare. La specifica di trasporto MCP definisce richieste HTTP che trasportano messaggi JSON-RPC e identificatori di sessione facoltativi. Queste strutture regolari aiutano Gateway a riconoscere il protocollo.

Il percorso Portal instradato di Cloudflare supporta Streamable HTTP. Se un server upstream supporta solo il vecchio trasporto Server-Sent Events, l’instradamento Gateway fallirà per quel server. Il Portal tenta Streamable HTTP quando l’instradamento è abilitato, ma il servizio upstream deve supportarlo.

La sincronizzazione in background rappresenta un’altra eccezione. I Portal recuperano periodicamente strumenti e prompt dai server upstream, ma Cloudflare afferma che tali richieste di sincronizzazione non passano attraverso Gateway. Solo le chiamate agli strumenti degli utenti in tempo reale ricevono l’ispezione instradata documentata.

Anche la copertura DLP presenta limiti specifici del prodotto. Cloudflare afferma che i suoi profili per prompt AI non si applicano al traffico MCP Portal, perché tali profili prevedono percorsi e formati API diversi. Gli amministratori devono utilizzare profili DLP standard.

Le regole Do Not Inspect restano efficaci per il traffico Portal. Sebbene l’instradamento Portal consenta la decrittazione automatica, un’esenzione esplicita impedisce l’ispezione del payload. Un’eccezione ampia potrebbe quindi rimuovere la protezione DLP da un server upstream approvato.

Anche le policy di identità presentano avvertenze. Cloudflare documenta che MFA indipendente, giustificazione dello scopo e autenticazione temporanea non vengono applicate ai server autorizzati tramite un Portal. I selettori per email, gruppo, paese e postura del dispositivo continuano invece ad applicarsi.

Questi vincoli sono importanti perché un Portal può apparire più restrittivo del suo effettivo percorso di policy. Un amministratore potrebbe assegnare un requisito a livello di server e presumere che gli utenti lo incontreranno durante l’autorizzazione del Portal. La documentazione di Cloudflare afferma che diversi controlli step-up non si comporteranno in questo modo.

I team di sicurezza dovrebbero inoltre separare il rilevamento del protocollo dalla sicurezza semantica. Una richiesta può attraversare un Portal approvato, non corrispondere a nessuna regola DLP e tuttavia attivare un’azione non sicura. DLP cerca pattern di dati definiti, non valuta se l’eliminazione di un progetto corrisponda all’intento dell’utente.

L’iniezione negli strumenti presenta un problema correlato. Un server upstream può restituire contenuti che influenzano la decisione successiva di un agente. L’ispezione di rete può registrare o bloccare stringhe sensibili, ma non riconosce necessariamente istruzioni manipolative incorporate in contenuti altrimenti validi.

Vale anche il contrario. Una connessione MCP shadow non costituisce automaticamente un incidente. Uno sviluppatore potrebbe testare una fonte di dati pubblica e innocua. La connessione rimane non governata, ma il suo impatto aziendale e di sicurezza richiede contesto.

Falsi positivi e falsi negativi appartengono quindi al modello operativo. I team dovrebbero trattare le corrispondenze di hostname e URI come piste, quindi utilizzare segnali del body, attribuzione dell’utente, dati del client e revisione del server per prendere una decisione. Le regole di blocco ad alto impatto dovrebbero basarsi su più di una corrispondenza generica del percorso.

Un rollout graduale può ridurre le interruzioni. Gli amministratori possono iniziare con il logging, stabilire il traffico Portal previsto e identificare le destinazioni dirette più comuni. Possono quindi bloccare le connessioni shadow ad alta confidenza, creando al contempo un processo di approvazione per i nuovi server.

La versione più solida combina controlli di rete e degli endpoint. Gateway vede il traffico remoto che attraversa percorsi gestiti. La gestione degli endpoint può controllare quali client e configurazioni gli utenti installano. Access e le restrizioni upstream rendono più difficile l’aggiramento una volta che esiste un percorso approvato.

Cloudflare ha fornito i componenti per questa architettura. Non ha eliminato la necessità di progettarla.

Tre segnali mostreranno se il modello MCP di Cloudflare regge

Il prossimo test è se le aziende riusciranno a trasformare la visibilità su MCP in instradamento coerente, blocchi significativi e governance degli strumenti misurabile.

Il primo segnale è la quota di traffico rilevato che passa attraverso domini Portal approvati. Le ricerche iniziali in Gateway riveleranno probabilmente una combinazione di servizi noti, esperimenti e falsi positivi. Il modello acquista credibilità quando l’attività MCP diretta diminuisce dopo la disponibilità di alternative approvate.

I team di sicurezza dovrebbero misurarlo come risultato di instradamento, non solo come conteggio dei blocchi. Un numero crescente di richieste bloccate potrebbe mostrare che la policy funziona, ma può anche indicare che gli utenti continuano a tentare di aggirare il percorso approvato. Una migrazione riuscita significa che l’attività legittima continua attraverso il Portal.

Il secondo segnale è la qualità delle policy a livello di strumenti e dati. Un Portal che espone ogni capacità di ogni server approvato centralizza l’accesso senza applicare molte restrizioni. I deployment più solidi cureranno gli strumenti, utilizzeranno condizioni di identità e applicheranno profili DLP sia alle richieste sia alle risposte.

Gateway di Cloudflare può bloccare una richiesta a uno strumento quando il contenuto in uscita corrisponde a un profilo DLP standard. Può inoltre bloccare la risposta quando il server upstream restituisce dati sensibili corrispondenti. Il client MCP riceve un errore anziché il contenuto protetto.

Questi controlli diventano più preziosi quando le organizzazioni li ottimizzano per i flussi di lavoro effettivi. Credenziali, informazioni finanziarie, identificatori dei clienti e documenti proprietari comportano rischi diversi. Una policy che blocca tutto frustrerà gli utenti, mentre una che non si attiva mai offre poca protezione.

I team di sicurezza dovrebbero monitorare i metodi degli strumenti bloccati, le categorie di dati corrispondenti, i server interessati e gli esiti per gli utenti. Dovrebbero inoltre verificare se gli agenti ritentano ripetutamente richieste bloccate. Tentativi ripetuti potrebbero rivelare un comportamento inadeguato del client o un flusso di lavoro che necessita di una progettazione approvata più sicura.

Il terzo segnale è la rapidità con cui Cloudflare e l’ecosistema MCP colmano le lacune di copertura note. L’adozione di Streamable HTTP dovrebbe ridurre il numero di server upstream che non possono utilizzare l’instradamento Gateway. Migliori controlli degli endpoint potrebbero aumentare la visibilità sulle configurazioni locali e non gestite.

Anche le modifiche al protocollo saranno rilevanti. I pattern di rilevamento basati sugli attuali metodi JSON-RPC devono seguire l’evoluzione della specifica. Un header stabile o un altro segnale di trasporto standardizzato potrebbe rendere più semplice la classificazione, ma i team di sicurezza non dovrebbero presumere che ogni client adotti immediatamente nuovi campi.

Il comportamento dei concorrenti offrirà un altro indizio senza modificare il confronto centrale. I fornitori di secure web gateway ed endpoint aggiungeranno probabilmente classificazioni MCP, inventari dei server o controlli degli agenti propri. Questa pressione può migliorare i metodi di rilevamento e mettere in luce i limiti degli approcci basati esclusivamente sulla rete.

Il vantaggio di Cloudflare è l’integrazione architetturale. Portal, Access, Gateway, DLP, egress e controlli applicativi possono partecipare a un unico percorso di policy. La sua sfida è dimostrare che i clienti possono configurare questi componenti senza lasciare possibilità significative di aggiramento.

La storia del “come” di Cloudflare riguarda quindi meno un singolo rilevatore che un ciclo di feedback. Individuare il traffico MCP diretto, esaminarlo, approvare i server necessari, instradarli attraverso un Portal e bloccare il percorso non gestito. Quindi ripetere il processo man mano che gli utenti adottano nuovi strumenti.

Le organizzazioni che valutano questo modello dovrebbero iniziare con una domanda pratica: quali percorsi di rete gestiti e quali client agenti il loro team di sicurezza può effettivamente osservare oggi?

Da lì, possono inventariare i segnali MCP, confrontarli con il traffico Portal approvato e scegliere dove l’enforcement dispone di sufficiente confidenza. L’obiettivo non è etichettare ogni connessione MCP come pericolosa. È garantire che gli agenti raggiungano strumenti sensibili attraverso un percorso che l’organizzazione possa autenticare, ispezionare e sottoporre ad audit.