MCP Gateway Benchmark: latenza e sicurezza di 6 gateway
Un MCP gateway si trova tra un agente IA e i tool che chiama, e i vendor lo posizionano come livello di sicurezza per quel traffico. Abbiamo confrontato sei MCP gateway con un backend strumentato su una singola macchina, misurando la latenza aggiunta, l'autorizzazione per-tool, la protezione dei contenuti e la completezza dell'audit.
Risultati del benchmark dei gateway MCP
Un prodotto compare rispetto a un controllo solo se ne offre uno e quel controllo è stato eseguito, quindi nessuno riceve zero per una funzionalità che non vende.
Uno dei sei gateway misurati include un rilevatore di injection. TrueFoundry ha bloccato 55 delle 60 istruzioni iniettate con esso. Gli altri cinque non offrono alcun rilevamento di injection o jailbreak, quindi un'istruzione inserita in una risposta di tool raggiunge il client attraverso ciascuno di essi.
ContextForge offre 44 plugin.1 I tre i cui nomi contengono “inject” aggiungono un'intestazione HTTP, un'informativa sulla privacy e un'intestazione di licenza, e nessuno degli altri rileva l'injection.
La scansione delle credenziali è la dimensione meglio presidiata. Quattro gateway hanno bloccato tutti e tre i formati rilevabili tramite pattern. Differiscono in ciò che riceve il chiamante: Lasso e TrueFoundry oscurano il segreto corrispondente e restituiscono il resto della risposta, mentre ContextForge e Docker trattengono l'intero output del tool, quindi il chiamante perde anche il messaggio di errore.
Tre prodotti offrono i propri controlli sui contenuti disattivati, che è lo stato in cui la maggior parte dei lettori li troverà. ContextForge rileva le credenziali una volta che un operatore abilita i suoi plugin. Cortx non ha bloccato nulla nemmeno con una policy attiva.
Istruzioni iniettate nelle risposte dei tool
La sonda restituisce una risposta di tool che contiene un'istruzione rivolta al model in due forme: un elemento all'interno di un elenco strutturato e una frase incorporata in un testo gratuito. Un gateway che ispeziona l'output del tool dovrebbe rimuoverla o rifiutarla.
TrueFoundry blocca 27 dei 30 nella forma a elenco e 28 dei 30 nella forma a testo gratuito, usando il suo rilevatore di prompt-injection integrato con l'impostazione predefinita di enforcement. Il rifiuto indica il nome della regola che è scattata.
Cinque dei 60 tentativi hanno comunque raggiunto il client e la strategia predefinita lascia passare una richiesta quando il rilevatore stesso genera un errore.
La sonda misura se il gateway rimuove il testo. Non verifica se un model seguirebbe l'istruzione.
Credenziali del backend nelle risposte dei tool
Il backend restituisce un errore contenente quattro credenziali: un token GitHub, un ID chiave di accesso AWS, un JWT e una stringa vendor arbitraria.
Nessuno degli scanner testati ha rilevato la stringa vendor arbitraria, perché nessuno disponeva di una regola scritta per la sua forma. ContextForge risulta bloccarla solo perché l'intera risposta è stata trattenuta grazie alle 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-tool
La sonda limita l'ambito di una credenziale per escludere un tool, quindi chiama direttamente quel tool per nome.
Quattro dei sei applicano il controllo e nessuno restituisce i dati trattenuti. La build open-source di Docker gira senza una credenziale del chiamante, quindi può nascondere un tool a livello globale ma non può dare a due chiamanti insiemi di tool diversi. La superficie dei plugin di Lasso è guardrail e tracing, senza alcuna fase di autorizzazione.
Bifrost misura 840 microsecondi con una chiave con scope e 866 con una senza scope, un divario inferiore alla variazione tra le ripetizioni. Limitare l'ambito di una credenziale non ha comportato alcuna penalità di latenza che siamo riusciti a misurare.
Cortx e TrueFoundry indicano la restrizione, Cortx restituendo “Tool non consentito per questa sessione”. Bifrost e ContextForge segnalano che il tool non è stato trovato. Non valutiamo qui nessuno dei due comportamenti.
Completezza dell'audit
Abbiamo letto ogni superficie di audit che siamo riusciti a identificare. La maggior parte dei prodotti divide il record tra un log e un database.
TrueFoundry è l'unico partecipante che registra un rifiuto di autorizzazione. La sua traccia per la chiamata rifiutata contiene il nome del tool, l'email del chiamante, gli argomenti e il testo del rifiuto.
Bifrost, ContextForge e Cortx bloccano tutti una chiamata non autorizzata e nessuno registra che sia avvenuta. I loro archivi hanno mantenuto lo stesso numero di righe prima e dopo il tentativo.
ContextForge non ha registrato alcuna invocazione 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 del tool e una durata plausibile di due millisecondi senza alcun campo di esito, quindi un operatore che cerca eventi di sicurezza non la troverebbe.
Cortx registra gli argomenti del tool e la risposta completa, cosa che fanno anche solo Lasso e TrueFoundry, ma conserva 50 righe qualunque sia il limite richiesto. Quella finestra ha coperto 11 secondi della nostra esecuzione da 2.400 chiamate.
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 inferiore a 100 microsecondi dichiarato da Bifrost è un'affermazione di throughput ad alta concorrenza.2 Con concorrenza 1 aggiunge circa dieci volte tanto, e l'affermazione dovrebbe essere verificata come numero di throughput piuttosto che considerata confutata qui.
Un gateway rallenta anche il traffico che non passa mai attraverso di esso. Mentre Docker o ContextForge era in esecuzione, le chiamate effettuate direttamente al backend sono risultate più lente di circa 0.9 millisecondi, tra 858 e 973 microsecondi nei quattro task di temporizzazione.
Questo effetto non si applicherebbe a un gateway su un host dedicato, quindi viene riportato separatamente dalle cifre relative alle chiamate instradate sopra.
Costo della governance
Due prodotti hanno potuto essere misurati con il controllo dei contenuti spento e acceso, cambiando un'impostazione tra le coppie.
I quattro rilevatori di ContextForge costano 3.198 microsecondi, con un aumento del 11.5%. Le deviazioni standard tra le ripetizioni sono state di 157 microsecondi con i rilevatori spenti e di 73 con essi accesi. Questa baseline non è confrontabile con il grafico della latenza: sia il framework dei plugin sia il numero di tool differivano, quindi vale solo la variazione all'interno della coppia.
I due guardrail di TrueFoundry lo 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 spenti, la deviazione standard tra le ripetizioni è stata di 1.5 millisecondi.
I due tipi di rilevatore costano importi diversi. Il pattern matching di ContextForge ha aggiunto il 11.5%, mentre il rilevamento di injection di TrueFoundry ha pressoché triplicato il valore e variava da 152.6 a 200.3 millisecondi tra le ripetizioni, quindi una singola esecuzione non avrebbe mostrato quell'intervallo.
Che cos'è un piano di controllo IA?
Cortx e TrueFoundry non sono gateway da installare. Sono piani di controllo IA: un livello ospitato che detiene la policy, l'identità e la traccia di audit per il traffico IA di un'organizzazione e instrada le chiamate ai tool attraverso di sé, in modo che un unico insieme di regole si applichi ovunque.
Il gateway è la parte che sposta il traffico. Il piano di controllo è la parte che decide cosa è consentito e annota cosa è successo. I vendor vendono la seconda come motivo per acquistare la prima.
Entrambe le cifre sono dominate dalla distanza di rete. Cortx aggiunge 211.1 millisecondi e TrueFoundry 55.5 dallo stesso host, e il solo viaggio di andata e ritorno è di circa 100 millisecondi verso la regione di Cortx contro 14.1 verso quella di TrueFoundry. Due attraversamenti spiegano circa 200 dei 211 millisecondi di Cortx. Non mettiamo mai a confronto i due tra loro.
La promessa di un piano di controllo è che una policy si applichi ovunque, quindi è ciò che abbiamo testato. Cortx fornisce la scansione delle risposte disattivata. Abbiamo creato una policy, attivato due delle sue categorie integrate su Block, l'abbiamo approvata e l'endpoint di stato del prodotto ha confermato che la nostra era la policy attiva. Ogni formato di credenziale ed entrambe le istruzioni iniettate hanno comunque raggiunto il client e attivare la policy non è costato alcuna latenza misurabile.
Il suo log di enforcement mostra il motivo: ogni evento registrato si trova nella fase che gira attorno a una chiamata al model e il nostro percorso non include alcun model. Nessuna delle sue categorie integrate copre il rilevamento di prompt injection o jailbreak, la stessa lacuna del set di plugin di ContextForge.
Un piano di controllo può quindi essere configurato correttamente, segnalarsi come attivo e comunque non trovarsi sul percorso che interessa. Una risposta di tool MCP è una superficie più recente di un prompt per un model, e un motore di policy copre le superfici per cui è stato costruito. Chiedete a un vendor quale fase del loro motore vede una risposta di tool e ottenete questa risposta prima dell'audit piuttosto che dopo.
Aggiungi come fonte preferitaChe cos'è un gateway MCP?
Il Model Context Protocol consente a un agente IA di scoprire e chiamare tool che risiedono al di fuori di esso, come un servizio di interrogazione di database o un'API interna. Un gateway è un proxy attraverso cui passano tutte quelle chiamate, così un operatore può indirizzare molti agenti a un unico indirizzo invece di collegare ciascun agente a ciascun tool.
Un gateway centralizza quattro compiti tra molti agenti e tool. Decide quale chiamante può usare quale tool, ispeziona l'output del tool prima che il model lo legga, registra ciò che è successo e instrada il traffico.
Cosa copre e cosa non copre il percorso
Un gateway vede le chiamate ai tool e le risposte dei tool. Non vede il ragionamento privato del model né l'intero contesto della chat, quindi questo benchmark testa i controlli di injection solo sulle risposte dei tool.
Protegge inoltre solo il traffico che lo attraversa. Abbiamo lasciato il backend raggiungibile direttamente e non abbiamo valutato la resistenza al bypass, 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 del tier Developer di TrueFoundry 0.167.0 (hosted). Portkey non ha prodotto alcuna misurazione. La sincronizzazione del suo workspace ha segnalato successo mentre il nostro log di origine registrava zero connessioni e l'account del tier gratuito che abbiamo testato non disponeva della classe di chiavi richiesta da un'integrazione a livello di organizzazione.
Date delle misurazioni: latenza dei tool MCP standalone 2026-08-13, verifica di policy e audit 2026-08-21, latenza hosted TrueFoundry 2026-08-17, latenza hosted Cortx 2026-08-19.
Ambiente: un'unica macchina con 8 vCPU, gateway e backend mock co-locati, Caddy su TLS. I gateway hosted sono accessibili tramite WAN, quindi le loro cifre includono la latenza di rete che questo setup non può separare chiaramente dall'elaborazione del gateway. Cortx esce da AWS us-east-1; la regione di TrueFoundry non è stata identificata in modo indipendente.
Backend: un singolo server MCP mock, 16 tool, ritardi deterministici per ciascun tool, 4 dei quali sono puri echo per la temporizzazione. Fa trapelare 4 formati di credenziali su richiesta (token GitHub, ID chiave AWS, JWT, stringa vendor arbitraria), 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 model di linguaggio. Un model 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, pari alla chiamata instradata dal gateway meno una chiamata diretta al backend abbinata, con i due percorsi interlacciati per ridurre la distorsione da deriva. Bifrost 5 ripetizioni, Docker e ContextForge 3, con 200 chiamate per task per ripetizione. Il campionamento sequenziale è stato rifiutato: sopravvalutava Docker del 89% e Bifrost del 54%. Lasso gira su stdio anziché su un socket, quindi non ha una cifra confrontabile.
Sonde di policy (n=30 ciascuna): un'istruzione iniettata in 2 forme, una fuga di credenziali in 4 formati e una chiamata a un tool per cui la credenziale non ha ambito. La baseline diretta al backend ha restituito ogni payload, quindi uno zero attraverso un gateway indica che il gateway ha agito, non che la sonda ha fallito.
Configurazione: ogni prodotto è stato misurato con i controlli sui contenuti più forti a noi disponibili, mantenendo i parametri dei rilevatori forniti. Non è stato scritto alcun pattern per corrispondere al payload di test. Quando un prodotto ha una configurazione predefinita e una governata, sono state pubblicate entrambe. TrueFoundry, ContextForge e Cortx hanno tutti fornito il controllo dei contenuti spento e sono stati rimisurati con esso acceso. TrueFoundry e ContextForge hanno registrato l'enforcement sul percorso testato; Cortx ha confermato che la policy era attiva ma non ha registrato alcun evento di enforcement per queste chiamate.
Audit: è stata letta ogni superficie di audit identificata, inclusi stdout, archivi database, log delle attività e viste di traccia hosted. Gli archivi database sono stati sottoposti a checkpoint prima del conteggio delle righe.
Per risultati a livello di model, consulta il benchmark di 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 = aug,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Consultato il 24 Agosto 2026}
}Registro delle modifiche
2 aggiornamenti- 2026
Aggiunta 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
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.