MCP Benchmark de passerelles: latence et sécurité de 6 passerelles
Une passerelle MCP se situe entre un agent IA et les outils qu'il appelle, et les fournisseurs la positionnent comme la couche de sécurité pour ce trafic. Nous avons comparé six passerelles MCP à un backend instrumenté unique sur une seule machine, en mesurant la latence ajoutée, l'autorisation par outil, la protection du contenu et l'exhaustivité de l'audit.
MCP résultats du benchmark de passerelles
Un produit n'apparaît face à un contrôle que s'il en fournit un et que ce contrôle a été exécuté ; personne n'est donc noté zéro pour une fonctionnalité qu'il ne vend pas.
Deux des six passerelles mesurées exécutaient un détecteur d'injection dans les configurations dont nous disposions. Cortx a arrêté les 60 instructions injectées et TrueFoundry 55 sur 60. Dans les quatre autres, une instruction introduite dans une réponse d'outil a atteint le client.
ContextForge fournit 44 plugins.1 Les trois dont les noms contiennent « inject » ajoutent un en-tête HTTP, une mention de confidentialité et un en-tête de licence, et aucun des autres ne détecte l'injection.
L'analyse des identifiants est la dimension la mieux couverte. Cinq passerelles ont arrêté les trois formats détectables par motif. Cortx, Lasso et TrueFoundry masquent le secret correspondant et renvoient le reste de la réponse. ContextForge et Docker retiennent l'intégralité de la sortie de l'outil, de sorte que l'appelant perd également le message d'erreur.
Trois produits livrent leurs contrôles de contenu désactivés, ce qui est l'état dans lequel la plupart des lecteurs les trouveront. ContextForge détecte les identifiants une fois qu'un opérateur active ses plugins. Cortx analyse les réponses d'outils uniquement après qu'un administrateur d'organisation a activé cette fonction.
Instructions injectées dans les réponses d'outils
La sonde renvoie une réponse d'outil contenant une instruction adressée au modèle sous deux formes : un élément dans une liste structurée et une phrase intégrée dans du texte gratuit. Une passerelle qui inspecte la sortie de l'outil doit la supprimer ou la refuser.
TrueFoundry bloque 27 sur 30 pour la forme en liste et 28 sur 30 pour la forme en texte gratuit, en utilisant son détecteur d'injection de prompt intégré au réglage d'application par défaut. Le refus indique la règle qui s'est déclenchée.
Cinq tentatives sur 60 ont quand même atteint le client, et la stratégie par défaut laisse passer une requête lorsque le détecteur lui-même renvoie une erreur.
Cortx bloque 30 sur 30 pour les deux formes avec son détecteur d'injection indirecte en mode application. À la place de la sortie de l'outil, le client reçoit un avis indiquant ce que le détecteur a trouvé. Ses paramètres laissent également passer une réponse lorsqu'un détecteur échoue.
Nous avons testé les deux détecteurs sur une instruction sous deux formes. Le résultat ne couvre pas d'autres instructions et ne classe pas les deux produits.
La sonde mesure si la passerelle supprime le texte. Elle ne teste pas si un modèle suivrait l'instruction.
Identifiants backend dans les réponses d'outils
Le backend renvoie une erreur contenant quatre identifiants : un token GitHub, un ID de clé d'accès AWS, un JWT et une chaîne arbitraire de fournisseur.
Aucun des scanners testés n'a détecté la chaîne arbitraire du fournisseur, car aucun ne possédait de règle écrite pour sa forme. ContextForge et Docker ne l'ont bloquée que parce qu'ils ont retenu l'intégralité de la réponse après avoir détecté les trois autres.
L'analyse des secrets de Docker est activée par défaut, et c'est le seul contrôle d'identifiants de ce tableau qu'un opérateur obtient sans rien configurer.
Autorisation par outil
La sonde limite un identifiant pour exclure un outil, puis appelle directement cet outil par son nom.
Quatre des six appliquent la règle, et aucun ne renvoie les données retenues. La version open source de Docker s'exécute sans identifiant d'appelant, de sorte qu'elle peut masquer un outil globalement mais ne peut pas donner à deux appelants des ensembles d'outils différents. La surface de plugin de Lasso se limite aux garde-fous et au traçage, sans aucune étape d'autorisation.
Bifrost mesure 840 microsecondes avec une clé scopée et 866 avec une clé non scopée, un écart inférieur à la variation entre les répétitions. La limitation d'un identifiant n'a entraîné aucune pénalité de latence que nous ayons pu résoudre.
Cortx et TrueFoundry indiquent la restriction, Cortx renvoyant « Tool not permitted for this session ». Bifrost et ContextForge signalent l'outil comme introuvable. Aucun de ces comportements n'est noté ici.
Exhaustivité de l'audit
Nous avons lu chaque surface d'audit que nous avons pu identifier. La plupart des produits répartissent l'enregistrement entre un journal et une base de données.
TrueFoundry et Cortx enregistrent les refus d'autorisation. La trace de TrueFoundry pour l'appel refusé contient le nom de l'outil, l'e-mail de l'appelant, les arguments et le texte du refus. L'enregistrement de Cortx contient le nom de l'outil, l'identifiant utilisateur de l'appelant, les arguments et un résultat DENIED avec la raison.
Bifrost et ContextForge bloquent tous deux un appel non autorisé, et aucun ne l'enregistre. Leurs magasins contenaient le même nombre de lignes avant et après la tentative.
ContextForge n'a enregistré aucune invocation échouée dans notre déploiement, et sa table audit_trails à 26 colonnes est restée vide tout du long.
Docker est la seule passerelle auto-hébergée qui laisse une trace d'un appel bloqué, et cette trace se présente comme un succès. La ligne contient le nom de l'outil et une durée plausible de deux millisecondes sans champ de résultat, de sorte qu'un opérateur recherchant des événements de sécurité ne la trouverait pas.
Cortx enregistre les arguments de l'outil et la réponse complète. Bifrost, Lasso et TrueFoundry font de même. La vue d'activité de la passerelle de Cortx n'affiche que les 50 derniers appels, mais un second magasin conservait encore nos appels de six semaines plus tôt, avec leurs arguments.
Latence ajoutée
Bifrost ajoute 840 microsecondes par appel, Docker 1 134 et ContextForge 23 058. ContextForge ajoute 27 fois plus de latence que Bifrost.
Le chiffre propre de Bifrost est inférieur à 100 microsecondes par requête, mesuré à 5 000 requêtes par seconde.2 Notre test envoyait une requête à la fois et mesurait 840 microsecondes. Nous n'avons pas testé à 5 000 requêtes par seconde, ce résultat ne montre donc pas que l'affirmation est fausse.
Une passerelle ralentit également le trafic qui ne passe jamais par elle. Pendant que Docker ou ContextForge servait, les appels effectués directement vers le backend étaient environ 0.9 milliseconde plus lents, entre 858 et 973 microsecondes sur les quatre tâches de chronométrage.
Cet effet ne s'appliquerait pas à une passerelle sur son propre hôte, il est donc rapporté séparément des chiffres des appels routés ci-dessus.
Coût de la gouvernance
Deux produits ont pu être mesurés avec leur contrôle de contenu désactivé puis activé, en modifiant un paramètre entre les paires.
Les quatre détecteurs de ContextForge coûtent 3 198 microsecondes, soit une augmentation de 11,5 %. Les écarts-types entre répétitions étaient de 157 microsecondes avec eux désactivés et de 73 avec eux activés. Cette base de référence n'est pas comparable au graphique de latence : le framework de plugins et le nombre d'outils différaient tous deux, seule la variation au sein de la paire est donc valable.
Les deux garde-fous de TrueFoundry la font passer de 55.5 à 172.1 millisecondes, soit environ le triple. Ses trois répétitions ont mesuré 152.6, 163.4 et 200.3 millisecondes. Avec les détecteurs désactivés, l'écart-type entre répétitions était de 1.5 milliseconde.
Les deux types de détecteurs coûtent des montants différents. La correspondance de motifs de ContextForge a ajouté 11,5 %, tandis que la détection d'injection et de secrets de TrueFoundry a environ triplé le chiffre et a varié de 152.6 à 200.3 millisecondes entre les répétitions, de sorte qu'une exécution unique n'aurait pas montré cette plage.
Qu'est-ce qu'un plan de contrôle IA ?
Nous avons testé Cortx et TrueFoundry en tant que services hébergés. Ce sont des plans de contrôle IA : une couche hébergée qui détient la politique, l'identité et la piste d'audit pour le trafic IA d'une organisation, et fait passer les appels d'outils par elle-même afin qu'un seul ensemble de règles s'applique partout.
La passerelle déplace le trafic. Le plan de contrôle décide de ce qui est autorisé et enregistre ce qui s'est passé. Les fournisseurs vendent le second comme raison d'acheter la première.
Les deux chiffres sont dominés par la distance réseau. Cortx ajoute 211.1 millisecondes et TrueFoundry 55.5 depuis la même machine, et l'aller-retour seul représente environ 100 millisecondes vers la région de Cortx contre 14.1 vers celle de TrueFoundry. Deux traversées représentent à peu près 200 des 211 millisecondes de Cortx. Nous ne classons jamais les deux l'un contre l'autre.
Un plan de contrôle prétend qu'une seule politique s'applique partout, c'est donc ce que nous avons testé. Cortx livre l'analyse des réponses pour les appels d'outils MCP désactivée, et seul un administrateur d'organisation peut l'activer. Avec l'analyse activée, le détecteur d'injection en mode application et une politique qui active deux catégories intégrées sur Block, Cortx a retenu chaque réponse contenant l'instruction injectée et masqué les trois formats d'identifiants standard, renvoyant le reste du texte d'erreur.
Avec la politique active et le commutateur d'organisation désactivé, tous les formats d'identifiants et les deux formes d'instruction ont atteint le client. Cortx détecte l'injection avec un détecteur distinct plutôt qu'une catégorie de politique. Le détecteur ne bloque qu'en mode application. En mode surveillance, il signale l'instruction et laisse passer la réponse.
Un plan de contrôle peut donc afficher une politique active sans analyser le chemin qui vous intéresse. Demandez à un fournisseur quel paramètre place son moteur sur le chemin des réponses d'outils et dans quel mode ses détecteurs s'exécutent. Cortx et TrueFoundry sont deux des 12 plans de contrôle que nous avons évalués sur la couverture fonctionnelle ; ce benchmark mesure ce que deux d'entre eux font réellement sur le chemin MCP.
Ajouter comme source préféréeQu'est-ce qu'une passerelle MCP ?
Le Model Context Protocol permet à un agent IA de découvrir et d'appeler des outils qui résident en dehors de lui, comme un service de requête de base de données ou une API interne. Une passerelle est un proxy par lequel passent tous ces appels, de sorte qu'un opérateur peut orienter de nombreux agents vers une seule adresse au lieu de connecter chaque agent à chaque outil.
Une passerelle centralise quatre tâches sur de nombreux agents et outils. Elle décide quel appelant peut utiliser quel outil, inspecte la sortie de l'outil avant que le modèle ne la lise, enregistre ce qui s'est passé et route le trafic.
Ce que le chemin couvre et ne couvre pas
Une passerelle voit les appels d'outils et les réponses d'outils. Elle ne voit pas le raisonnement privé du modèle ni le contexte complet de la conversation, ce benchmark teste donc les contrôles d'injection uniquement sur les réponses d'outils.
Elle ne protège également que le trafic qui passe par elle. Nous avons laissé le backend directement accessible et n'avons pas noté la résistance au contournement, car ce résultat dépendrait des contrôles réseau de déploiement extérieurs au chemin de la passerelle.
MCP méthodologie du benchmark de passerelles
Produits : sept sélectionnés, six mesurés. Bifrost v1.6.10, Docker MCP Gateway v0.43.3, IBM ContextForge v1.0.7, Lasso Security v1.2.1 (auto-hébergés) ; Cortx v1.1, console TrueFoundry Developer tier 0.167.0 (hébergés). Portkey n'a produit aucune mesure. Sa synchronisation d'espace de travail a signalé un succès tandis que notre journal d'origine a enregistré zéro connexion, et le compte de niveau gratuit que nous avons testé ne possédait pas la classe de clé requise par une intégration au niveau organisation.
Dates de mesure : latence des outils MCP autonomes 2026-08-13, balayage des politiques et de l'audit 2026-08-21, latence hébergée TrueFoundry 2026-08-17, latence hébergée Cortx 2026-08-19.
Environnement : une machine à 8 vCPU, passerelle et backend factice colocalisés, Caddy sur TLS. Les passerelles hébergées sont accessibles via le WAN, de sorte que leurs chiffres incluent une latence réseau que cette configuration ne peut pas séparer proprement du traitement de la passerelle. Cortx sort d'AWS us-east-1 ; la région de TrueFoundry n'a pas été identifiée indépendamment.
Backend : un serveur MCP factice, 16 outils, délais déterministes par outil, dont 4 échos purs pour le chronométrage. Il laisse fuiter 4 formats d'identifiants sur demande (token GitHub, ID de clé AWS, JWT, chaîne arbitraire fournisseur), renvoie des instructions injectées sous 2 formes (liste structurée, texte gratuit), et journalise chaque appel. Les trois formats d'identifiants standard sont synthétiques, avec des longueurs et des structures qui satisfont les règles de format utilisées par les scanners de secrets réels.
Client : un client MCP déterministe sans modèle de langage. Un modèle dans le chemin ajouterait des secondes de variance à une mesure en microsecondes sans changer ce que fait la passerelle.
Latence : latence ajoutée médiane à concurrence 1, l'appel routé par la passerelle moins un appel direct au backend apparié, les deux chemins étant entrelacés pour réduire le biais de dérive. Bifrost 5 répétitions, Docker et ContextForge 3, à 200 appels par tâche et par répétition. L'échantillonnage séquentiel a été rejeté : il surestimait Docker de 89 % et Bifrost de 54 %. Lasso s'exécute sur stdio plutôt que sur un socket, il n'a donc pas de chiffre comparable.
Sondes de politique (n=30 chacune) : une instruction injectée sous 2 formes, une fuite d'identifiants sur 4 formats, et un appel à un outil pour lequel l'identifiant n'est pas scopé. La référence directe vers le backend a renvoyé chaque charge utile, donc un zéro à travers une passerelle indique que la passerelle a agi, et non que la sonde a échoué.
Configuration : chaque produit a été mesuré avec les contrôles de contenu les plus forts dont nous disposions, en conservant les paramètres de détecteur livrés. Nous n'avons écrit aucun motif pour correspondre à la charge utile de test. Lorsqu'un produit possède une configuration par défaut et une configuration gouvernée, nous publions les deux. TrueFoundry, ContextForge et Cortx ont chacun livré leur contrôle de contenu désactivé et ont été re-mesurés avec celui-ci activé, et tous les trois ont journalisé l'application sur le chemin testé. Sur Cortx, son fournisseur xnode a défini le commutateur au niveau organisation et le mode de détecteur, que notre compte ne peut pas modifier, et a ajouté des formats de tokens de fournisseurs standard, y compris celui de GitHub, à la bibliothèque de motifs de notre espace de travail.
Audit : nous avons lu chaque surface d'audit que nous avons identifiée, notamment stdout, les magasins de bases de données, les journaux d'activité et les vues de trace hébergées. Nous avons établi des points de vérification sur les magasins de bases de données avant de compter les lignes.
Pour les résultats au niveau du modèle, consultez le agentique LLM benchmark.
Citez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk},
title = {{MCP Benchmark de passerelles: latence et sécurité de 6 passerelles}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Consulté le 5 octobre 2026}
}Résultats et horodatages de 35 points de données. Téléchargez les données de synthèse présentées dans les graphiques et les tableaux de cet article sous forme de fichier ZIP contenant 7 fichiers CSV et un README.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Journal des modifications
2 mises à jourAjout d'une section de résultats de benchmark comparant six passerelles MCP en latence et sécurité
Ajout d'IBM ContextForge, Kong AI Gateway et MintMCP Gateway à la couverture des gateways.
Liens de référence
À lire ensuite
Automatisation MSP: NinjaOne, Acronis & ConnectWise
Exécution de code avec MCP: une nouvelle approche de l'efficacité des agents IA
MCP Benchmark: Meilleurs serveurs MCP pour l'accès Web
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.