MCP Gateway Benchmark: latenza e sicurezza di 6 gateway
Un gateway MCP si colloca tra un agente IA e gli strumenti che chiama, e i fornitori lo posizionano come livello di sicurezza per quel traffico. Abbiamo confrontato sei gateway MCP con un backend strumentato su una singola macchina, misurando latenza aggiunta, autorizzazione per singolo strumento, protezione dei contenuti e completezza dell'audit.
Risultati del benchmark dei gateway MCP
Un prodotto compare rispetto a un controllo solo se lo include e quel controllo è stato eseguito, quindi nessuno riceve zero per una funzionalità che non vende.
Due dei sei gateway misurati eseguivano un rilevatore di injection nelle configurazioni a nostra disposizione. Cortx ha bloccato tutte le 60 istruzioni iniettate e TrueFoundry 55 su 60. Attraverso gli altri quattro, un'istruzione inserita in una risposta di uno strumento ha raggiunto il client.
ContextForge include 44 plugin.1 I tre i cui nomi contengono “inject” aggiungono un header HTTP, un'informativa sulla privacy e un'intestazione di licenza, e nessuno degli altri rileva l'injection.
La scansione delle credenziali è la dimensione meglio coperta. Cinque gateway hanno bloccato tutti e tre i formati riconoscibili tramite pattern. Cortx, Lasso e TrueFoundry oscurano il segreto individuato e restituiscono il resto della risposta. ContextForge e Docker trattengono l'intero output dello strumento, quindi il chiamante perde anche il messaggio di errore.
Tre prodotti forniscono i controlli sui contenuti disattivati, che è lo stato in cui li troverà la maggior parte dei lettori. ContextForge rileva le credenziali solo dopo che un operatore abilita i suoi plugin. Cortx analizza le risposte degli strumenti solo dopo che un amministratore dell'organizzazione attiva quella funzione.
Istruzioni iniettate nelle risposte degli strumenti
La sonda restituisce una risposta di uno strumento contenente un'istruzione rivolta al modello in due forme: un elemento all'interno di un elenco strutturato e una frase incorporata in testo gratuito. Un gateway che ispeziona l'output dello strumento dovrebbe rimuoverla o rifiutarla.
TrueFoundry blocca 27 su 30 nella forma a elenco e 28 su 30 nella forma a testo gratuito, usando il suo rilevatore di prompt injection integrato con l'impostazione predefinita enforcing. Il rifiuto indica la regola che è scattata.
Cinque tentativi su 60 hanno comunque raggiunto il client e la strategia predefinita lascia passare una richiesta quando il rilevatore stesso va in errore.
Cortx blocca 30 su 30 in entrambe le forme con il suo rilevatore di indirect injection in modalità enforcing. Al posto dell'output dello strumento, il client riceve un avviso che indica cosa ha rilevato il rilevatore. Le sue impostazioni lasciano passare una risposta anche quando un rilevatore fallisce.
Abbiamo testato entrambi i rilevatori su un'istruzione in due forme. Il risultato non copre altre istruzioni e non classifica i due prodotti.
La sonda misura se il gateway rimuove il testo. Non verifica se un modello seguirebbe l'istruzione.
Credenziali del backend nelle risposte degli strumenti
Il backend restituisce un errore contenente quattro credenziali: un token GitHub, un ID chiave di accesso AWS, un JWT e una stringa arbitraria del fornitore.
Nessuno degli scanner testati ha rilevato la stringa arbitraria del fornitore, perché nessuno aveva una regola scritta per la sua forma. ContextForge e Docker l'hanno bloccata solo perché hanno trattenuto l'intera risposta dopo aver rilevato le altre tre.
La scansione dei segreti di Docker è attiva per impostazione predefinita ed è l'unico controllo delle credenziali in questa tabella che un operatore ottiene senza configurare nulla.
Autorizzazione per singolo strumento
La sonda assegna a una credenziale un ambito tale da escludere uno strumento, quindi chiama direttamente quello strumento per nome.
Quattro dei sei la applicano e nessuno restituisce i dati trattenuti. La build open source di Docker viene eseguita senza una credenziale del chiamante, quindi può nascondere uno strumento a livello globale ma non può assegnare a due chiamanti set di strumenti diversi. La superficie plugin di Lasso comprende guardrail e tracciamento, senza alcun passaggio di autorizzazione.
Bifrost misura 840 microsecondi con una chiave con ambito e 866 con una senza ambito, una differenza inferiore alla variazione tra le ripetizioni. Limitare l'ambito di una credenziale non ha comportato alcuna penalità di latenza che abbiamo potuto rilevare.
Cortx e TrueFoundry indicano la restrizione; Cortx restituisce “Strumento non consentito per questa sessione”. Bifrost e ContextForge segnalano che lo strumento non è stato trovato. Nessuno dei due comportamenti viene valutato qui.
Completezza dell'audit
Abbiamo letto ogni superficie di audit che siamo riusciti a identificare. La maggior parte dei prodotti divide la registrazione tra un log e un database.
TrueFoundry e Cortx registrano i rifiuti di autorizzazione. La traccia di TrueFoundry per la chiamata rifiutata contiene il nome dello strumento, l'email del chiamante, gli argomenti e il testo del rifiuto. La registrazione di Cortx contiene il nome dello strumento, l'ID utente del chiamante, gli argomenti e un esito DENIED con il motivo.
Bifrost e ContextForge bloccano entrambi una chiamata non autorizzata e nessuno dei due la registra. I loro archivi presentavano lo stesso numero di righe prima e dopo il tentativo.
ContextForge non ha registrato alcuna chiamata fallita nella nostra distribuzione e la sua tabella audit_trails da 26 colonne è rimasta vuota per tutto il tempo.
Docker è l'unico gateway self-hosted che lascia una traccia di una chiamata bloccata, e la traccia risulta come un successo. La riga contiene il nome dello strumento e una durata plausibile di due millisecondi senza un campo esito, quindi un operatore che cerca eventi di sicurezza non la troverebbe.
Cortx registra gli argomenti dello strumento e la risposta completa. Bifrost, Lasso e TrueFoundry fanno lo stesso. La vista delle attività del gateway di Cortx mostra solo le ultime 50 chiamate, ma un secondo archivio conservava ancora le nostre chiamate di sei settimane prima, con i relativi argomenti.
Latenza aggiunta
Bifrost aggiunge 840 microsecondi per chiamata, Docker 1.134 e ContextForge 23.058. ContextForge aggiunge 27 volte la latenza di Bifrost.
Il dato dichiarato da Bifrost è inferiore a 100 microsecondi per richiesta, misurato a 5.000 richieste al secondo.2 Il nostro test ha inviato una richiesta alla volta e ha misurato 840 microsecondi. Non abbiamo testato a 5.000 richieste al secondo, quindi questo risultato non dimostra che l'affermazione sia errata.
Un gateway rallenta anche il traffico che non transita attraverso di esso. Mentre Docker o ContextForge era in esecuzione, le chiamate effettuate direttamente al backend risultavano circa 0.9 millisecondi più lente, tra 858 e 973 microsecondi nelle quattro attività di misurazione.
Questo effetto non si applicherebbe a un gateway sul proprio host, quindi viene riportato separatamente dai valori delle chiamate instradate sopra.
Costo della governance
Due prodotti potevano essere misurati con il controllo dei contenuti disattivato e attivato, modificando una sola impostazione tra le coppie.
I quattro rilevatori di ContextForge costano 3.198 microsecondi, un aumento del 11,5%. Le deviazioni standard tra le ripetizioni sono state di 157 microsecondi con i rilevatori disattivati e di 73 con i rilevatori attivati. Questa baseline non è confrontabile con il grafico della latenza: il framework di plugin e il numero di strumenti differivano entrambi, quindi vale solo la variazione all'interno della coppia.
I due guardrail di TrueFoundry la portano da 55.5 a 172.1 millisecondi, circa il triplo. Le sue tre ripetizioni hanno misurato 152.6, 163.4 e 200.3 millisecondi. Con i rilevatori disattivati, la deviazione standard tra le ripetizioni è stata di 1.5 millisecondi.
I due tipi di rilevatori hanno costi diversi. Il pattern matching di ContextForge ha aggiunto il 11,5%, mentre il rilevamento di injection e segreti di TrueFoundry insieme ha circa triplicato il valore ed è variato da 152.6 a 200.3 millisecondi tra le ripetizioni, quindi una singola esecuzione non avrebbe mostrato tale intervallo.
Che cos'è un piano di controllo IA?
Abbiamo testato Cortx e TrueFoundry come servizi hosted. Sono piani di controllo IA: un livello hosted che conserva policy, identità e audit trail per il traffico IA di un'organizzazione e instrada le chiamate agli strumenti attraverso se stesso, in modo che un unico insieme di regole si applichi ovunque.
Il gateway sposta il traffico. Il piano di controllo decide cosa è consentito e registra cosa è accaduto. I fornitori vendono il secondo come motivo per acquistare il primo.
Entrambi i valori sono dominati dalla distanza di rete. Cortx aggiunge 211.1 millisecondi e TrueFoundry 55.5 dalla stessa macchina, e il solo round trip è di circa 100 millisecondi verso la regione di Cortx contro 14.1 verso quella di TrueFoundry. Due attraversamenti rappresentano circa 200 dei 211 millisecondi di Cortx. Non classifichiamo mai i due prodotti l'uno rispetto all'altro.
Un piano di controllo afferma che un'unica policy si applica ovunque, ed è ciò che abbiamo testato. Cortx fornisce la scansione delle risposte per le chiamate agli strumenti MCP disattivata e solo un amministratore dell'organizzazione può attivarla. Con la scansione attiva, il rilevatore di injection in modalità enforcing e una policy che abilita due categorie integrate su Block, Cortx ha trattenuto ogni risposta contenente l'istruzione iniettata e ha mascherato i tre formati di credenziali standard, restituendo il resto del testo di errore.
Con la policy attiva e l'interruttore dell'organizzazione disattivato, ogni formato di credenziale ed entrambe le forme di istruzione hanno raggiunto il client. Cortx rileva l'injection con un rilevatore separato anziché con una categoria di policy. Il rilevatore blocca solo in modalità enforcing. In modalità monitor, segnala l'istruzione e lascia passare la risposta.
Un piano di controllo può quindi mostrare una policy attiva e tuttavia non analizzare il percorso che ti interessa. Chiedi a un fornitore quale impostazione colloca il suo motore sul percorso delle risposte degli strumenti e in quale modalità operano i suoi rilevatori. Cortx e TrueFoundry sono due dei 12 piani di controllo che abbiamo valutato per copertura delle funzionalità; questo benchmark misura cosa fanno realmente due di essi sul percorso MCP.
Aggiungi come fonte preferitaChe cos'è un gateway MCP?
Il Model Context Protocol consente a un agente IA di individuare e chiamare strumenti che risiedono al suo esterno, come un servizio di interrogazione di database o una API interna. Un gateway è un proxy attraverso cui passano tutte quelle chiamate, quindi un operatore può indirizzare molti agenti a un unico indirizzo invece di collegare ogni agente a ogni strumento.
Un gateway centralizza quattro compiti su molti agenti e strumenti. Decide quale chiamante può usare quale strumento, ispeziona l'output dello strumento prima che il modello lo legga, registra cosa è accaduto e instrada il traffico.
Cosa copre e cosa non copre il percorso
Un gateway vede le chiamate agli strumenti e le risposte degli strumenti. Non vede il ragionamento privato del modello né l'intero contesto della chat, quindi questo benchmark testa i controlli anti-injection solo sulle risposte degli strumenti.
Inoltre protegge solo il traffico che lo attraversa. Abbiamo lasciato il backend direttamente raggiungibile e non abbiamo valutato la resistenza all'elusione, perché quel risultato dipenderebbe dai controlli di rete della distribuzione esterni al percorso del gateway.
Metodologia del benchmark dei gateway MCP
Prodotti: sette selezionati, sei misurati. Bifrost v1.6.10, Docker MCP Gateway v0.43.3, IBM ContextForge v1.0.7, Lasso Security v1.2.1 (self-hosted); Cortx v1.1, console TrueFoundry Developer tier 0.167.0 (hosted). Portkey non ha prodotto alcuna misurazione. La sincronizzazione del suo workspace segnalava successo mentre il nostro log di origine registrava zero connessioni, e l'account gratuito tier che abbiamo testato non disponeva della classe di chiavi richiesta da un'integrazione a livello di organizzazione.
Date delle misurazioni: latenza degli strumenti MCP standalone 2026-08-13, sweep di policy e audit 2026-08-21, latenza hosted TrueFoundry 2026-08-17, latenza hosted Cortx 2026-08-19.
Ambiente: una macchina con 8 vCPU, gateway e backend mock co-ubicati, Caddy su TLS. I gateway hosted sono raggiunti tramite WAN, quindi i loro valori includono una latenza di rete che questa configurazione non può separare nettamente dall'elaborazione del gateway. Cortx esce da AWS us-east-1; la regione di TrueFoundry non è stata identificata in modo indipendente.
Backend: un server MCP mock, 16 strumenti, ritardi deterministici per singolo strumento, 4 dei quali sono puri echo per le misurazioni temporali. Perde 4 formati di credenziali su richiesta (token GitHub, ID chiave AWS, JWT, stringa arbitraria del fornitore), restituisce istruzioni iniettate in 2 forme (elenco strutturato, testo gratuito) e registra ogni chiamata. I tre formati di credenziali standard sono sintetici, con lunghezze e strutture che soddisfano le regole di formato usate dai veri scanner di segreti.
Client: un client MCP deterministico senza modello linguistico. Un modello nel percorso aggiungerebbe secondi di varianza a una misurazione in microsecondi senza cambiare ciò che fa il gateway.
Latenza: latenza aggiunta mediana con concorrenza 1, ovvero la chiamata instradata dal gateway meno una chiamata diretta al backend abbinata, con i due percorsi intercalati per ridurre la distorsione da deriva. Bifrost 5 ripetizioni, Docker e ContextForge 3, a 200 chiamate per attività per ripetizione. Il campionamento sequenziale è stato rifiutato: sovrastimava Docker dell'89% e Bifrost del 54%. Lasso viene eseguito su stdio anziché su un socket, quindi non ha un valore confrontabile.
Sonde di policy (n=30 ciascuna): un'istruzione iniettata su 2 forme, una fuga di credenziali su 4 formati e una chiamata a uno strumento per cui la credenziale non ha ambito. La baseline diretta al backend restituiva ogni payload, quindi uno zero attraverso un gateway indica che il gateway sta agendo, non che la sonda è fallita.
Configurazione: ogni prodotto è stato misurato con i controlli sui contenuti più rigorosi a nostra disposizione, mantenendo i parametri dei rilevatori forniti. Non abbiamo scritto alcun pattern per corrispondere al payload di test. Quando un prodotto ha una configurazione predefinita e una governata, pubblichiamo entrambe. TrueFoundry, ContextForge e Cortx fornivano ciascuno il controllo dei contenuti disattivato e sono stati rimisurati con esso attivato, e tutti e tre hanno registrato l'applicazione dei controlli sul percorso testato. Su Cortx, il suo vendor xnode ha impostato l'interruttore a livello di organizzazione e la modalità del rilevatore, che il nostro account non può modificare, e ha aggiunto formati di token standard dei fornitori, incluso quello di GitHub, alla libreria di pattern del nostro workspace.
Audit: abbiamo letto ogni superficie di audit identificata, inclusi stdout, archivi di database, log delle attività e viste di traccia hosted. Abbiamo creato checkpoint degli archivi di database prima di contare le righe.
Per i risultati a livello di modello, consulta il benchmark LLM agentico.
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk},
title = {{MCP Gateway Benchmark: latenza e sicurezza di 6 gateway}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Consultato il 5 ottobre 2026}
}Risultati e timestamp di 35 punti dati. Scarica i dati di sintesi mostrati nei grafici e nelle tabelle di questo articolo come file ZIP contenente 7 file CSV e un README.
Vuoi i dati granulari che ci stanno dietro? Passa a Premium
Registro delle modifiche
2 aggiornamentiAggiunta una sezione di risultati benchmark che confronta sei gateway MCP su latenza e sicurezza
Aggiunti IBM ContextForge, Kong AI Gateway e MintMCP Gateway alla copertura dei gateway.
Collegamenti di riferimento
Prossimo da leggere
Automazione MSP: NinjaOne, Acronis & ConnectWise
Esecuzione di codice con MCP: un nuovo approccio all'efficienza degli agenti IA
MCP Benchmark: I migliori server MCP per l'accesso al web
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.