Los mejores gateways, runtimes y registros de MCP para agentes de AI en ingeniería y DevOps (2026)

TL;DR: Registros vs. Gateways vs. Runtimes

• MCP Registry: Un catálogo para descubrir y gobernar herramientas. Úsalo para aplicar una lista de herramientas aprobadas en tu cadena de suministro de software.
• MCP Gateway: Una capa de enrutamiento que conecta modelos con herramientas. Ideal para desarrollo rápido con datos no sensibles, normalmente con una cuenta de servicio compartida.
• MCP Runtime: Una plataforma de ejecución segura que hospeda herramientas y ejecuta acciones en nombre de usuarios autenticados. Úsala en aplicaciones empresariales que requieren autorización por usuario (OAuth/OBO), credenciales en bóveda y registros de auditoría estructurados.
• El riesgo clave: Usar un gateway sin permisos por usuario expone código sensible a ataques de inyección de prompts y a auditorías de cumplimiento fallidas.
• Los despliegues seguros requieren: Secretos en bóveda fuera de la ventana de contexto del LLM y registros de auditoría compatibles con OpenTelemetry que vinculen cada acción a un usuario específico.
• El veredicto: Elige runtimes como Arcade.dev para agentes multiusuario seguros que actúan en sistemas de producción; usa gateways para integraciones simples y de bajo riesgo.

Los líderes de ingeniería empresarial necesitan conectar modelos como Claude y ChatGPT con herramientas clave como GitHub, GitLab y Jira. Hacerlo de forma segura exige servidores personalizados o darle a los modelos acceso amplio a código propietario.

El ecosistema del Model Context Protocol creció rápido, pero la industria sigue confundiendo descubrimiento de herramientas, enrutamiento de solicitudes y ejecución segura en runtime.

Sin un estándar arquitectónico claro, los equipos de plataforma despliegan conexiones frágiles e inseguras que exponen bases de código propietarias a ataques de inyección.

Esta guía establece una taxonomía 2026 para el ecosistema, separa el descubrimiento de la ejecución y explica por qué las cargas de trabajo agénticas en producción requieren infraestructura a nivel Runtime. Tratar un gateway básico como un runtime seguro es el camino más común hacia auditorías de seguridad y cumplimiento fallidas.

Por qué los servidores MCP caseros fallan en producción

La mayoría de los equipos de ingeniería comienzan su camino agéntico con las implementaciones de referencia de Anthropic o SDKs de Python de código abierto. Estas herramientas funcionan bien para prototipar flujos en una laptop local. Pero al llevarlas a un entorno de producción multiusuario, te topas con una pared enorme.

La producción expone fracturas arquitectónicas de inmediato: riesgos graves de filtración de tokens, arquitecturas complejas de limitación de tasa entre aplicaciones y cero trazabilidad de auditoría empresarial.

Por ejemplo, GitHub aplica límites estrictos basados en puntos para su API GraphQL. Los agentes de AI atrapados en ciclos de reintento agotan rápidamente esas cuotas, rompiendo los flujos de trabajo.

Pero el punto de quiebre más crítico es la autorización. Al desplegar un servidor personalizado, debes decidir cómo el agente se autentica contra las herramientas del backend.

Darle al agente una identidad genérica de cuenta de servicio es el enfoque estándar de los gateways. Este método pasa por alto los permisos nativos del usuario. Si un agente se ve comprometido mediante inyección indirecta de prompts, una vulnerabilidad crítica detallada en el OWASP Top 10 for Large Language Model Applications, la identidad compartida crea un radio de explosión amplio. La inyección de prompt se propaga por los repositorios de código fuente con acceso administrativo sin restricciones.

¿La alternativa? Intentar heredar dinámicamente el acceso completo del usuario por solicitud requiere flujos de autorización con estado, lógica de refresco y bóveda de credenciales. Un proxy sin estado evalúa cada solicitud de forma aislada: no puede rastrear que una solicitud es el paso 3 de un flujo de 6 pasos, actuando en nombre de un usuario que autorizó un alcance específico hace minutos. Esa conciencia de sesión es lo que hace aplicable la autorización por usuario y por herramienta, y las capas sin estado no pueden imponerla sin una gestión personalizada de estado significativa.

Taxonomía MCP (2026): Registros, Gateways y Runtimes

Para evaluar la infraestructura con efectividad, necesitas entender los límites funcionales del ecosistema.

Taxonomía de infraestructura MCP: Registros vs. Gateways vs. Runtimes (2026)

Categoría 1: Registros de MCP para descubrimiento

Los registros son catálogos diseñados para resolver el descubrimiento de herramientas. No hospedan, autorizan ni ejecutan llamadas. Esta categoría se divide en dos tipos:

• Registros públicos: Plataformas que funcionan como catálogos públicos de búsqueda resuelven el descubrimiento inicial de herramientas, pero no ofrecen mecanismos para gestionar llamadas de forma segura.
• Registros empresariales: Plataformas que actúan como listas de permitidos en la cadena de suministro ofrecen catálogos internos curados, asegurando que los agentes usen solo servidores aprobados por la organización y bloqueando endpoints públicos maliciosos. Algunos registros empresariales agregan control de acceso por roles y registros de auditoría, aunque estas capacidades varían según el proveedor.

Al evaluar registros públicos, prioriza la amplitud del catálogo y la precisión de los metadatos. Para registros empresariales, enfócate en el análisis de seguridad, la aplicación de políticas y la integración con las herramientas existentes de cadena de suministro de software.

Categoría 2: Gateways de MCP para enrutamiento

Proveedores tradicionales de gateways de API como Kong y MuleSoft están adaptando soporte para MCP sobre arquitecturas diseñadas para tráfico HTTP sin estado. Tienden un puente en la brecha de protocolo traduciendo MCP a HTTP y aplicando políticas con construcciones de la era HTTP: claves de API, límites de tasa y ACLs de endpoints. Esta capa de traducción introduce latencia, pierde el contexto de sesión y no puede aplicar autorización por usuario ni por herramienta. Añadir MCP a un gateway de API no es un giro estratégico. Es un parche.

Los gateways de MCP y plataformas de integración diseñados específicamente para esto, como Composio, Merge y AWS AgentCore, son un nivel superior. Ofrecen integraciones de herramientas preconfiguradas y enrutamiento centralizado diseñado para flujos de trabajo de agentes. Pero todavía carecen de la intersección de permisos a nivel de runtime necesaria para una ejecución real por usuario, dejando sin resolver los problemas de seguridad más difíciles.

Al evaluar estas plataformas, enfócate en tres áreas:

• Cumplimiento de especificación y confiabilidad: Asegúrate de que las implementaciones sean servidores MCP totalmente conformes con la especificación, no simples wrappers de API con una interfaz MCP. Muchos gateways tempranos caen en esta trampa y producen herramientas que alucinan parámetros bajo cargas de trabajo reales y concurrentes. La especificación oficial del Model Context Protocol exige una adhesión estricta a las estructuras de mensajes, incluyendo negociación de capacidades, handshakes de inicialización y gestión del ciclo de vida, aspectos que los wrappers simples no logran mantener. Los wrappers delgados que pasan respuestas de API sin modificar pueden generar 100 veces más tokens que las herramientas a nivel de intención para consultas idénticas, desbordando ventanas de contexto y degradando el rendimiento del agente en flujos de trabajo de múltiples pasos.
• Soporte de infraestructura privada: Evalúa si el gateway puede conectarse a entornos de nube privada o despliegues on-prem. El soporte para herramientas de desarrollo autohospedadas suele ser limitado o requiere configuraciones de red complejas para evitar exponer redes internas a internet.
• Autorización y políticas: La mayoría de los gateways dependen de una sola clave o cuenta de servicio. Dejan la autorización por usuario como tarea para el comprador, lo que crea una brecha de seguridad enorme en entornos multiinquilino.

Categoría 3: Runtimes de MCP para ejecución segura

Los runtimes representan el nivel más alto de la taxonomía. Son plataformas de ejecución completas que combinan ejecución hospedada de herramientas, implementaciones de servidores conformes con la especificación, autorización justo a tiempo por usuario (las credenciales se adquieren solo en el momento en que una acción las requiere, con alcance específico para la herramienta y el usuario, y nunca se exponen al LLM ni al cliente MCP), credenciales en bóveda, controles de políticas y gobernanza completa en un único entorno administrado.

Los runtimes mitigan específicamente la amenaza de envenenamiento de herramientas. Al aislar las credenciales y aplicar permisos a nivel de usuario solo después de que el modelo de lenguaje genera una solicitud, los runtimes garantizan que un agente comprometido no pueda acceder a propiedad intelectual más allá de los privilegios nativos del usuario autenticado.

El modelo de autorización aplica una intersección estricta de permisos: Agent Permissions ∩ User Permissions = Effective Action Scope. El agente solo puede ejecutar una acción si tanto la política de roles del agente como los permisos nativos de SaaS del usuario humano lo permiten explícitamente. Cualquier otra combinación se rechaza.

Por ejemplo, un agente de AI empresarial asiste al departamento de Recursos Humanos. Un empleado que usa este agente tiene privilegios administrativos en Workday, incluido acceso a datos de nómina global. Pero el agente de RR. HH. está limitado estrictamente a tareas de reclutamiento. Cuando se le pide acceder a datos de nómina, el runtime evalúa la intersección en el momento de la llamada y rechaza la solicitud. El usuario tiene la autoridad, pero el alcance restringido del agente bloquea la acción. Esto aplica el principio de mínimo privilegio en la capa del agente, bloqueando tanto la exfiltración de datos como el acceso no autorizado.

Flujo de autorización: MCP Gateway vs Runtime, identidad compartida vs OBO por usuario

Cómo evaluar los Runtimes de MCP

• OAuth por usuario y RBAC: Un runtime verdadero evalúa la intersección de los permisos del agente y los permisos del usuario que realiza la llamada para cada acción individual a nivel de función, no solo a nivel de herramienta. Esto significa habilitar process_claim y get_claim_status mientras bloquea deny_claim para un usuario específico, a través de un agente específico, en runtime. Gestiona la renovación, el desajuste y la rotación de tokens conforme a las especificaciones modernas de OAuth de la IETF, manteniendo estas funciones aisladas de la ventana de contexto del modelo de lenguaje.
• Soporte de infraestructura privada: Los runtimes deben conectarse de forma segura a servidores de control de código fuente autohospedados y plataformas internas de desarrollo mediante tunelización segura o peering, sin exponerlos a la web abierta.
• Auditoría y políticas: La plataforma debe generar logs compatibles con OpenTelemetry que registren cada acción, vinculada explícitamente a un usuario y servicio específicos. También debe soportar hooks de política pre-llamada y post-llamada para validar e interceptar solicitudes riesgosas en tiempo real.
• Confiabilidad del runtime: La plataforma debe ofrecer un contexto de ejecución definido por el desarrollador para reintentos inteligentes, ejecución paralela en tareas de varios pasos y failover automático para manejar límites de tasa y errores de red transitorios.

Los mejores gateways, runtimes y registros MCP (top 8)

El ecosistema cuenta con ocho plataformas destacadas dentro de la taxonomía definida. Esta matriz de características mapea cada plataforma con los criterios clave de evaluación para despliegues DevOps empresariales, para que los equipos identifiquen rápidamente el mejor ajuste arquitectónico.

Plataforma	Categoría	Auth por usuario	Soporte de infra privada	Confiabilidad de herramientas	Registro de auditoría	Mejor caso de uso
Arcade	Runtime	Sí (OBO)	Sí (VPC/Túnel seguro)	Sí (Reintentos, failover, ejecución paralela)	Sí (OTel)	Equipos en producción que necesitan agentes multiusuario seguros en cualquier sistema.
Composio	Gateway	Parcial (OAuth por usuario; sin intersección de permisos agente/usuario)	Sí (Self-hosted)	Limitada (Sin selección de campos; errores requieren múltiples reintentos)	Limitado (Web UI)	Prototipado e integración de conexiones en proyectos.
Merge MCP	Gateway	Parcial (Auth por identidad; alcance limitado a la categoría de integración)	Limitado	Limitada (Reintentos a nivel API)	Sí (Logs de API)	API unificada para integraciones B2B SaaS (más fuerte en HRIS y reclutamiento según G2)
AWS AgentCore	Gateway	Parcial (OAuth saliente; OBO requiere configuración personalizada)	Sí (solo AWS)	Parcial (Requiere orquestación personalizada)	Sí (vía CloudWatch, requiere trabajo adicional)	Equipos completamente comprometidos con el ecosistema AWS Bedrock.
WorkOS	Auth Sidecar	Sí (SSO/SCIM)	N/A	N/A	Sí (API)	Capa de identidad adicional para gateways de enrutamiento personalizados.
JFrog MCP	Registro	N/A	Sí (Artifactory)	N/A	Sí (Estándar)	Lista de herramientas internas empresariales aprobadas para la cadena de suministro.
Smithery	Registro	N/A	No	No	No (Estadísticas de uso)	Descubrimiento público de herramientas open-source creadas por la comunidad.
Anthropic DIY	Código DIY	No (Constrúyelo tú mismo)	Sí (Build personalizado)	No (Constrúyelo tú mismo)	No (Constrúyelo tú mismo)	Implementaciones de referencia open-source y proyectos personales.

Arcade.dev (runtime)

Descripción general: Arcade.dev es un runtime de ejecución diseñado específicamente para el Model Context Protocol. A diferencia de las capas de enrutamiento sin estado, Arcade funciona como un runtime completo que unifica la autorización de agentes, un amplio catálogo de herramientas optimizadas para agentes y la gestión del ciclo de vida en un único plano de control. El runtime habla MCP de forma nativa mediante transporte Streamable HTTP, sin traducción de protocolo ni pérdida de contexto.

Ideal para: Equipos en producción que necesitan agentes multiusuario seguros capaces de actuar en cualquier sistema, desde código fuente y CI/CD hasta herramientas de productividad y aplicaciones de negocio.

Puntos fuertes:

Arcade se distingue por ofrecer más de 8,000 herramientas optimizadas para agentes junto con autorización nativa justo a tiempo para múltiples usuarios. Son herramientas de nivel de intención, no simples wrappers de API. Absorben la ambigüedad de la solicitud de un agente y la convierten en una transacción segura y predecible. Cuando un usuario dice “haz que el párrafo de introducción de mi Google Doc suene más amigable”, las herramientas de Arcade lo traducen al ID de segmento correcto, el índice de caracteres y el texto de reemplazo. El agente nunca razona sobre el esquema de la API subyacente. Esto evita los bucles de alucinación de parámetros que rompen a los agentes conectados directamente a endpoints REST.

Cada solicitud MCP en Arcade lleva dos capas de identidad: una clave a nivel de proyecto (qué aplicación hace la solicitud) y una identidad a nivel de usuario (en nombre de quién se ejecuta la acción). Arcade evalúa la intersección de permisos del agente y el usuario de forma dinámica en runtime para prevenir escalada de privilegios. Se conecta con sistemas de identidad empresarial existentes como Okta, Entra y SailPoint, adquiriendo tokens con alcance en runtime y aplicando las políticas existentes de la empresa en lugar de duplicarlas.

Arcade genera, de forma estructurada, Registros de auditoría compatibles con OpenTelemetry, que brindan la observabilidad necesaria para cumplir con los requisitos de cumplimiento empresarial y rastrear acciones hasta sesiones individuales de usuario. La certificación SOC 2 Tipo 2 de Arcade valida estos controles mediante una auditoría independiente. El filtrado de visibilidad garantiza que los agentes solo vean las herramientas que el usuario actual tiene permiso de invocar. El control de versiones permite a los ingenieros de plataforma actualizar esquemas de herramientas y rotar parámetros de conexión sin interrumpir los agentes en ejecución.

Arcade también incluye su propio MCP Gateway, pero no es una capa de enrutamiento de Categoría 2. Es una capa de composición a nivel de runtime que opera dentro del perímetro de seguridad del runtime, heredando todas sus capacidades de autorización, bóveda de credenciales y auditoría. Federa herramientas de múltiples fuentes en colecciones con alcance por equipo e identidad. Una empresa puede crear Gateways delimitados por equipo o perímetro de seguridad: Ingeniería accede a GitHub, Linear y herramientas de despliegue; Ventas accede a Salesforce, Gong y herramientas de correo. Cada uno es una URL única usable en cualquier cliente MCP (Cursor, Claude Desktop, VS Code, ChatGPT o aplicaciones personalizadas). Cada Gateway puede incluir instrucciones de LLM, skills y contexto para ayudar al agente a usar las herramientas con eficacia. Los equipos también pueden incorporar sus servidores MCP existentes al runtime para obtener autorización, reintentos y registros de auditoría sin reescribir lo que ya funciona.

El compromiso: Arcade está diseñado específicamente para despliegues multiusuario en producción y gestiona la complejidad de infraestructura de forma nativa. Para proyectos personales de un solo usuario o scripts locales, un runtime completo agrega una carga innecesaria.

Composio (gateway)

Descripción general: Composio es una plataforma de integración que ofrece una amplia biblioteca de conectores prediseñados entre modelos de lenguaje y aplicaciones de destino.

Ideal para: Desarrolladores que prototipan agentes o integran servicios de terceros en proyectos donde la velocidad importa más que la seguridad y la gobernanza.

Principales fortalezas: El valor central de Composio es su biblioteca de conectores. Reduce el código repetitivo necesario para conectar un agente a distintos endpoints, abstrayendo la complejidad inicial de integración para que los desarrolladores se concentren en el diseño de prompts.

El compromiso: El valor principal de Composio está en su biblioteca de integración, no en su arquitectura de enrutamiento. La amplitud de conectores prediseñados es su punto fuerte. Pero su comportamiento de registro predeterminado puede exponer payloads sensibles de solicitud y respuesta, generando un riesgo de cumplimiento para equipos que manejan datos personales protegidos. En benchmarks publicados, el enfoque de passthrough directo a la API de Composio produjo 100 veces más tokens de respuesta que el tooling orientado a intención para consultas idénticas de CRM, consumiendo el 373% de una ventana de contexto de 200K donde Arcade consumió el 3.7%. A escala, esta sobrecarga de tokens se traduce en menor precisión del agente, desbordamiento de la ventana de contexto en flujos de trabajo de múltiples pasos y diferencias de costo significativas. Los datos completos del benchmark son open source en github.com/ArcadeAI/attio-mcp-benchmark. Además, Composio carece del control de acceso basado en roles a nivel de herramienta y las interfaces de gobernanza dedicadas que los runtimes de ejecución reales ofrecen de forma nativa.

Merge MCP (gateway)

Descripción general: Merge lleva su trayectoria como proveedor unificado de integraciones al espacio agéntico, ofreciendo un gateway que mapea sus modelos de datos normalizados existentes en endpoints de servidor compatibles con el protocolo.

Ideal para: Aplicaciones donde el reto principal es la fragmentación de datos entre categorías de SaaS B2B como HRIS, reclutamiento y ticketing. Los modelos de datos unificados de Merge ofrecen una interfaz limpia y normalizada entre distintos proveedores en estas categorías. Si tus agentes necesitan actuar sobre estos sistemas con autorización por usuario y registros de auditoría, necesitas una capa de Runtime que Merge no proporciona.

Principales fortalezas: Merge destaca en el manejo de interfaces unificadas para sistemas de RR.HH., ticketing y contabilidad. Si tu agente necesita sincronizar datos entre veinte sistemas distintos de seguimiento de candidatos al mismo tiempo, Merge ofrece una interfaz limpia y estandarizada que previene la alucinación de parámetros.

El compromiso: Merge no está construido de forma nativa para flujos de trabajo de DevOps o ingeniería central. Carece de integración profunda con herramientas especializadas de CI/CD, lo que lo hace menos adecuado para agentes diseñados para manipular código fuente, gestionar infraestructura en la nube o resolver pull requests complejos dentro de VPCs aisladas.

AWS AgentCore (gateway)

Descripción general: La entrada nativa de Amazon al ecosistema es una plataforma de infraestructura de agentes administrada con una capa de enrutamiento integrada que permite a los desarrolladores convertir servicios existentes y funciones serverless en endpoints conformes con la especificación, de forma segura dentro de su nube.

Ideal para: Equipos de ingeniería ya profundamente integrados y comprometidos con AWS Bedrock y el ecosistema más amplio de Amazon Web Services.

Principales fortalezas: AgentCore ofrece una integración nativa excelente con AWS CloudWatch para métricas detalladas de rendimiento y usa IAM para la autorización saliente hacia servicios nativos de AWS. AgentCore gestiona la autenticación entrante básica mediante Amazon Cognito y ofrece escalado nativo de infraestructura.

El compromiso: AWS AgentCore implica un bloqueo extremo al ecosistema. Además, opera estrictamente como gateway. Soporta flujos de autorización básicos, pero construir un runtime multiusuario cohesivo con gobernanza granular requiere integrar Cognito, IAM, CloudWatch y otros servicios, cada uno administrado, configurado y monitoreado por separado. La carga operativa crece a medida que aumenta la complejidad del agente.

WorkOS (auth sidecar)

Descripción general: WorkOS no es en sí una plataforma de Model Context Protocol. Es un sidecar de identidad y autenticación empresarial que los equipos usan para tapar los huecos de seguridad en los gateways de enrutamiento básico.

Ideal para: Organizaciones que construyen infraestructura propia y necesitan implementar single sign-on empresarial y sincronización de directorios rápidamente.

Puntos fuertes: WorkOS ofrece una infraestructura sólida para la gestión de identidades, con soporte completo de SCIM y aprovisionamiento automatizado de usuarios. Permite a los desarrolladores delegar la complejidad del ciclo de vida de usuarios, el manejo de sesiones y la emisión de tokens.

La contrapartida: Como WorkOS es una capa de autenticación y no una plataforma de ejecución, los equipos deben conectarlo manualmente a sus gateways existentes. Esa integración añade costo, latencia y complejidad arquitectónica. Los desarrolladores tienen que enlazar a mano los tokens del proveedor de identidad con su lógica de ejecución de herramientas para lograr aislamiento real por usuario.

JFrog MCP (registro)

Descripción general: Dejando de lado el enrutamiento y la ejecución, el JFrog MCP Registry es un catálogo dedicado de descubrimiento y gobernanza empresarial. JFrog trata las herramientas de agentes como artefactos de software estándar y analizables.

Ideal para: Equipos de seguridad empresarial e ingeniería de plataforma que necesitan mantener una lista estrictamente aprobada de herramientas para desarrolladores internos y cargas de trabajo de agentes.

Puntos fuertes: JFrog funciona como una lista de permitidos crítica en la cadena de suministro. Al ofrecer controles de acceso estrictos basados en roles y registros de auditoría detallados en el perímetro, permite a las empresas crear un catálogo interno muy curado. Este enfoque bloquea endpoints públicos maliciosos o no verificados antes de que entren a la red corporativa.

La contrapartida: JFrog es estrictamente una capa de descubrimiento y políticas. No ofrece entorno de ejecución ni capa de enrutamiento en vivo. Después de descubrir y aprobar una herramienta en el registro, los equipos necesitan un gateway o runtime dedicado para invocarla y ejecutarla de forma segura contra datos reales.

Smithery (registro)

Descripción general: Smithery es actualmente el motor de descubrimiento público de referencia del ecosistema, y funciona como el marketplace abierto principal para encontrar y distribuir servidores creados por la comunidad.

Ideal para: Desarrolladores independientes, investigadores y aficionados que quieren encontrar, experimentar y probar servidores comunitarios en sus máquinas locales.

Puntos fuertes: Smithery da amplia visibilidad sobre lo más nuevo del ecosistema. Si se lanza una API nueva o de nicho, un conector comunitario probablemente aparece en Smithery en cuestión de días. Es ideal para prototipar rápido y con poca fricción.

La contrapartida: Smithery está diseñado solo para descubrimiento y ejecución local básica. Le faltan los mecanismos de gobernanza empresarial, los controles de acceso robustos y los procesos estrictos de vetting de seguridad que exigen los equipos corporativos. No resuelve desafíos de ejecución, enrutamiento ni infraestructura segura, por lo que conectarlo directo a flujos de producción que manejan datos sensibles no es seguro.

Servidores oficiales de Anthropic y Python SDK DIY (DIY)

Descripción general: Para los equipos que prefieren construir desde cero, Anthropic ofrece implementaciones de referencia open-source y SDKs para plataformas como GitHub y Slack, con el fin de demostrar las capacidades centrales.

Ideal para: Arquitecturas muy especializadas y profundamente personalizadas donde las plataformas comerciales prefabricadas no pueden acomodar protocolos internos propietarios o heredados.

Puntos fuertes: Construir tu propia infraestructura te da control total sobre cada byte de datos y cada solicitud de red. Los desarrollos personalizados son una base educativa sólida para entender exactamente cómo el protocolo maneja la negociación de capacidades y el intercambio de contexto.

La contrapartida: La carga de ingeniería es enorme. Eres responsable de construir, mantener y escalar tus propios pipelines de autorización multiusuario, reglas de enrutamiento, límites de seguridad de red y toda la plomería de auditoría desde cero. Además, quedas atado al ecosistema de modelos de Anthropic, ya que los servidores de referencia están hechos para Claude. El resultado son costos de mantenimiento altos y atención de ingeniería desviada de las funcionalidades del producto.

Runbook de 5 pasos para desplegar agentes MCP en producción

Los despliegues de AI empresarial que manejan código sensible, datos de clientes o sistemas regulados siguen el mismo camino de cinco pasos, sin importar el equipo.

1. Mapea el radio de impacto: Identifica tus sistemas objetivo y clasifica la sensibilidad de los datos y acciones a los que accederá el agente antes de escribir cualquier código.
2. Elige tu arquitectura: Selecciona la categoría de plataforma adecuada, Registry, Gateway o Runtime, basándote exclusivamente en los niveles de seguridad y gobernanza que estableciste en el primer paso.
3. Configura el mapeo de identidades: Nunca uses claves compartidas para datos sensibles. Vincula todas las acciones del agente a identidades humanas reales y verificables desde tu proveedor de identidad principal, usando flujos de autorización modernos.
4. Implementa filtrado de visibilidad: Aplica control estricto sobre el catálogo. Asegúrate de que los agentes solo puedan descubrir e invocar dinámicamente las herramientas que el usuario autenticado tiene permiso explícito de usar.
5. Prueba el failover y los reintentos: Valida cómo maneja tu plataforma los errores transitorios, los límites de tasa y las fallas de herramientas. Confía en lógica de reintentos estructurada y backoff exponencial, en lugar de depender de reintentos ilimitados del LLM.

Conclusión

La elección de infraestructura depende de la sensibilidad de los datos, no de un tradeoff universal. Usa registries para descubrimiento público de herramientas y gateways para enrutar herramientas de productividad no críticas. Para despliegues de AI empresarial que manejan código sensible, datos regulados o flujos multiusuario, los runtimes de ejecución son la única opción viable.

No le des a un agente de AI acceso ilimitado con cuenta de servicio a tus plataformas de desarrollo. La inyección de prompts es una amenaza constante, y los agentes con permisos excesivos son una vulnerabilidad que los atacantes aprovecharán.

Si estás construyendo agentes multiusuario y no puedes permitirte filtrar código fuente ni comprometer tu entorno de ingeniería, explora Arcade. Arcade ofrece autorización por usuario, herramientas optimizadas para agentes y gobernanza del ciclo de vida, todo dentro de una sola capa de runtime.

¿Quieres darle a tus agentes acceso seguro por usuario a herramientas empresariales sin construir infraestructura de autenticación desde cero?

Regístrate en Arcade ahora.

FAQ: MCP Gateways, Runtimes y Seguridad

¿Cuál es la diferencia entre un MCP Registry, un Gateway y un Runtime?

Un registry gestiona el descubrimiento y catalogación de herramientas, un gateway enruta solicitudes (frecuentemente con una cuenta de servicio compartida) y un runtime ejecuta herramientas de forma segura con autorización por usuario, secretos en vault y registros de auditoría.

¿Cuándo usar un MCP Gateway versus un MCP Runtime?

Usa un gateway para herramientas de bajo riesgo y enrutamiento rápido con identidad compartida. Usa un runtime cuando necesites OAuth/OBO por usuario, RBAC y registros de auditoría con OpenTelemetry para agentes en producción.

¿Los MCP Gateways soportan autorización por usuario (OAuth/OBO)?

La mayoría de los gateways usan por defecto una cuenta de servicio compartida y no ofrecen ejecución OBO real por usuario. Si necesitas permisos por usuario aplicados en tiempo de ejecución, generalmente necesitas un runtime o middleware de autenticación personalizado considerable.

¿Cómo evito que la inyección de prompts exfiltre código fuente a través de herramientas?

Aplica mínimo privilegio por usuario, mantén las credenciales fuera del contexto del modelo y ejecuta verificaciones de política antes y después de cada llamada a herramientas. Los runtimes reducen el radio de impacto al ejecutar las llamadas con los permisos limitados del usuario autenticado.

¿Puedo ejecutar MCP de forma segura en una VPC o con herramientas autohospedadas como GitHub Enterprise?

Sí, pero necesitas conectividad privada (por ejemplo, tunneling o peering) para que los servicios internos no queden expuestos públicamente. Prefiere plataformas que soporten explícitamente infraestructura privada y patrones de red empresarial.

¿Qué registros de auditoría necesito para agentes de AI empresarial?

Necesitas registros que documenten qué agente hizo qué, en nombre de quién, en qué sistema y cuándo, vinculados a una identidad de usuario real. Los registros compatibles con OpenTelemetry son un requisito común para la trazabilidad y la respuesta a incidentes.

¿Dónde deben vivir los secretos en una configuración MCP?

Los secretos deben almacenarse en un vault e inyectarse solo en tiempo de ejecución. Nunca los pongas en prompts ni en la ventana de contexto del modelo. El agente debe recibir el resultado de una acción, no las credenciales brutas usadas para realizarla. Los runtimes ofrecen este aislamiento de credenciales de forma nativa.

¿Un “MCP Gateway” es solo un API gateway?

No exactamente. Las interacciones MCP suelen ser multi-turno y con estado, mientras que los API gateways tradicionales están optimizados para ciclos de solicitud-respuesta sin estado. Si usas un API gateway, normalmente necesitarás middleware adicional con soporte para MCP.

¿Puedo usar un API gateway existente para MCP?

No directamente. Los API gateways tradicionales están diseñados para solicitudes sin estado, mientras que MCP es stateful y multi-turno. Tendrías que construir un middleware personalizado considerable para manejar los requisitos de MCP en cuanto a negociación de capacidades e intercambio de contexto.

¿Cómo manejo el cumplimiento de SOC 2 con agentes de AI?

Hay dos aspectos independientes. Primero, tu proveedor debe contar con certificación SOC 2 Tipo 2 como requisito de adquisición empresarial, lo que valida sus controles internos. Segundo, el producto en sí debe generar registros de auditoría estructurados que documenten quién hizo qué, en qué sistema y cuándo, vinculados a una identidad de usuario autenticada. La certificación por sí sola no garantiza la visibilidad por acción ni la gobernanza que necesitas. Busca registros compatibles con OpenTelemetry con trazabilidad por usuario como capacidad del producto, no solo como declaración de cumplimiento.

¿Esto aplica más allá de los equipos de ingeniería y DevOps?

Sí. La misma arquitectura aplica a cualquier despliegue de AI empresarial que maneje datos sensibles. Los agentes de Recursos Humanos que acceden a Workday, los agentes de finanzas que acceden a sistemas contables y los agentes legales que acceden a repositorios de contratos requieren autorización por usuario, credenciales en vault y registros de auditoría. Los ejemplos de ingeniería de esta guía se generalizan directamente a cualquier área donde los agentes actúen en nombre de usuarios autenticados.