MCP Gateway Benchmark: latencia y seguridad de 6 gateways
Un gateway MCP se sitúa entre un agente de IA y las herramientas a las que llama, y los proveedores lo posicionan como la capa de seguridad para ese tráfico. Evaluamos seis gateways MCP contra un backend instrumentado en una sola máquina, midiendo la latencia añadida, la autorización por herramienta, la protección del contenido y la completitud de la auditoría.
MCP resultados del benchmark de gateways
Un producto aparece frente a un control solo si lo incluye y ese control se ejecutó, de modo que nadie recibe una puntuación de cero por una función que no vende.
Dos de los seis gateways evaluados ejecutaban un detector de inyección en las configuraciones a las que tuvimos acceso. Cortx detuvo todas las 60 instrucciones inyectadas y TrueFoundry detuvo 55 de 60. A través de los otros cuatro, una instrucción implantada en una respuesta de herramienta llegó al cliente.
ContextForge incluye 44 plugins.1 Los tres cuyos nombres contienen «inject» añaden una cabecera HTTP, un aviso de privacidad y una cabecera de licencia, y ninguno del resto detecta la inyección.
El escaneo de credenciales es la dimensión mejor atendida. Cinco gateways detuvieron los tres formatos que se pueden detectar por patrones. Cortx, Lasso y TrueFoundry redactan el secreto detectado y devuelven el resto de la respuesta. ContextForge y Docker retienen toda la salida de la herramienta, por lo que la persona que llama también pierde el mensaje de error.
Tres productos entregan sus controles de contenido desactivados, que es el estado en el que la mayoría de los lectores los encontrarán. ContextForge detecta credenciales solo cuando un operador habilita sus plugins. Cortx analiza las respuestas de las herramientas solo después de que un administrador de la organización lo active.
Instrucciones inyectadas en las respuestas de las herramientas
La sonda devuelve una respuesta de herramienta que contiene una instrucción dirigida al modelo en dos formas: un elemento dentro de una lista estructurada y una frase incrustada en gratis texto. Un gateway que inspecciona la salida de la herramienta debería eliminarla o rechazarla.
TrueFoundry bloquea 27 de 30 en la forma de lista y 28 de 30 en la forma de gratis texto, utilizando su detector integrado de inyección de prompt en el ajuste de aplicación predeterminado. El rechazo indica el nombre de la regla que se activó.
Cinco de 60 intentos aún llegaron al cliente, y la estrategia predeterminada deja pasar una solicitud cuando el propio detector falla.
Cortx bloquea 30 de 30 en ambas formas con su detector de inyección indirecta en modo de aplicación. En lugar de la salida de la herramienta, el cliente recibe un aviso que indica qué detectó el detector. Sus ajustes también permiten que una respuesta pase cuando un detector falla.
Probamos ambos detectores con una instrucción en dos formas. El resultado no cubre otras instrucciones y no clasifica los dos productos.
La sonda mide si el gateway elimina el texto. No comprueba si un modelo seguiría la instrucción.
Credenciales del backend en las respuestas de las herramientas
El backend devuelve un error que contiene cuatro credenciales: un token de GitHub, un ID de clave de acceso de AWS, un JWT y una cadena arbitraria de proveedor.
Ninguno de los escáneres probados detectó la cadena arbitraria del proveedor, porque ninguno tenía una regla escrita para su forma. ContextForge y Docker la detuvieron solo porque retuvieron toda la respuesta después de detectar las otras tres.
El escaneo de secretos de Docker está activado de forma predeterminada y es el único control de credenciales de esta tabla que un operador obtiene sin configurar nada.
Autorización por herramienta
La sonda limita una credencial para excluir una herramienta y luego llama a esa herramienta directamente por su nombre.
Cuatro de los seis la aplican y ninguno devuelve los datos retenidos. La versión de código abierto de Docker se ejecuta sin una credencial de llamador, por lo que puede ocultar una herramienta de forma global pero no puede ofrecer a dos llamadores conjuntos de herramientas diferentes. La superficie de plugins de Lasso se limita a guardarraíles y trazabilidad, sin ningún paso de autorización.
Bifrost mide 840 microsegundos con una clave con ámbito y 866 con una sin ámbito, una diferencia menor que la variación entre repeticiones. Limitar el ámbito de una credencial no supuso ninguna penalización de latencia que pudiéramos resolver.
Cortx y TrueFoundry nombran la restricción; Cortx devuelve «Herramienta no permitida para esta sesión». Bifrost y ContextForge informan de que la herramienta no se encontró. Aquí no se puntúa ninguno de estos comportamientos.
Completitud de la auditoría
Leímos todas las superficies de auditoría que pudimos identificar. La mayoría de los productos dividen el registro entre un log y una base de datos.
TrueFoundry y Cortx registran las denegaciones de autorización. La traza de TrueFoundry para la llamada rechazada incluye el nombre de la herramienta, el correo electrónico del llamador, los argumentos y el texto de rechazo. El registro de Cortx incluye el nombre de la herramienta, el ID de usuario del llamador, los argumentos y un resultado DENIED con el motivo.
Bifrost y ContextForge bloquean una llamada no autorizada y ninguno la registra. Sus almacenes mantuvieron el mismo número de filas antes y después del intento.
ContextForge no registró ninguna invocación fallida en nuestro despliegue, y su tabla audit_trails de 26 columnas permaneció vacía todo el tiempo.
Docker es el único gateway autohospedado que deja algún rastro de una llamada bloqueada, y el rastro se lee como un éxito. La línea incluye el nombre de la herramienta y una duración plausible de dos milisegundos sin ningún campo de resultado, por lo que un operador que busque eventos de seguridad no lo encontraría.
Cortx registra los argumentos de la herramienta y la respuesta completa. Bifrost, Lasso y TrueFoundry hacen lo mismo. La vista de actividad del gateway de Cortx solo muestra las últimas 50 llamadas, pero un segundo almacén aún conservaba nuestras llamadas de seis semanas antes, con sus argumentos.
Latencia añadida
Bifrost añade 840 microsegundos por llamada, Docker 1.134 y ContextForge 23.058. ContextForge añade 27 veces más latencia que Bifrost.
La propia cifra de Bifrost es inferior a 100 microsegundos por solicitud, medida a 5.000 solicitudes por segundo.2 Nuestra prueba envió una solicitud cada vez y midió 840 microsegundos. No probamos a 5.000 solicitudes por segundo, por lo que este resultado no demuestra que la afirmación sea incorrecta.
Un gateway también ralentiza el tráfico que nunca pasa por él. Mientras Docker o ContextForge estaba sirviendo, las llamadas directas al backend tardaban unos 0.9 milisegundos más, entre 858 y 973 microsegundos en las cuatro tareas de medición.
Ese efecto no se aplicaría a un gateway en su propio host, por lo que se informa por separado de las cifras de llamadas enrutadas anteriores.
Coste de la gobernanza
Dos productos pudieron medirse con su control de contenido desactivado y activado, cambiando un ajuste entre los pares.
Los cuatro detectores de ContextForge costaron 3.198 microsegundos, un aumento del 11,5 %. Las desviaciones estándar entre repeticiones fueron de 157 microsegundos con ellos desactivados y de 73 con ellos activados. Esta línea base no es comparable con la tabla de latencia: el framework de plugins y el número de herramientas diferían, por lo que solo se mantiene el cambio dentro del par.
Las dos guardarraíles de TrueFoundry lo llevan de 55.5 a 172.1 milisegundos, aproximadamente el triple. Sus tres repeticiones midieron 152.6, 163.4 y 200.3 milisegundos. Con los detectores desactivados, la desviación estándar entre repeticiones fue de 1.5 milisegundos.
Los dos tipos de detectores tuvieron costes diferentes. La coincidencia de patrones de ContextForge añadió un 11,5 %, mientras que la detección de inyección y secretos de TrueFoundry en conjunto casi triplicó la cifra y varió de 152.6 a 200.3 milisegundos entre repeticiones, por lo que una sola ejecución no habría mostrado ese rango.
¿Qué es un plano de control de IA?
Probamos Cortx y TrueFoundry como servicios alojados. Son planos de control de IA: una capa alojada que mantiene la política, la identidad y la pista de auditoría del tráfico de IA de una organización, y enruta las llamadas a herramientas a través de sí misma para que un único conjunto de reglas se aplique en todas partes.
El gateway mueve el tráfico. El plano de control decide lo que está permitido y registra lo que ocurrió. Los proveedores venden lo segundo como la razón para comprar lo primero.
Ambas cifras están dominadas por la distancia de red. Cortx añade 211.1 milisegundos y TrueFoundry 55.5 desde la misma caja, y solo el viaje de ida y vuelta es de unos 100 milisegundos hacia la región de Cortx, frente a 14.1 hacia la de TrueFoundry. Dos cruces representan aproximadamente 200 de los 211 milisegundos de Cortx. Nunca comparamos los dos entre sí.
Un plano de control afirma que una política se aplica en todas partes, así que eso es lo que probamos. Cortx entrega el escaneo de respuestas para llamadas a herramientas MCP desactivado, y solo un administrador de la organización puede activarlo. Con el escaneo activado, el detector de inyección en modo de aplicación y una política que habilita dos categorías integradas en Block, Cortx retuvo toda respuesta que llevara la instrucción inyectada y enmascaró los tres formatos de credenciales estándar, devolviendo el resto del texto de error.
Con la política activa y el interruptor de la organización desactivado, todos los formatos de credenciales y ambas formas de instrucción llegaron al cliente. Cortx detecta la inyección con un detector separado en lugar de con una categoría de política. El detector solo bloquea en su modo de aplicación. En modo monitor, marca la instrucción y deja pasar la respuesta.
Por tanto, un plano de control puede mostrar una política activa y aun así no analizar la ruta que le importa. Pregunte a un proveedor qué ajuste pone su motor en la ruta de respuesta de las herramientas y en qué modo se ejecutan sus detectores. Cortx y TrueFoundry son dos de los 12 planos de control que puntuamos en cobertura de funciones; este benchmark mide lo que dos de ellos hacen realmente en la ruta MCP.
Añadir como fuente preferida¿Qué es un MCP gateway?
El Model Context Protocol permite a un agente de IA descubrir y llamar a herramientas que residen fuera de él, como un servicio de consulta de base de datos o una API interna. Un gateway es un proxy por el que pasan todas esas llamadas, de modo que un operador puede dirigir muchos agentes a una sola dirección en lugar de conectar cada agente con cada herramienta.
Un gateway centraliza cuatro tareas en muchos agentes y herramientas. Decide qué llamador puede usar qué herramienta, inspecciona la salida de la herramienta antes de que el modelo la lea, registra lo ocurrido y enruta el tráfico.
Lo que la ruta cubre y lo que no cubre
Un gateway ve las llamadas a herramientas y las respuestas de las herramientas. No ve el razonamiento privado del modelo ni el contexto completo del chat, por lo que este benchmark prueba los controles de inyección solo en las respuestas de las herramientas.
Además, solo protege el tráfico que pasa por él. Dejamos el backend directamente accesible y no puntuamos la resistencia a la elusión porque ese resultado dependería de controles de red de despliegue ajenos a la ruta del gateway.
MCP metodología del benchmark de gateways
Productos: siete seleccionados, seis medidos. Bifrost v1.6.10, Docker MCP Gateway v0.43.3, IBM ContextForge v1.0.7, Lasso Security v1.2.1 (autohospedados); Cortx v1.1, consola del nivel Developer de TrueFoundry 0.167.0 (alojados). Portkey no produjo ninguna medición. Su sincronización de espacio de trabajo informó de éxito mientras nuestro registro de origen registró cero conexiones, y la cuenta de nivel gratis que probamos carecía de la clase de clave que requiere una integración de nivel de organización.
Fechas de medición: latencia de herramientas MCP independientes 2026-08-13, barrido de políticas y auditoría 2026-08-21, latencia alojada de TrueFoundry 2026-08-17, latencia alojada de Cortx 2026-08-19.
Entorno: una caja de 8 vCPU, gateway y backend simulado coubicados, Caddy sobre TLS. Los gateways alojados se acceden a través de la WAN, por lo que sus cifras incluyen la latencia de red que esta configuración no puede separar limpiamente del procesamiento del gateway. Cortx egresa de AWS us-east-1; la región de TrueFoundry no se identificó de forma independiente.
Backend: un servidor MCP simulado, 16 herramientas, retrasos deterministas por herramienta, 4 de ellas ecos puros para la medición de tiempos. Fuga 4 formatos de credenciales a petición (token de GitHub, ID de clave de AWS, JWT, cadena arbitraria de proveedor), devuelve instrucciones inyectadas en 2 formas (lista estructurada, gratis texto) y registra cada llamada. Los tres formatos de credenciales estándar son sintéticos, con longitudes y estructuras que cumplen las reglas de formato que utilizan los escáneres de secretos reales.
Cliente: un cliente MCP determinista sin modelo de lenguaje. Un modelo en la ruta añadiría segundos de varianza a una medición de microsegundos sin cambiar lo que hace el gateway.
Latencia: mediana de la latencia añadida con concurrencia 1, la llamada enrutada por el gateway menos una llamada directa al backend emparejada, con las dos rutas intercaladas para reducir el sesgo de deriva. Bifrost 5 repeticiones, Docker y ContextForge 3, a 200 llamadas por tarea y repetición. Se rechazó el muestreo secuencial: sobrestimaba a Docker en un 89 % y a Bifrost en un 54 %. Lasso se ejecuta sobre stdio en lugar de sobre un socket, por lo que no tiene una cifra comparable.
Sondas de políticas (n=30 cada una): una instrucción inyectada en 2 formas, una fuga de credenciales en 4 formatos y una llamada a una herramienta para la que la credencial no tiene ámbito. La línea base directa al backend devolvió cada carga útil, de modo que un cero a través de un gateway indica que el gateway actuó, no que la sonda falló.
Configuración: cada producto se midió con los controles de contenido más estrictos disponibles para nosotros, conservando los parámetros de detección de fábrica. No escribimos ningún patrón para coincidir con la carga útil de prueba. Cuando un producto tiene una configuración predeterminada y una gobernada, publicamos ambas. TrueFoundry, ContextForge y Cortx entregaron su control de contenido desactivado y se volvieron a medir con él activado, y los tres registraron la aplicación en la ruta probada. En Cortx, su proveedor xnode estableció el interruptor de nivel de organización y el modo del detector, que nuestra cuenta no puede cambiar, y añadió formatos de token de proveedor estándar, incluido el de GitHub, a la biblioteca de patrones de nuestro espacio de trabajo.
Auditoría: leímos todas las superficies de auditoría que identificamos, incluidas stdout, almacenes de bases de datos, registros de actividad y vistas de trazas alojadas. Hicimos un punto de control en los almacenes de bases de datos antes de contar filas.
Para obtener resultados a nivel de modelo, consulte el benchmark agéntico de LLM.
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk},
title = {{MCP Gateway Benchmark: latencia y seguridad de 6 gateways}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Recuperado el 5 de octubre de 2026}
}Resultados y marcas de tiempo de 35 puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 7 archivos CSV y un README.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Registro de cambios
2 actualizacionesSe añadió una sección de resultados de benchmark comparando seis gateways MCP en latencia y seguridad
Se añadieron IBM ContextForge, Kong AI Gateway y MintMCP Gateway a la cobertura de gateways.
Enlaces de referencia
Siguiente para leer
Automatización MSP: NinjaOne, Acronis y ConnectWise
Ejecución de código con MCP: un nuevo enfoque para la eficiencia de los agentes de IA
MCP Benchmark: Los mejores MCP servidores para acceso web
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.