Gateway MCP para agentes de IA: cómo Eon pasó de 2 días a 2 minutos en el onboarding de sus ingenieros
Gateway MCP para agentes de IA: Eon redujo de 2 días a 2 minutos el acceso de sus ingenieros a herramientas en tres nubes. Así lo hizo y qué puedes copiar.
Un ingeniero nuevo de Eon tardaba unos dos días en configurar credenciales y servidores locales antes de investigar su primer incidente. Hoy tarda unos dos minutos. El cambio salió de un gateway MCP para agentes de IA que centraliza el acceso a decenas de herramientas operativas en AWS, GCP y Azure. Lo construyeron sobre Amazon Bedrock AgentCore, y el mismo punto de entrada sirve a desarrolladores humanos y a un agente SRE autónomo.
Eon, fundada por exingenieros de AWS, ofrece una plataforma de datos que descubre y clasifica recursos en las tres nubes, hace backup deduplicado continuo (hasta 50% menos de costo de almacenamiento, según mediciones internas de la propia compañía) y detecta ransomware. Su equipo de ingeniería investiga incidentes de producción que obligan a cruzar fuentes: un pod de Kubernetes caído exige revisar logs del contenedor, métricas de Grafana, el pull request de GitHub que desplegó el cambio y el estado de salud del proveedor cloud, todo en la misma sesión. Cada herramienta nueva sumaba otra integración que configurar, proteger y rotar. Cada desarrollador, además, mantenía varios servidores MCP (Model Context Protocol) corriendo en su máquina, difíciles de estandarizar y actualizar.
La arquitectura: un solo gateway MCP con acceso de mínimo privilegio
Eon evaluó dos caminos. El primero era un proxy inverso propio con autenticación a medida. Resolvía la consolidación de credenciales, pero solo soportaba MCP remoto y obligaba a construir y mantener la traducción de protocolos, la gestión de sesiones y la lógica de autorización. El segundo era AgentCore Gateway, un servicio gestionado con federación de identidad, políticas de autorización basadas en Cedar y hosting en Runtime que convierte servidores MCP locales en endpoints HTTP remotos. Eligieron el segundo porque la separación de identidades, la conectividad entre cuentas y la aplicación de políticas llegaban como capacidades gestionadas, no como código propio.
La solución tiene cinco capas:
El resultado: el desarrollador abre su IDE, configura una URL, se autentica con el SSO y recibe cientos de herramientas en una sola respuesta tools/list. Sin setup local y sin tokens por herramienta.
Qué puedes aplicar en tu empresa
El caso muestra que el cuello de botella de los agentes de IA suele ser el acceso y no el modelo. Algunas lecciones prácticas:
1. Centraliza antes de que escale. Eon decidió actuar cuando el crecimiento del equipo y de los MCP hizo insostenible gestionar credenciales una por una. Si tus ingenieros ya instalan servidores locales, ya llegaste a ese punto.
2. Trata a los agentes como identidades propias. Humanos y agentes entran por la misma puerta, pero con permisos distintos. Solo identidades de agente específicas reciben permisos de escritura, y de alcance limitado.
3. Define permisos por herramienta, no por sistema. Autorizar "GitHub" es demasiado grueso. Permitir "comentar PRs" y nada más es lo que reduce el riesgo.
4. Compra lo que no te diferencia. Traducción de protocolos, sesiones y autorización son infraestructura, no ventaja competitiva. Eon descartó construirlas.
5. Mide el onboarding. De dos días a dos minutos es una métrica que cualquier director de ingeniería entiende y que justifica la inversión.
El enfoque encaja con la tendencia de gobernar agentes por políticas y no por revisión manual, como en la automatización de la seguridad de agentes de IA empresariales con AWS y Cisco. También es el tipo de base que necesitan casos como el de Miro, que redujo la resolución de bugs de días a horas con agentes sobre Amazon Bedrock, donde el agente solo es útil si llega a todas las fuentes de contexto. Y si tu reto es diagnosticar incidentes a escala, vale la pena ver cómo Netflix usa un grafo de conocimiento para automatizar diagnósticos.
Cuándo conviene un gateway MCP para agentes de IA
El momento adecuado llega cuando coinciden tres señales: más de un puñado de herramientas conectadas a agentes, equipos que repiten configuraciones locales y operaciones en varias cuentas o nubes. Antes de eso, un proxy simple puede bastar. Después, cada herramienta nueva cuesta más que la anterior.
Hay que leer el caso con cautela. Los resultados provienen de Eon y de AWS, que además vende la plataforma, y la cifra de ahorro de almacenamiento es una medición interna. Aun así, el patrón es sólido y replicable: una puerta única, identidad federada y políticas explícitas.
La pregunta para tu organización es concreta: ¿cuántos días pierde hoy un ingeniero nuevo antes de poder usar las herramientas que tus agentes ya consumen? Si la respuesta incomoda, un gateway MCP para agentes de IA puede ser tu siguiente proyecto de infraestructura.
Preguntas frecuentes
¿Qué es un gateway MCP para agentes de IA?
Es un punto de entrada único que agrega decenas de servidores MCP y expone sus herramientas a desarrolladores y agentes mediante una sola URL autenticada. Centraliza credenciales, identidad y permisos, de modo que nadie necesita ejecutar servidores locales ni gestionar tokens por herramienta, como hizo Eon con Amazon Bedrock AgentCore.
¿Qué resultados obtuvo Eon con Amazon Bedrock AgentCore?
Los ingenieros nuevos acceden a todas sus herramientas de investigación en unos dos minutos, frente a los dos días que tardaban antes en configurar credenciales y servidores MCP locales. Además, un único gateway da acceso unificado a herramientas en AWS, GCP y Azure tanto a humanos como a un agente SRE autónomo.
¿Cómo controla Eon lo que pueden hacer los agentes de IA?
Mediante políticas Cedar en modo ENFORCE dentro del gateway. Cada llamada a una herramienta se evalúa antes de llegar al destino. La lectura se limita a grupos aprobados, las herramientas de producción son de solo lectura y la escritura se reserva a identidades de agente específicas para acciones de bajo impacto, como comentar un PR.