OpenAI Secure MCP Tunnels: Cómo funcionan (Guía 2026)

El 27 de mayo de 2026, OpenAI lanzó Secure MCP Tunnel. La promesa es pequeña y específica: mantén tu servidor MCP privado y permite que los productos de OpenAI lo llamen de todos modos. La guía oficial y el repositorio del cliente se citan en su totalidad en la sección de fuentes al final de este artículo, para que puedas leer la documentación principal después del recorrido.

1. TL;DR

Usa Secure MCP Tunnel cuando tengas un servidor MCP en un portátil, una VM, un clúster de Kubernetes o una red privada, y quieras que ChatGPT, Codex, la Responses API o AgentKit lo utilicen sin hacerlo público. Ejecutas un pequeño demonio llamado tunnel-client junto al servidor. Se conecta a OpenAI a través de HTTPS, realiza long-polling para obtener trabajo, reenvía cada solicitud a tu servidor y publica la respuesta de vuelta. Sin puertos de entrada, sin URL pública, sin ngrok.

Evítalo si tu servidor MCP ya es público de forma segura (simplemente usa la herramienta MCP alojada normal con una server_url), o si no estás dispuesto a enrutar el tráfico MCP a través de un endpoint alojado en OpenAI. Y lee la sección de seguridad dos veces: el túnel elimina exposición de red y, no riesgo de prompt-injection o envenenamiento de herramientas (tool-poisoning). Esos son problemas distintos.

2. Qué es

Aquí está la definición directamente de la documentación, vale la pena citarla textualmente porque los motores de búsqueda de IA la extraen directamente:

“Secure MCP Tunnel le permite conectar servidores MCP privados a productos de OpenAI compatibles sin abrir puertos de firewall de entrada ni exponer

Y el túnel en sí, un nivel más abajo: “Un MCP tunnel es una conexión solo de salida desde un host dentro de su red hacia un endpoint de MCP outbound-only — es todo el diseño. Su red nunca acepta una conexión

MCP (Model Context Protocol) es el estándar abierto que permite que un modelo de IA llame a herramientas externas mediante JSON-RPC. Una herramienta MCP alojada normal server_url — Los propios ejemplos de OpenAI apuntan a cosas como https://mcp.stripe.com. Secure MCP localhost.

3. Por qué existe

Antes de esto, conectar un servidor MCP privado a un modelo alojado implicaba una de tres opciones incómodas. Cada una tiene un modo de fallo que un equipo de seguridad bloquearía.

1. Exponerlo públicamente. Colocar el servidor MCP en una URL pública con TLS y autenticación. Ahora tienes una nueva superficie de ataque expuesta a internet, y los servidores MCP expuestos accidentalmente son un problema real documentado.
2. Tunelizarlo con ngrok o Cloudflare Tunnel. Funciona, pero es un proxy inverso de propósito general. Los túneles rápidos “no fueron diseñados como límites de seguridad” — CORS abierto por defecto, sin filtrado de rutas, sin conocimiento de MCP.
3. Abrir una regla de firewall de entrada. La opción que menos suele aprobar tu equipo de seguridad y la única que una máquina de desarrollador no puede ofrecer en absoluto.

La respuesta de Secure MCP Tunnel es invertir la conexión. La documentación lo explica claramente: el acceso al túnel “sigue el contexto existente de la organización y el espacio de trabajo en lugar de introducir una ruta de entrada pública independiente.” No estás creando una nueva puerta de entrada. Estás permitiendo que un daemon que tú controlas se conecte a través de la puerta que ya tienes.

4. Modelo mental: Las piezas nombradas

Cinco piezas componen toda la funcionalidad. Aprende estos nombres y la documentación se leerá de una sola vez.

El flujo de datos es un bucle de sondeo, no un socket persistente que OpenAI mantiene abierto hacia su red. Léalo de arriba a abajo:

        OpenAI cloud                         Your network (trust boundary)
 ┌─────────────────────────┐          ┌──────────────────────────────────────┐
 │ ChatGPT / Codex /        │          │                                        │
 │ Responses API / AgentKit │          │   tunnel-client (daemon)               │
 │           │              │          │        │            │                  │
 │           v              │          │        │            v                  │
 │  OpenAI-hosted tunnel    │  <====== │  (1) outbound HTTPS long-poll          │
 │  endpoint  (queues work) │          │      GET /v1/tunnel/{id}/poll          │
 │           │              │  ======> │  (2) queued JSON-RPC request           │
 │           ^              │          │        │                               │
 │           │              │          │        v                               │
 │  (4) response returns    │  <====== │  (3) forward to private MCP server     │
 │      to the product      │          │      (stdio command or HTTP URL)       │
 └─────────────────────────┘          │        │                               │
                                       │        v                               │
                                       │   Private MCP server (localhost / VPC) │
                                       └──────────────────────────────────────┘
   The MCP server never has a public listener. Every arrow your network draws
   is OUTBOUND. OpenAI never initiates a connection into your boundary.

Conclusión clave: el diseño de sondeo es el punto central. Un demonio que solo realiza llamadas salientes es algo que un firewall y un revisor de seguridad pueden analizar realmente. Un socket entrante persistente no lo es.

5. Ejemplo de extremo a extremo más pequeño

Esta es la guía de inicio rápido canónica de la documentación, palabra por palabra. Asume que ya creó un túnel en la configuración de túneles de Platform y tiene su tunnel_id. Apunta el túnel a un stdio local Servidor MCP — un script de Python iniciado mediante un comando.

export CONTROL_PLANE_API_KEY="sk-..."

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-stdio \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-command "python /path/to/server.py"

tunnel-client doctor --profile local-stdio --explain
tunnel-client run --profile local-stdio

Tres comandos realizan el trabajo. init escribe un perfil con nombre a partir de una muestra. doctor --explain verifica el perfil y te indica por qué algo no es saludable antes de que dependas de ello. run inicia el bucle de sondeo del daemon. Mantén run activo mientras creas y pruebas el conector — la documentación es explícita al decir que “la detección de conectores y las llamadas a herramientas MCP dependen del cliente en ejecución.”

Si tu servidor MCP utiliza HTTP en lugar de stdio, cambia un flag — usa --mcp-server-url en lugar de --mcp-command:

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile local-http \
  --tunnel-id tunnel_0123456789abcdef0123456789abcdef \
  --mcp-server-url https://mcp.internal.example.com/mcp

Luego, confirma que el daemon esté realmente saludable antes de tocar ChatGPT. tunnel-client expone endpoints de operador y una UI de administración de loopback exactamente para esto:

curl -fsS http://127.0.0.1:8080/healthz   # process is up
curl -fsS http://127.0.0.1:8080/readyz    # connected and polling
open    http://127.0.0.1:8080/ui          # local admin UI (loopback-only)

6. Análisis profundo de cada pieza

6.1 El ciclo de vida de la solicitud

La documentación describe el bucle en cinco pasos. Un producto envía una solicitud MCP al endpoint alojado en OpenAI. El endpoint la pone en cola. tunnel-client realiza long-polling para obtener el trabajo en cola, reenvía cada solicitud JSON-RPC a tu servidor MCP privado y publica la respuesta de vuelta a través del mismo túnel. Cuando un conector solicita resultados en streaming, la ruta puede reenviar eventos intermedios enviados por el servidor (server-sent events), por lo que las herramientas de streaming siguen funcionando. El punto de inicio de la red siempre permanece dentro de tu límite.

Conclusión subjetiva: “long-poll, luego reenvía solo lo que puedas procesar” te proporciona una contrapresión natural. Tu servidor nunca recibe una avalancha de peticiones (thundering herd) de OpenAI — el cliente extrae el trabajo a su propio ritmo.

6.2 tunnel-client y perfiles

tunnel-client es un binario de Go, de código abierto bajo openai/tunnel-client. The docs are firm about distribution: get it from the Platform download link or the latest public release, and “keep your runbook pointed at the latest-release URL instead of hard-coding a specific release URL.” It is not on npm or PyPI. A profile es una configuración con nombre (la local-stdio anterior), por lo que un host puede ejecutar varios túneles con diferentes ajustes. También puedes gestionar todo mediante variables de entorno y flags, con la precedencia flags > env vars > YAML > defaults.

Recomendación: usa profiles, no una lista interminable de flags. Un directorio profiles/ /config env:VARNAME versionado con secretos referenciados como file:/path /workflows

o variables de entorno es la diferencia entre un despliegue reproducible y uno único que no puedes reconstruir.

6.3 Dónde ejecutarlo tunnel-client Ejecuta

• tunnel-client en el mismo límite de confianza que ya tenga acceso al servidor MCP. La documentación menciona tres patrones: localhostSidecar de Kubernetes
• — ejecútalo junto al servidor MCP en un mismo Pod y conéctate a través de localhost
• . Despliegue dedicado de Kubernetes

— ejecútalo por separado cuando el servidor ya sea accesible a través de un Service privado. localhost hop, un ciclo de vida. Recurre al despliegue dedicado solo cuando varias cargas de trabajo comparten un mismo servicio MCP.

6.4 Permisos e identidad

El acceso al túnel utiliza el contexto de tu organización y espacio de trabajo actual. Tres átomos de permiso lo controlan, los cuales se asignan a roles reales:

La clave de API de tiempo de ejecución que tunnel-client ejecuta con necesita Read + Use. Una identidad de administrador independiente necesita Read + Manage para crear o editar metadatos del túnel. Mantenlos separados — el daemon nunca debería tener permisos de creación/eliminación.

Conclusión clave: el principio de menor privilegio está integrado, así que úsalo. El daemon de larga duración obtiene Use, un humano o un trabajo de CI obtiene Manage, y ambos nunca comparten una clave.

6.5 Harpoon: llamadas HTTP permitidas (allowlisted)

Más allá de MCP, tunnel-client incluye un servidor MCP integrado llamado Harpoon que expone un pequeño conjunto de endpoints REST privados por etiqueta, con tamaños de solicitud y respuesta limitados. Su propósito es acceder a un puñado de servicios internos sin hacerlos públicos. La documentación es tajante: “Harpoon no es un proxy de propósito general: los llamadores no pueden elegir hosts arbitrarios, y las solicitudes están limitadas a los destinos y métodos configurados por el cliente.”

Conclusión subjetiva: Harpoon es un bisturí, no una VPN. Si sientes la necesidad de usarlo para acceder a “cualquier cosa interna”, es que se te ha quedado pequeño y deberías exponer un servidor MCP adecuado en su lugar.

6.6 OAuth a través del túnel

Si tu servidor MCP utiliza OAuth, hay una advertencia que te costará una tarde entera si la pasas por alto. El descubrimiento de OAuth (discovery) puede viajar a través del túnel, y el túnel preserva los metadatos del servidor de autorización upstream para los flujos orientados al navegador. Pero, en palabras de la propia documentación: “El servidor de autorización en sí no se tuneliza automáticamente. Si no es accesible desde la internet pública ni desde el tunnel-client host,

Conclusión subjetiva: tuneliza el servidor MCP, pero asegúrate de que el servidor de autorización OAuth sea accesible desde donde se ejecutan el navegador y el cliente. Un servidor MCP accesible con un servidor de autenticación inaccesible es un fallo silencioso y confuso.

7. Lo que hicimos mal

Cuatro suposiciones nos jugaron una mala pasada en la primera ejecución. Son exactamente las cosas que el eslogan de marketing te hace creer.

Asumimos que “privado” significaba que los datos nunca tocan a OpenAI. No significa eso. La dirección address y las credenciales de tu servidor permanecen locales, pero las cargas útiles (payloads) de solicitud y respuesta de MCP aún transitan por el endpoint alojado de OpenAI, exactamente igual que cualquier otra llamada a una herramienta alojada. El túnel oculta dónde reside tu servidor; no mantiene el tráfico de la herramienta fuera de la plataforma de OpenAI. Si una carga útil es demasiado sensible para enviarla a un modelo alojado, un túnel no cambia eso.

Asumimos que era el “ngrok de OpenAI”. Es más limitado a propósito. ngrok reenvía tráfico arbitrario a un puerto. El túnel reenvía JSON-RPC de MCP a tu servidor MCP, además de HTTP estrictamente permitido a través de Harpoon. Esa limitación es una característica, no una funcionalidad faltante.

Nos pusimos a buscar npm install. No existe ninguno. tunnel-client es un binario descargado o una compilación de Go openai/tunnel-client. Perdimos diez minutos asumiendo que existía un paquete porque todos los demás SDK de OpenAI tienen uno.

Asumimos que un túnel hace que toda la configuración sea “segura”. Asegura la ruta de red. No hace nada contra una llamada de herramienta maliciosa o

8. Patrones incorrectos vs. correctos

9. Errores comunes (obtenidos de la documentación)

Estos provienen directamente de las notas oficiales de configuración y solución de problemas, con la causa raíz junto al síntoma.

• El túnel no es visible en ChatGPT. Causa raíz: el túnel no está asociado con el workspace de destino, o al operador del conector le falta el permiso Tunnels Use. Corrige el alcance del workspace y el permiso.
• El descubrimiento del conector o las llamadas a herramientas fallan. Causa raíz: tunnel-client run detenido. El descubrimiento y las llamadas dependen del cliente en ejecución. Reinícialo y vuelve a ejecutar doctor --explain.
• Puedes ver un túnel pero no puedes editarlo. Causa raíz: el operador tiene Tunnels Read pero no Manage. Concede el permiso Manage a la identidad que edita los metadatos.
• OAuth falla aunque el servidor MCP es accesible. Causa raíz: el servidor de autorización no está tunelizado y no es accesible desde la internet pública ni desde el host del cliente. Haz que el servidor de autenticación sea accesible.
• Las solicitudes a través del túnel fallan de forma intermitente. Causa raíz: el cliente no está conectado. Si tunnel-client se está reconectando, las solicitudes fallarán hasta que vuelva a estar en línea. Observa /readyz y /metrics.

10. Notas sobre rendimiento, escalabilidad y costos

Primero, las cifras honestas: OpenAI no publica cifras de latencia o rendimiento específicas para el tunnel, y no existe un precio documentado para el tunnel. Lo que los docs y el repo sí te ofrecen son los parámetros que definen su comportamiento.

• Tiempo de long-poll. El cliente utiliza long-poll para obtener trabajo; tanto la ventana de sondeo como el límite de solicitudes en curso son configurables. Ajústalos para equilibrar las conexiones inactivas frente a la latencia de respuesta.
• TTL de conexión. La ventana de conexión MCP está limitada (el valor predeterminado del repo es del orden de minutos). Una herramienta que tarde más que esa ventana debe transmitir su progreso o finalizar a tiempo, o será interrumpida.
• La contrapresión (backpressure) es gratuita. Debido a que el cliente solicita el trabajo en lugar de recibirlo mediante push, un servidor MCP lento ralentiza su propia ingesta en lugar de colapsar bajo carga. Escalas ejecutando más clientes o un servidor más potente, no absorbiendo una avalancha de peticiones.
• Costo. Para la herramienta MCP alojada en general, OpenAI indica que solo pagas por los tokens utilizados al importar definiciones de herramientas o realizar llamadas a herramientas, sin cargos adicionales por llamada. Un cargo específico por tunnel no está especificado en los docs — verifícalo en los ajustes de Platform antes de asumir que es gratuito a gran escala.

11. Para quién es esto (y para quién no)

12. Señal de la comunidad

El anuncio provino de la cuenta de desarrollador de OpenAI y fue amplificado por Greg Brockman, quien lo definió como “trae tus propios servidores MCP”.

La arquitectura no es exclusiva de OpenAI. Anthropic lanzó un patrón de túnel MCP funcionalmente similar semanas antes, y la modelo de seguridad — mover las credenciales al perímetro significa que un agente con inyección de prompts no tiene ningún token que robar — y escéptico sobre el lock-in.

Vale la pena citar la voz contraria. La crítica principal en ese hilo expone el intercambio con claridad:

«No eres dueño del bucle. Eres dueño del límite. Si esa transacción te resulta favorable depende de cuánto confíes en [el proveedor] para ejecutar el bucle y de cuánto bloqueo de proveedor (vendor lock-in) puedas tolerar».
— r/mcp, sobre el patrón de arquitectura de túnel.

Otros en el mismo hilo plantearon la pregunta obvia: «¿qué impide que el certificado local se filtre o sea robado?» y señalaron que trasladar el riesgo de los tokens al tiempo de actividad del proveedor sigue siendo un traslado, no una eliminación. Son puntos válidos. Un túnel es un intercambio: menos exposición de red, mayor dependencia de un plano de control alojado por OpenAI.

Nuestra opinión

Secure MCP Tunnel es un movimiento dentro de un cambio mayor: los principales proveedores de modelos están compitiendo para hacer

Secure MCP Tunnel is one move in a larger shift: the major model vendors are racing to make tus herramientas privadas utilizables por sus agentes alojados sin que tengas que exponer nada. Anthropic lo hizo. OpenAI lo hizo. El patrón compartido — solo de salida, credenciales en el perímetro, bucle ejecutado por el proveedor — se está convirtiendo en la forma empresarial predeterminada para la conectividad de agentes. Espera que Google y otros lancen la misma primitiva bajo diferentes nombres.

Para los siguientes pasos prácticos, nuestra Guía de configuración de servidores MCP cubre la conexión de servidores a un IDE, el tutorial de Construye tu propio servidor MCP muestra cómo escribir el servidor que pondrías detrás de un túnel, y la guía del SDK de Python para agentes de OpenAI explica el entorno de ejecución de agentes más amplio que consume estas herramientas.

15. Preguntas frecuentes

16. Glosario

• MCP: Model Context Protocol, el estándar abierto para permitir que los modelos llamen a herramientas externas mediante JSON-RPC.
• servidor MCP: un proceso que expone herramientas, recursos y prompts a un cliente MCP.
• Secure MCP Tunnel: la función de OpenAI para conectar un servidor MCP privado a sus productos sin un listener público.
• tunnel-client: el demonio ejecutado por el cliente que consulta a OpenAI y reenvía las solicitudes a tu servidor MCP.
• Punto de conexión de túnel alojado por OpenAI: el edge público al que llaman los productos de OpenAI; pone en cola el trabajo para tu túnel.
• tunnel_id: la identidad del túnel, formato tunnel_ más 32 caracteres hexadecimales.
• clave de API de tiempo de ejecución: la credencial que tunnel-client utiliza; requiere Tunnels Read + Use.
• outbound-only: el tráfico siempre se inicia desde dentro de tu red; OpenAI nunca realiza llamadas entrantes.
• long-poll: el cliente mantiene abierta una solicitud HTTP a la espera de trabajo en cola, en lugar de recibirlo mediante push.
• transporte stdio: un servidor MCP iniciado mediante un comando y con el que se comunica a través de la entrada/salida estándar.
• Harpoon: un servidor MCP integrado en tunnel-client para llamadas HTTP privadas estrictamente permitidas.
• mTLS: TLS mutuo, donde tanto el cliente como el servidor presentan certificados; opcional para el plano de control y el lado MCP.
• conector: el objeto del lado de ChatGPT que apunta a una fuente de herramientas, incluyendo un túnel.
• Herramienta MCP alojada en Responses API: el mcp tool type that lets the API call an MCP server, normally via a public server_url.

17. Todas las fuentes y enlaces

Fuentes primarias

• OpenAI: Guía de Secure MCP Tunnel
• openai/tunnel-client en GitHub
• OpenAI: MCP y conectores (herramienta MCP alojada)
• Especificación de autorización MCP (OAuth 2.1)

Comunidad

• @OpenAIDevs: Tweet de lanzamiento de Secure MCP Tunnel
• r/mcp: la arquitectura de túnel y la crítica al lock-in
• r/OpenAI: Reacción al soporte de MCP en ChatGPT

Contexto de Web y seguridad

• Invariant Labs: Ataques de envenenamiento de herramientas MCP
• Cloudflare: servidores MCP remotos (tunneling de arte previo)
• Solo.io: vulnerabilidades de seguridad en servidores MCP

Enlaces internos

• Guía de configuración de servidores MCP
• Crea tu propio servidor MCP
• Directorio de los mejores servidores MCP
• Guía del SDK de Python para agentes de OpenAI