Creamos el Túnel MCP seguro porque los servidores MCP que más les importan a los equipos suelen ser los que menos quieren exponer a Internet.
Queríamos compartir cómo abordamos esa restricción: mantener privados los servidores y, al mismo tiempo, ofrecer a ChatGPT, Codex y otros productos de OpenAI una ruta normal para las solicitudes MCP.
El Model Context Protocol ha facilitado la conexión de los sistemas de IA con herramientas y datos externos. Pero muchos de los servidores MCP más valiosos se ejecutan en redes empresariales, mallas de servicios privadas, laptops de desarrolladores y otros entornos diseñados para rechazar el tráfico entrante de redes públicas. Conectar estos servidores a productos de IA alojados a menudo ha requerido que los equipos creen puntos de acceso públicos, desplieguen infraestructura de proxy adicional o incorporen nuevos operadores de red en rutas sensibles.
El Túnel MCP seguro ofrece un enfoque más sencillo: los clientes ejecutan una pequeña aplicación cliente dentro de su entorno privado que establece una conexión HTTPS saliente con OpenAI. Esta aplicación:
- Recibe solicitudes MCP
- Las reenvía a un servidor local aprobado
- Devuelve respuestas y notificaciones a través de la misma conexión.
Los productos de OpenAI pueden usar el modelo estándar de solicitudes y respuestas de MCP, mientras el servidor subyacente permanece protegido por los controles de red existentes del cliente.
Lograr que esto funcionara de forma confiable y segura implicó resolver varios problemas de ingeniería a la vez: preservar el límite de la red privada del servidor, admitir los flujos de streaming y autenticación de MCP, y ofrecer a los equipos una aplicación cliente que puedan inspeccionar y operar. En esta publicación explicamos esas decisiones.
Diseñamos el túnel a partir de unos pocos principios: conectividad exclusivamente saliente, configuración explícita de los destinos, compatibilidad con el streaming y las notificaciones de MCP, y una aplicación cliente que los clientes ejecutan y que los equipos pueden inspeccionar y operar por su cuenta.
En conjunto, estos principios permiten conectar fácilmente herramientas y datos privados a los productos de OpenAI sin convertir los servidores MCP privados en servicios públicos.
Las opciones habituales no son las adecuadas
Hoy en día, los equipos suelen permitir el acceso a un servicio privado de una de estas tres formas: exponer un punto de acceso público, ejecutar un túnel de terceros o ampliar la red con una VPN o una conexión de peering.
- Un punto de acceso público facilita el acceso a costa de debilitar el límite de la red.
- Un proveedor de túneles de terceros puede permitir el acceso a un servidor privado rápidamente, pero también incorpora a la ruta de conexión otro proveedor al que evaluar y contratar, cuyo servicio hay que operar y en quien hay que confiar. Para los equipos empresariales, no es un detalle menor: el proveedor del túnel pasa a formar parte de la revisión de seguridad, del proceso de compras, del manual de operaciones y de la superficie de exposición de metadatos de un sistema cuyo propósito es mantener privadas las herramientas privadas.
- Las VPN y el peering de redes resuelven el acceso creando una conectividad de red amplia, lo que suele implicar demasiada infraestructura para una integración MCP de alcance limitado.
El Túnel MCP seguro adopta un enfoque más específico. En lugar de pedir a los clientes que muevan el servidor MCP, amplíen el perímetro de la red o incorporen otro proveedor de conectividad, el Túnel MCP seguro coloca junto al servidor privado una pequeña aplicación cliente de código abierto que se puede inspeccionar, y deja que esa aplicación inicie y controle la conexión con OpenAI.
El Túnel MCP seguro invierte la forma de establecer el acceso: el lado privado da el primer paso. Los productos de OpenAI envían solicitudes MCP a un punto de acceso del túnel alojado en OpenAI. El servicio de túneles pone el trabajo en cola para un túnel específico, y la aplicación cliente, que el cliente ya ejecuta junto al servidor MCP privado, lo recoge mediante HTTPS saliente. La aplicación reenvía la solicitud localmente y devuelve la respuesta por la misma ruta.
Esto ofrece a los productos de OpenAI una ruta normal para las solicitudes MCP sin exigir que el servidor privado acepte tráfico entrante de redes públicas ni crear una conectividad de red más amplia.
Figura 1. Ciclo de vida de una solicitud del Túnel MCP seguro.
¿Por qué empezar con long-polling?
Empezamos deliberadamente con un transporte que no presenta sorpresas operativas. HTTPS saliente ya es familiar para los firewalls empresariales, los entornos con proxy y los equipos de plataforma. El long-polling permite que la aplicación cliente del túnel solicite solo la cantidad de trabajo que puede procesar, lo que proporciona a la cola del lado del cliente un punto natural de contrapresión en lugar de fomentar el almacenamiento ilimitado en búfer.
Esa elección también hizo que el diseño implementado fuera fácil de entender:
- Un producto envía solicitudes MCP en formato JSON-RPC al punto de acceso alojado en OpenAI.
- El servicio de túneles mantiene abierta esa solicitud o la transmite por streaming hasta que la aplicación que ejecuta el cliente devuelve una respuesta final
- Cuando se solicitan resultados por streaming, el túnel puede reenviar eventos intermedios enviados por el servidor.
El resultado es una ruta normal de solicitudes y respuestas MCP para el producto, mientras el servidor MCP y su dirección permanecen privados. Las solicitudes, las respuestas y los eventos intermedios se retransmiten a través del punto de acceso del túnel alojado en OpenAI.
Mantener explícito el límite de seguridad
El túnel no es una forma de eliminar el límite de la red, sino de hacerlo explícito. La aplicación cliente del túnel, ejecutada por el cliente, se autentica ante el plano de control del túnel; el producto utiliza el punto de acceso del túnel alojado en OpenAI, y la dirección privada de MCP solo se utiliza desde dentro del entorno del cliente. El acceso al túnel está vinculado al contexto existente de la organización y el espacio de trabajo del cliente en OpenAI, así como a la identidad configurada del túnel, en lugar de convertirse en una ruta de red independiente con su propio modelo de acceso.
El diseño requiere algo más que elegir la dirección correcta de la conexión de red. Como la aplicación cliente del túnel se ejecuta dentro del entorno del cliente, su comportamiento debe poder inspeccionarse y tener un alcance deliberadamente limitado: los clientes deben poder entender qué código se ejecuta, qué ruta saliente abre y a qué servicios privados tiene permitido acceder.
Figura 2. El servidor MCP permanece dentro del perímetro del cliente.
Hacer que el desarrollo con MCP se sienta local
Queríamos que la aplicación cliente del túnel se sintiera como una herramienta de desarrollo, no como un proyecto de redes. Un desarrollador debería poder ejecutar un servidor MCP en una laptop, iniciar la aplicación cliente del túnel junto a él y conectar ese servidor a ChatGPT o Codex sin crear un punto de acceso público ni esperar a que se configure una VPN, se establezca una regla de firewall o se realice un cambio de peering.
Ese mismo flujo debería mantenerse cuando el servidor pase de una laptop a Kubernetes, una máquina virtual u otro entorno controlado por el cliente. Lo importante es que el modelo mental siga siendo el mismo: ejecutar la aplicación cliente cerca del servidor MCP privado, validar que pueda acceder a él y dejar que inicie la conexión con OpenAI. Las comprobaciones de estado y de disponibilidad, los registros y la interfaz de administración local permiten inspeccionar ese ciclo cuando algo no funciona, sin convertir el túnel en un proyecto de operaciones.
La experiencia de desarrollo también está presente en el propio Codex. La aplicación cliente del túnel incluye un complemento de Codex que convierte la configuración en un flujo de trabajo guiado, en lugar de exigir que los desarrolladores aprendan desde el principio cada opción, perfil y detalle del plano de control de tunnel-client. El objetivo no es crear un atajo local para una sola ocasión: el complemento debería generar una estructura de configuración que el equipo pueda seguir usando cuando el servidor pase de una laptop a Kubernetes, una máquina virtual u otro entorno de producción.
La misma idea aparece en el flujo de trabajo del asistente incluido con tunnel-client: como el asistente puede leer el contexto local del túnel que expone tunnel-client, puede ayudar al desarrollador a razonar a partir de la configuración real, en vez de instrucciones genéricas. Esto incluye qué perfil está activo, qué configuración se generó, si se puede acceder al servidor MCP local y en qué etapa del inicio se encuentra la aplicación cliente del túnel. Así, la solución de problemas forma parte del ciclo de desarrollo, en lugar de requerir una vía de escalamiento independiente.
Figura 3. El mismo ciclo de tunnel-client funciona desde la laptop hasta producción.
Por qué importa que la aplicación cliente del túnel sea de código abierto
La aplicación cliente del túnel es software de código abierto que el cliente ejecuta dentro de su perímetro, junto a los servidores MCP privados. Esto permite a los clientes y a quienes realizan revisiones de seguridad inspeccionar el código que se ejecuta en su entorno. Pueden inspeccionar qué hace la aplicación cliente, qué conexión saliente abre, cómo reenvía las solicitudes MCP localmente y qué configuración controla su alcance.
Esa transparencia mantiene el modelo de confianza alineado con la arquitectura: OpenAI aloja el servicio de túneles, pero el código que se ejecuta dentro del entorno del cliente es pequeño, se puede revisar y está bajo su control.
Autenticación empresarial sin acceso amplio a la red
Los servidores MCP privados rara vez son simples puntos de acceso HTTP internos anónimos. Pueden depender de OAuth, autoridades certificadoras privadas, proxies de salida o certificados de cliente en el tramo de conexión con MCP. Admitir esos servidores implicó considerar las condiciones habituales de las redes empresariales como parte del diseño del túnel, no como excepciones que los clientes deben resolver por su cuenta.
La restricción clave es que el servidor MCP debe seguir siendo privado. El descubrimiento de OAuth para el servidor MCP viaja por la ruta del túnel, de modo que el producto alojado puede averiguar cómo autenticarse sin exigir que el servidor MCP escuche conexiones desde la Internet pública. Del lado del cliente, la aplicación cliente del túnel se puede configurar para el entorno local: paquetes de certificados de CA personalizados, ajustes de proxy y mTLS del lado de MCP.
También mantuvimos explícito el límite. El túnel no permite automáticamente que OpenAI acceda a todos los puntos de acceso empresariales relacionados. Si un servidor de autorización es privado, el componente que realiza el flujo OAuth debe poder acceder a él. Ese límite es intencional: el Túnel MCP seguro proporciona una ruta de alcance limitado hacia las herramientas privadas configuradas, no un puente de red de propósito general.
Más allá de MCP
MCP es el formato principal para las herramientas de los modelos, pero las primeras pruebas alfa con clientes mostraron otro problema estrechamente relacionado: no todos los flujos de trabajo privados de los clientes están ya disponibles como servidores MCP. Algunos flujos de trabajo importantes son API REST existentes detrás del mismo firewall. Si el Túnel MCP seguro solo resolviera el acceso a MCP, los equipos seguirían necesitando un punto de acceso público independiente, un proveedor de túneles, una ruta VPN o un proyecto de peering para esas API privadas relacionadas.
Harpoon extiende el mismo modelo de conectividad limitada a destinos REST aprobados. En lugar de exponer URL arbitrarias, el cliente registra destinos etiquetados en la aplicación cliente del túnel. Los componentes del lado de OpenAI invocan esas etiquetas a través del Túnel MCP seguro, y la solicitud HTTP real sigue originándose dentro del entorno del cliente, junto al servicio privado.
La restricción importante es que las etiquetas no constituyen un puente de red de propósito general. Las llamadas siguen estando limitadas por el registro de destinos bajo control del cliente, los métodos permitidos, los límites de tamaño de las respuestas, los tiempos de espera, el comportamiento de las redirecciones y los controles de acceso al túnel. Esto ofrece a los flujos de trabajo aprobados de OpenAI una ruta controlada hacia las API privadas del cliente, sin pedirle que habilite el acceso entrante a la red ni otorgar a OpenAI una identidad similar a la de una VPN.