Agentgateway unifica el tráfico de LLM, MCP y A2A en un único proxy open source

Iván, arquitecto de sistemas de RED Security, ha publicado en Habr un análisis de Agentgateway, un gateway open source por el que se pueden canalizar a la vez tres tipos de tráfico de IA: solicitudes a modelos de lenguaje, llamadas a herramientas mediante MCP y comunicación entre agentes por A2A. La idea le resultará familiar a cualquiera que haya visto cómo la IA se extiende por una empresa: en lugar de una decena de conexiones directas con claves en el código y sin un registro común, aparece un único punto de control.

Advertencia: en el feed solo está disponible el anuncio del artículo; el texto completo se encuentra en Habr. Por eso, lo que sigue es contexto basado en la documentación pública del proyecto, no un resumen de los detalles del análisis del autor.

Qué problema resuelve el gateway

Mientras los equipos conectan los LLM de uno en uno, todo parece inofensivo. Un servicio llama a OpenAI, otro a Anthropic, un tercero a Gemini. Después aparecen agentes que invocan API internas a través de servidores MCP y se llaman entre sí. Cada conexión tiene sus propias claves, sus propios límites y sus propios logs. O no tiene ninguno.

Es habitual que el responsable de seguridad pregunte qué datos salieron al exterior la semana pasada y que no haya forma de responderle. El gateway resuelve el problema desde la arquitectura: todo el tráfico pasa por el proxy y las reglas se definen en un solo lugar. Para una empresa con certificaciones y requisitos de los reguladores, esto no es una comodidad: es una condición para llevar la IA a producción.

Qué se sabe del proyecto

Agentgateway fue creado por la empresa Solo.io y después el proyecto se cedió a la Linux Foundation. Esto importa a quienes temen depender de un único proveedor: el código es abierto y la gobernanza va más allá de una sola compañía. El núcleo está escrito en Rust, lo que suele traducirse en un consumo de memoria reducido y una latencia predecible en la ruta crítica.

Principales funciones según la documentación:

• tres tipos de tráfico en un mismo proxy: solicitudes a LLM, MCP y A2A;
• enrutamiento hacia varios proveedores de modelos, incluidas plataformas en la nube y API compatibles con OpenAI;
• autorización y políticas de acceso, también basadas en JWT y expresiones CEL;
• límites y control del gasto vinculados a los tokens, y no solo al número de solicitudes;
• filtros de protección para prompts y respuestas;
• métricas y trazabilidad mediante OpenTelemetry;
• integración con la Kubernetes Gateway API e interfaz integrada para depuración.

Dónde está el problema

El gateway se convierte en un único punto de fallo y en un único punto de ataque. Hay que dotarlo de redundancia, actualizarlo y monitorizarlo con el mismo rigor que un balanceador externo. Segundo aspecto: los protocolos MCP y A2A son jóvenes, sus especificaciones aún cambian y la compatibilidad habrá que comprobarla con servidores y agentes reales, no en un entorno de demostración.

También existe un riesgo organizativo. Si los equipos siguen accediendo a los modelos sin pasar por el gateway, con claves personales, la centralización quedará solo sobre el papel. Técnicamente se corrige con políticas de red y entregando las claves únicamente al gateway, pero esa es ya una decisión de nivel de infraestructura, no de un solo proyecto.

Por dónde empezar la implantación

Un camino práctico sería este. Primero, levante el gateway en un entorno de pruebas y haga pasar por él un servicio no crítico que use LLM. Compare la latencia y compruebe que los logs contienen lo que necesita la auditoría. Después, traslade las claves de los proveedores desde las aplicaciones a la configuración del gateway y cierre la salida directa a internet de los servicios que acceden a los modelos.

El siguiente paso: defina las políticas para las herramientas MCP. Empiece con una denegación por defecto y permita solo las herramientas que el agente realmente necesite. Por último, configure límites por tokens para cada equipo: así el gasto en IA dejará de ser una sorpresa a fin de mes. Para los detalles de configuración y los ejemplos, conviene consultar el artículo original del autor en Habr y la documentación del proyecto.