MCP Benchmark des 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é sur une seule machine, en mesurant la latence ajoutée, l'autorisation par outil, la protection du contenu et l'exhaustivité de l'audit.
Résultats du benchmark des passerelles MCP
Un produit n'apparaît face à un contrôle que s'il en intègre un et que ce contrôle a été exécuté, de sorte que personne n'obtient zéro pour une fonctionnalité qu'il ne vend pas.
L'une des six passerelles mesurées embarque un détecteur d'injection. TrueFoundry a arrêté 55 des 60 instructions injectées grâce à lui. Les cinq autres n'embarquent aucune détection d'injection ou de jailbreak, de sorte qu'une instruction insérée dans une réponse d'outil atteint le client à travers chacune d'elles.
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.
La détection des identifiants est la dimension la mieux couverte. Quatre passerelles ont bloqué les trois formats détectables par correspondance de motif. Elles diffèrent par ce que reçoit l'appelant : Lasso et TrueFoundry caviardent le secret correspondant et renvoient le reste de la réponse, tandis que 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 intercepte les identifiants une fois qu'un opérateur active ses plugins. Cortx n'a rien bloqué même avec une politique active.
Instructions injectées dans les réponses des 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 devrait 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 nomme la règle qui s'est déclenchée.
Cinq des 60 tentatives ont tout de 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.
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 des 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 comportait de règle écrite pour sa forme. ContextForge semble la bloquer uniquement parce que toute la réponse a été retenue en raison des 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 d'eux ne renvoie les données retenues. La version open source de Docker s'exécute sans identifiant d'appelant, elle peut donc masquer un outil globalement mais ne peut pas attribuer des jeux d'outils différents à deux appelants. La surface de plugins de Lasso se limite aux garde-fous et au tracing, 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 « Outil non autorisé pour cette session ». Bifrost et ContextForge signalent que l'outil est 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 est le seul participant qui enregistre un refus d'autorisation. Sa trace pour l'appel refusé contient le nom de l'outil, l'e-mail de l'appelant, les arguments et le texte du refus.
Bifrost, ContextForge et Cortx bloquent tous un appel non autorisé et aucun n'enregistre qu'il a eu lieu. Leurs stockages présentaient 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 la trace apparaît 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, ce que seuls Lasso et TrueFoundry font aussi, mais conserve 50 lignes quelle que soit la limite demandée. Cette fenêtre couvrait 11 secondes de notre exécution de 2 400 appels.
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 de moins de 100 microsecondes revendiqué par Bifrost est une affirmation de débit à forte concurrence.2 À une concurrence de 1, il ajoute environ dix fois ce chiffre, et cette affirmation doit être testée comme un chiffre de débit plutôt que considérée comme réfutée ici.
Une passerelle ralentit aussi le trafic qui ne passe jamais par elle. Pendant que Docker ou ContextForge servait, les appels effectués directement vers le backend s'exécutaient environ 0.9 millisecondes plus lentement, entre 858 et 973 microsecondes sur les quatre tâches de mesure.
Cet effet ne s'appliquerait pas à une passerelle sur son propre hôte, il est donc rapporté séparément des chiffres d'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é et activé, en changeant un seul réglage entre les deux états.
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, de sorte que seul le changement au sein de la paire est valable.
Les deux garde-fous de TrueFoundry le 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 millisecondes.
Les deux types de détecteurs ont des coûts différents. La correspondance de motifs de ContextForge a ajouté 11.5 %, tandis que la détection d'injection de TrueFoundry a environ triplé le chiffre et a varié de 152.6 à 200.3 millisecondes selon les répétitions, de sorte qu'une seule exécution n'aurait pas montré cette plage.
Qu'est-ce qu'un plan de contrôle de l'IA ?
Cortx et TrueFoundry ne sont pas des passerelles que l'on installe. Ce sont des plans de contrôle de l'IA : une couche hébergée qui détient la politique, l'identité et la piste d'audit pour le trafic d'IA d'une organisation, et qui route les appels d'outils par elle-même afin qu'un seul ensemble de règles s'applique partout.
La passerelle est la partie qui déplace le trafic. Le plan de contrôle est la partie qui décide de ce qui est autorisé et consigne ce qui s'est passé. Les fournisseurs vendent le second comme la raison d'acheter le premier.
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 est d'environ 100 millisecondes vers la région de Cortx contre 14.1 vers celle de TrueFoundry. Deux traversées représentent environ 200 des 211 millisecondes de Cortx. Nous ne classons jamais les deux l'un contre l'autre.
La promesse d'un plan de contrôle est qu'une seule politique s'applique partout, c'est donc ce que nous avons testé. Cortx livre l'analyse des réponses désactivée. Nous avons créé une politique, activé deux de ses catégories intégrées sur Block, l'avons approuvée, et le point de terminaison d'état propre du produit a confirmé que notre politique était la politique active. Chaque format d'identifiant et les deux instructions injectées ont tout de même atteint le client, et l'activation de la politique n'a entraîné aucune latence mesurable.
Son journal d'application montre pourquoi : chaque événement qu'il enregistre se situe à l'étape qui s'exécute autour d'un appel de modèle, et notre chemin ne contient aucun modèle. Aucune de ses catégories intégrées ne couvre non plus l'injection de prompt ou la détection de jailbreak, le même manque que l'ensemble de plugins de ContextForge.
Un plan de contrôle peut donc être correctement configuré, se déclarer actif, et pourtant ne pas se trouver sur le chemin qui vous importe. Une réponse d'outil MCP est une surface plus récente qu'un prompt de modèle, et un moteur de politique couvre les surfaces pour lesquelles il a été construit. Demandez à un fournisseur quelle étape de son moteur voit une réponse d'outil, et obtenez cette réponse avant l'audit plutôt qu'après.
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 à l'extérieur de lui, comme un service d'interrogation 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 câbler 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, c'est pourquoi ce benchmark teste 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 joignable et n'avons pas noté la résistance au contournement, car ce résultat dépendrait de contrôles réseau de déploiement en dehors du chemin de la passerelle.
Méthodologie du benchmark des passerelles MCP
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é). Portkey n'a produit aucune mesure. Sa synchronisation d'espace de travail a signalé un succès alors que notre journal d'origine n'a enregistré aucune connexion, et le compte de niveau gratuit que nous avons testé ne disposait pas de la classe de clé requise par une intégration au niveau de l'organisation.
Dates de mesure : latence des outils MCP autonomes 2026-08-13, analyse de politique et d'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 simulé co-localisé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 simulé, 16 outils, des délais déterministes par outil, dont 4 sont de purs échos pour la mesure. Il divulgue 4 formats d'identifiants sur demande (token GitHub, ID de clé AWS, JWT, chaîne arbitraire de 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 vrais scanners de secrets.
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 à une concurrence de 1, l'appel routé par la passerelle moins un appel direct correspondant vers le backend, 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 via stdio plutôt qu'une socket, il n'a donc pas de chiffre comparable.
Sondes de politique (n=30 chacune) : une instruction injectée sur 2 formes, une fuite d'identifiant sur 4 formats et un appel à un outil pour lequel l'identifiant n'est pas scopé. La ligne de base directe vers le backend a renvoyé chaque payload, donc un zéro via une passerelle indique que la passerelle a agi, et non une sonde défaillante.
Configuration : chaque produit a été mesuré avec les contrôles de contenu les plus stricts à notre disposition, en conservant les paramètres de détecteur livrés. Aucun motif n'a été écrit pour correspondre au payload de test. Lorsqu'un produit possède une configuration par défaut et une configuration gouvernée, les deux sont publiées. TrueFoundry, ContextForge et Cortx ont chacun livré leur contrôle de contenu désactivé et ont été re-mesurés avec celui-ci activé. TrueFoundry et ContextForge ont journalisé l'application sur le chemin testé ; Cortx a confirmé que la politique était active mais n'a journalisé aucun événement d'application pour ces appels.
Audit : chaque surface d'audit que nous avons identifiée a été lue, y compris stdout, les stockages en base de données, les journaux d'activité et les vues de trace hébergées. Les stockages en base de données ont été vérifiés avant le comptage des lignes.
Pour les résultats au niveau du modèle, voir le benchmark LLM agentique.
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 des passerelles: latence et sécurité de 6 passerelles}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Consulté le 24 Août 2026}
}Journal des modifications
2 mises à jour- 2026
Ajout 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
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.