La mayoría de demos de MCP todavía asumen una condición incómoda: para que un agente use una herramienta interna, alguien termina abriendo un endpoint, pegando una llave larga en una configuración o confiando demasiado en que el modelo no va a tocar algo indebido. OpenAI Secure MCP Tunnel, anunciado el 19 de mayo de 2026, ataca justo ese borde.

La noticia útil no es que ChatGPT, Codex, Responses API y AgentKit puedan llamar más tools. La noticia útil es que OpenAI formaliza un patrón donde el servidor MCP privado no queda expuesto a internet. En su lugar, corres un tunnel-client dentro de la red que sí alcanza ese servidor, y ese cliente hace polling contra un endpoint hospedado por OpenAI.

Flujo editorial con un tunnel-client dentro de una red privada reenviando requests MCP hacia herramientas internas

Qué cambia frente a publicar un MCP remoto

Un MCP remoto público es cómodo, pero también sube el riesgo de superficie. Tienes que resolver autenticación, rate limits, red, auditoría, permisos por usuario y exposición accidental. Secure MCP Tunnel cambia la topología:

OpenAI recibe la llamada desde el producto que usa el agente.
El endpoint de tunnel encola el request.
Tu tunnel-client, corriendo dentro de tu red, toma ese trabajo.
El cliente reenvía el JSON-RPC al MCP privado y devuelve la respuesta.

Ese detalle importa porque desplaza el perímetro. El servidor MCP puede seguir cerca de bases internas, APIs privadas o entornos on-prem sin convertirse en un servicio público más.

Por qué esto es buscable para builders

Las consultas alrededor de secure mcp tunnel, private MCP server, Codex MCP private tools o ChatGPT MCP enterprise no son masivas, pero sí vienen con intención fuerte. Quien busca eso no está preguntando qué es MCP. Está intentando conectar herramientas reales con datos reales.

Ahí Agente IA puede competir bien en español porque el ángulo no es “MCP está de moda”. Es mucho más concreto: cómo conectar herramientas privadas sin regalar el perímetro de red al agente.

La ganancia no elimina la revisión de permisos

Secure MCP Tunnel reduce una clase de exposición, pero no vuelve segura cualquier tool. Si el servidor MCP tiene permisos amplios, el agente puede seguir invocando acciones peligrosas a través del túnel.

La revisión que haría antes de activarlo:

separar servidores MCP por dominio de riesgo;
limitar tools de escritura;
registrar qué producto invoca cada tool;
revisar scopes por entorno;
y probar prompt injection contra las acciones más sensibles.

Panel editorial con permisos, auditoría y separación de servidores MCP por dominio de riesgo

Dónde sí lo usaría

Lo consideraría para equipos que ya tienen:

APIs internas que no deben salir a internet;
datos corporativos o de clientes detrás de VPN;
agentes en Codex o ChatGPT que necesitan consultar sistemas internos;
y un equipo capaz de operar credenciales, logs y rotación con disciplina.

No lo usaría como primer paso para una demo. Para aprender MCP, un servidor local simple sigue siendo suficiente. Para producción enterprise, en cambio, el patrón de túnel empieza a ser mucho más defendible que “abre este endpoint y reza”.

El error común: confundir túnel con autorización

El túnel resuelve transporte y exposición, no autorización de negocio. Si conectas un MCP que permite borrar cuentas, cambiar permisos o leer todo un CRM, la pregunta relevante sigue siendo: ¿quién decidió que ese agente puede hacerlo y bajo qué evidencia?

Por eso esta noticia conecta naturalmente con la base del curso gratis de agentes, pero pertenece a una etapa más avanzada: cuando el problema ya no es crear el agente, sino meterlo dentro de una red real sin perder control operativo.

La lectura corta: Secure MCP Tunnel no es una feature vistosa; es infraestructura de confianza para que MCP salga de la demo y entre a entornos donde abrir puertos ya no es aceptable.