Imagina que le pides a tu asistente de IA que revise una campaña, actualice el estado de un ticket de soporte y deje una nota en el CRM, todo en una sola conversación. El asistente entiende la instrucción perfectamente. El problema no es la IA: es que esos tres sistemas viven en plataformas distintas, con logins distintos, permisos distintos y nadie a cargo de vigilar qué puede tocar el agente y qué no. Un MCP Gateway es, precisamente, la pieza de arquitectura pensada para resolver ese problema.
Ese es exactamente el problema que resolvió Harness, una plataforma de entrega de software usada por miles de equipos técnicos, cuando construyó lo que llama un "MCP Gateway": una puerta única que permite a su asistente de IA operar sobre herramientas externas como GitHub, Jira y Confluence sin salir de la conversación y sin saltarse los controles de acceso de la empresa [1]. Es un caso de ingeniería muy específico, pero el patrón que resuelve (conectar un agente a "todo lo demás" sin perder gobernanza) es el mismo dolor que enfrenta cualquier empresa que hoy intenta llevar IA agéntica más allá de un chatbot de prueba.
¿Qué es un MCP Gateway y qué problema resuelve?
Un MCP Gateway es una capa intermedia que se ubica entre un agente de IA y las distintas herramientas de terceros que ese agente necesita usar, y que centraliza la autenticación, los permisos y la auditoría de cada llamada en un solo punto gobernado. En lugar de que el agente tenga una conexión suelta a cada aplicación, todas las integraciones pasan por esa puerta única.
Harness lo explica con una frase simple: para el agente de IA, GitHub, Jira y Confluence dejan de verse como sistemas separados y pasan a verse como una sola herramienta que puede invocar, mientras el gateway hace el trabajo pesado detrás de escena. El MCP Gateway se ubica entre Harness AI Chat y las aplicaciones de terceros que has conectado, y para el agente de IA se ve como un único proveedor de herramientas, mientras que detrás se conecta a cada aplicación MCP de terceros configurada como conector de Harness [1].
El origen del problema es muy concreto. Los clientes de Harness viven dentro de pipelines, servicios, entornos, secretos y conectores, pero buena parte del trabajo real (el cambio que efectivamente hay que enviar a producción) vive fuera de Harness: la fuente de verdad suele ser un repositorio de GitHub, y el contexto alrededor está en Jira, Confluence y una larga cola de otras herramientas SaaS [1]. Sustituye "pipeline" por "campaña", "orden de compra" o "caso de soporte" y el mismo problema aparece en marketing, eCommerce o retail: la IA vive en una plataforma, pero el trabajo real está repartido en cinco más.
¿Cómo funciona el gateway que construyó Harness?
Funciona reutilizando la infraestructura de seguridad que la empresa ya tenía, en lugar de inventar una capa paralela. Harness deliberadamente no reinventó la seguridad: el gateway reutiliza lo que Harness ya tiene, el RBAC de Harness determina quién puede ver qué, el Secret Manager de Harness almacena las credenciales, y los Conectores de Harness definen qué es alcanzable [1]. Esa decisión es la parte más replicable del caso: no hace falta un sistema de permisos nuevo para la IA si la empresa ya tiene uno para las personas.
En la práctica, esto se traduce en tres reglas de funcionamiento:
- Conectar una vez, usar en el chat. Un administrador agrega una aplicación MCP de terceros como conector de Harness, sin trabajo de ingeniería ni redespliegue, y queda disponible en el chat de IA [1].
- Visibilidad heredada, no nueva. Como corre sobre el RBAC de Harness, un usuario solo obtiene las aplicaciones a las que ya tiene acceso [1].
- Credenciales que el agente nunca ve. Los secretos quedan en el gestor de credenciales y el gateway los referencia en tiempo de ejecución, sin exponerlos nunca al modelo.
Sobre la gobernanza fina, Harness añadió cuatro capas que vale la pena mirar como checklist para cualquier implementación empresarial: visibilidad según el acceso del usuario, permisos por herramienta marcados como "permitido", "necesita aprobación" o "bloqueado", alcance acotado por conversación (cerrado por defecto) y barreras de tiempo real que inspeccionan entradas y salidas para detectar inyección de prompts o mal uso.
| Capa de control | Qué garantiza |
|---|---|
| Visibilidad por RBAC | El usuario solo ve las apps que ya podía usar antes de la IA |
| Permisos por herramienta | Cada acción se marca como permitida, con aprobación o bloqueada |
| Alcance por conversación | Una sesión se puede limitar solo a las herramientas que necesita |
| Guardrails en tiempo real | Se inspeccionan entradas y salidas por inyección de prompts o abuso |
¿Por qué conectar IA a herramientas externas es tan frágil a gran escala?
Porque en una infraestructura distribuida, con miles de cuentas y servidores que se reinician constantemente, una sesión de IA puede romperse silenciosamente a mitad de una tarea si no se diseña para tolerar fallos. Harness no corre en un solo servidor: su infraestructura abarca múltiples servidores, y las conexiones pueden romperse silenciosamente cuando un servidor se reinicia [1].
La solución de Harness fue diseñar el gateway para que la recuperación sea invisible para el usuario: si una sesión con una herramienta externa expira, el gateway la reestablece y reintenta solo, y como el estado de la conversación vive en un almacén compartido y no en la memoria de un solo proceso, otro nodo puede continuar la conversación si el original se cae. El usuario nunca nota la costura.
Este detalle no es un capricho técnico. Es el motivo por el que solo el 62% de los equipos de seguridad admite no tener forma de saber dónde se están usando modelos de lenguaje dentro de su organización, según datos de la propia Harness [4]. Sin una capa de gobernanza como esta, cada integración nueva de un agente con una herramienta externa es, literalmente, un punto ciego más.
¿Qué otras plataformas ofrecen una gobernanza similar para agentes de IA?
Harness construyó su gateway a medida, pero el patrón de "MCP Gateway" ya es una categoría de mercado con varios proveedores especializados que cualquier empresa puede adoptar sin construir nada desde cero. Estos son tres de los más consolidados a mediados de 2026:
| Herramienta | Dato concreto |
|---|---|
| Portkey | Su gateway procesa más de 1 billón de tokens y 120 millones de solicitudes de IA al día, gestiona más de 180 millones de dólares en gasto anualizado en IA y da soporte a más de 24.000 organizaciones, y en marzo de 2026 abrió su MCP Gateway con OAuth 2.1 como open source [10] |
| Kong AI Gateway | Desde la versión 3.12 de Kong Gateway incorpora un plugin AI MCP Proxy que traduce entre MCP y HTTP, y un plugin AI MCP OAuth2 que implementa la especificación OAuth 2.0 para servidores MCP [17] |
| Docker MCP Gateway | Es la solución open source de Docker para orquestar servidores MCP con patrones nativos de contenedores, ejecutando cada servidor MCP en contenedores aislados con privilegios restringidos [23] |
La propia documentación de Harness reconoce esta categoría: entre los gateways probados con su servidor MCP están Docker MCP Gateway, Portkey, LiteLLM, Envoy AI Gateway y Kong [6]. Si tu empresa no tiene equipo de ingeniería para construir un gateway propio como el de Harness, estas son las opciones que ya existen para replicar el mismo principio de gobernanza.
¿Qué significa esto si tu empresa no es una compañía de software?
Significa que antes de conectar un agente de IA a tu CRM, tu ERP o tu plataforma de eCommerce, necesitas resolver primero quién decide qué puede hacer ese agente y con qué credenciales, no después de que ya esté conectado a todo. El caso de Harness es de DevOps, pero el mismo dolor aparece cuando un equipo comercial quiere que su IA actualice oportunidades en el CRM, cree tickets de logística o responda con datos del catálogo.
Ya lo veíamos al analizar por qué tu CRM sigue siendo la casa aunque la IA toque la puerta: el agente puede ser conversacional, pero los permisos, los datos y las credenciales tienen que seguir viviendo en la plataforma que la empresa ya gobierna. El MCP Gateway de Harness es, en el fondo, la misma idea aplicada a un stack de DevOps: la IA no reemplaza el sistema de control de acceso, lo usa.
Para una empresa de marketing, retail o eCommerce, el patrón práctico se traduce así:
- Un solo punto de conexión, no un cable directo del agente a cada SaaS que usa el equipo (CRM, ERP, helpdesk, ads).
- Permisos heredados del sistema que ya existe, no un esquema de acceso nuevo solo para la IA.
- Reglas por acción, para que un agente pueda leer un pedido pero necesite aprobación humana para aplicar un descuento o cancelar una orden.
- Tolerancia a fallos, porque una conversación de un cliente con un asistente de IA no debería romperse porque un servidor se reinició.
Si quieres profundizar en cómo se diseña ese andamiaje de contexto y herramientas alrededor de un agente, publicamos un artículo específico sobre harness engineering y cómo escalar agentes de IA con control. Y si el interés es específicamente en marketing agéntico y MCP como protocolo de conexión, vale la pena revisar también cómo la IA agéntica está cambiando el marketing B2B.
Conclusiones Clave
- Un MCP Gateway centraliza el acceso de un agente de IA a múltiples herramientas de terceros en un solo punto gobernado, en vez de conexiones sueltas por cada aplicación.
- La gobernanza no se inventa desde cero: Harness reutilizó su propio RBAC, su gestor de secretos y sus conectores existentes en lugar de crear un sistema de permisos paralelo para la IA.
- La tolerancia a fallos es tan crítica como la seguridad: en infraestructura distribuida, una sesión de IA debe poder recuperarse sola sin que el usuario note la interrupción.
- Existen gateways MCP listos para usar (Portkey, Kong AI Gateway, Docker MCP Gateway) para empresas que no van a construir esta infraestructura desde cero.
- El mismo patrón aplica fuera de DevOps: CRM, ERP, helpdesks y plataformas de eCommerce enfrentan el mismo reto al conectar agentes de IA.
- El 62% de los equipos de seguridad no sabe dónde se usan modelos de IA en su organización, lo que convierte cada integración sin gobernanza en un punto ciego.
Si tu empresa está evaluando cómo conectar agentes de IA a las herramientas que ya usa (CRM, ERP, catálogo, soporte) sin perder control sobre accesos y datos, en Franco ayudamos a diseñar esa arquitectura de gobernanza antes de escalar. Conoce nuestro servicio de automatización con agentes de IA y MCP y conversemos sobre tu caso específico.
Sobre el Autor
Juan P Franco es consultor en expansión digital, comercio electrónico y automatización con agentes de IA. Ayuda a empresas de todo tamaño y modelo de negocio (B2B, B2C, retail, D2C) a crecer en canales digitales con estrategias basadas en datos y tecnología.
Referencias
[1] Harness. "How Harness AI Reaches Your Toolchain, Safely" (Bringing Third-Party Apps into Harness AI Chat). https://www.harness.io/blog/bringing-third-party-apps-into-harness-ai
[4] Harness. "AI Discovery, Testing & Protection." https://www.harness.io/products/ai-security
[6] Harness Developer Hub. "Harness MCP Server." https://developer.harness.io/docs/platform/harness-ai/connect-with-ai/harness-mcp-server/
[10] Portkey. "Portkey's Gateway is Now Fully Open Source." https://portkey.ai/blog
[17] Acquaviva, Claudio. "Kong AI/MCP Gateway and Kong MCP Server: technical breakdown." https://medium.com/@claudioacquaviva/kong-ai-mcp-gateway-and-kong-mcp-server-technical-breakdown-13420f610ee6
[23] Bishop W.C. Martin. "Best MCP Gateways for Enterprise AI (2026)." https://www.bishopwcmartin.com/best-mcp-gateways-for-enterprise-ai-2026/