Seguridad en servidores MCP: La guía 2026 para túneles de herramientas AI

En 2026, internet ya no es solo una web de páginas para que los humanos naveguen — es una red de servicios para que los agentes AI la recorran. Si 2024 fue el año del chatbot, 2026 es el año de la infraestructura agentica. Herramientas como Claude Code han pasado de ser novedades experimentales a actores principales en entornos de desarrollo locales. No solo sugieren código; lo construyen, prueban y despliegan. Pero para hacerlo de manera efectiva, necesitan un puente. Ese puente es el Model Context Protocol (MCP).

A medida que avanzamos hacia este mundo centrado en agentes, la forma en que pensamos sobre el tunneling ha cambiado radicalmente. No solo estamos creando túneles para mostrar una demo a un cliente; estamos creando túneles para dar acceso a un agente autónomo a nuestro IDE local, bases de datos y terminal. Las apuestas son mucho mayores.

---

¿Qué es MCP y por qué importa ahora?

El Model Context Protocol es un estándar abierto introducido por Anthropic en noviembre de 2024 para estandarizar cómo los sistemas AI integran y comparten datos con herramientas, sistemas y fuentes externas. Ofrece una interfaz universal para leer archivos, ejecutar funciones y manejar prompts contextuales. Tras su anuncio, fue adoptado por grandes proveedores de AI como OpenAI y Google DeepMind.

En diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation (AAIF), un fondo dirigido bajo la Linux Foundation, cofundado por Anthropic, Block y OpenAI. Este movimiento formalizó MCP como un estándar abierto real, no un protocolo de un solo proveedor.

El crecimiento ha sido asombroso. Solo en 2025, se lanzaron más de 13,000 servidores MCP en GitHub. La versión oficial del estándar salió en noviembre de 2025, ampliando el protocolo más allá de llamadas síncronas a herramientas, hacia una arquitectura capaz de soportar flujos de trabajo seguros, duraderos y gobernados en entornos de producción reales. Hasta marzo de 2026, los mantenedores publicaron una hoja de ruta centrada en cuatro prioridades: transporte escalable vía Streamable HTTP, gestión del ciclo de vida de tareas, gobernanza para una base creciente de contribuyentes y preparación empresarial, incluyendo auditorías y autenticación SSO.

MCP ya no es solo infraestructura experimental. Es el tejido conectivo de la IA empresarial — y eso también lo convierte en un objetivo serio.

---

La anatomía de la crisis de seguridad MCP

De “Agregar servidor” a superficie de ataque

En los primeros días de adopción de MCP, los desarrolladores conectaban servidores rápidamente sin considerar el radio de explosión. En abril de 2025, investigadores de seguridad publicaron un análisis concluyendo que el protocolo tenía múltiples problemas de seguridad pendientes: inyección de prompts, combinaciones de herramientas demasiado permisivas que facilitan exfiltración de datos, y herramientas similares que pueden reemplazar silenciosamente a las confiables.

La pesadilla se intensifica cuando se pasa de stdio (comunicación local) a HTTP/S (tunneling remoto). Cuando expones tu entorno local a un modelo frontier como Claude, abres un canal bidireccional hacia tu máquina. A principios de 2026, las propuestas relacionadas con seguridad en MCP dominaron las propuestas en RSA Conference — y menos del 4% de esas propuestas se centraron en oportunidades. La comunidad de seguridad está casi completamente enfocada en la exposición.

Los vectores de amenaza reales

Envenenamiento de herramientas

El envenenamiento de herramientas es una forma de inyección de prompts indirecta donde instrucciones maliciosas se incrustan directamente en la descripción de una herramienta durante su registro — en los metadatos que indican a un AI qué hace cada herramienta y cómo usarla. Estos metadatos son visibles para el modelo, pero no normalmente para los usuarios humanos. Cuando un agente se conecta a un servidor MCP, solicita una lista de herramientas. El servidor responde con nombres y descripciones que se cargan directamente en el contexto del modelo. Una descripción envenenada engaña al agente para tratar un comando malicioso como un paso necesario en la operación legítima.

Un ejemplo real de Invariant Labs mostró una herramienta que parecía simplemente sumar dos números, pero cuya descripción oculta instruía al agente a leer primero ~/.cursor/mcp.json y exfiltrar su contenido — sin advertencia alguna al usuario.

Investigaciones del benchmark MCPTox probaron 20 agentes LLM destacados contra ataques de envenenamiento de herramientas usando 45 servidores MCP reales y 353 herramientas auténticas. Los resultados son alarmantes: o1-mini mostró una tasa de éxito del 72.8%. Los modelos más capaces a menudo eran más vulnerables, porque el ataque explota sus habilidades superiores para seguir instrucciones. Claude 3.7 Sonnet tuvo la tasa más alta de rechazo — menos del 3%.

El “Rug Pull”

Las herramientas MCP pueden mutar sus propias definiciones después de la instalación. Aprobas una herramienta que parece segura en el Día 1, y para el Día 7 ha sido actualizada silenciosamente para solicitar permisos adicionales o redirigir tus claves API. Como la mayoría de los clientes MCP no notifican a los usuarios cuando cambian las descripciones de las herramientas, esta clase de ataque pasa casi desapercibida. La solución es sencilla en teoría: los clientes deberían mostrar las descripciones iniciales y alertar sobre cambios posteriores. En la práctica, muy pocos lo hacen.

Ataques cruzados entre servidores y ataques en la cadena de suministro

Cuando varios servidores MCP están conectados a un mismo agente, uno malicioso puede anular o interceptar llamadas a uno confiable. Un incidente real en mayo de 2025 involucró la integración oficial de MCP en GitHub, donde los atacantes descubrieron que podían secuestrar agentes AI creando issues maliciosos en repositorios públicos. Como los desarrolladores suelen configurar MCP en GitHub con Tokens de Acceso Personal que dan acceso a todos los repositorios — públicos y privados — un issue envenenado podría instruir al agente a exfiltrar datos de repos privados y publicarlos.

Un ataque en la cadena de suministro separado involucró un paquete que se hacía pasar por un servidor MCP legítimo de Postmark. Una línea de código malicioso dirigía a los servidores MCP comprometidos a copiar en ciego cada email saliente a los atacantes — memos internos, restablecimientos de contraseña, facturas. Esto es el equivalente en 2026 a una vulnerabilidad en la cadena de suministro de npm, pero con un agente AI como mecanismo de entrega involuntario.

CVE-2025-6514 reveló una vulnerabilidad crítica de inyección de comandos OS en mcp-remote, un proxy OAuth popular para conectar clientes MCP locales a servidores remotos. Afectó a más de 437,000 entornos y convirtió cualquier instalación sin parche en una puerta trasera en la cadena de suministro capaz de ejecutar comandos arbitrarios, robar claves API, credenciales en la nube, claves SSH y contenidos de repositorios Git.

Invocación oculta de herramientas y robo de recursos

El equipo de Palo Alto Networks’ Unit 42 demostró que la función de muestreo de MCP — que permite a los servidores solicitar proactivamente completaciones de LLM — puede ser explotada de tres maneras: robo de recursos (agotar cuotas de API para cargas de trabajo no autorizadas), secuestro de conversaciones (inyectar instrucciones persistentes que manipulan respuestas del agente en múltiples turnos), y invocación oculta de herramientas (realizar operaciones no autorizadas en el sistema de archivos sin que el usuario se dé cuenta). En un ejemplo, la salida maliciosa nunca se mostró al usuario; solo el registro del servidor reveló lo ocurrido.

Privilegios excesivos y filtración de contexto

Sin las salvaguardas adecuadas, los servidores MCP pueden solicitar y recibir acceso privilegiado a datos sensibles mucho más allá de su función declarada. OWASP clasifica la inyección de prompts — base de la mayoría de ataques MCP — como la vulnerabilidad número uno en su Top 10 de LLM para 2025. Si las sesiones MCP no están bien aisladas, los datos sensibles también pueden filtrarse entre sesiones — un problema conocido como filtración de contexto.

La propia especificación MCP reconoce el riesgo, indicando que “SIEMPRE debería haber un humano en el ciclo con la capacidad de denegar invocaciones de herramientas.” Ese SHOULD tiene un peso importante, y los expertos en seguridad recomiendan tratarlo como un MUST.

---

La arquitectura Zero Trust 2026 para agentes

Ya no puedes confiar en suposiciones de localhost. Asegurar un flujo de trabajo agentico en 2026 requiere un enfoque Zero Trust en cada capa.

1. Patrón de Gateway MCP

En lugar de exponer tu servidor MCP directamente a través de un túnel, enruta el tráfico mediante un Gateway MCP dedicado que actúe como un interruptor de circuito — inspeccionando llamadas JSON-RPC entre el agente y tus herramientas antes de que se ejecuten.

El Gateway MCP de Docker, por ejemplo, ofrece aislamiento en contenedores, verificación de firmas para prevenir ataques en la cadena de suministro, bloqueo de red para aplicar redes Zero Trust, y bloqueo de secretos para evitar filtraciones de credenciales. También mantiene un registro exhaustivo de cada interacción entre agente y herramienta.

A nivel de política, configura tu gateway con:

• Limitación semántica de tasa. Si un agente intenta llamar a read_file 500 veces en diez segundos, el gateway termina la conexión. Los agentes legítimos no hacen eso.
• Disparadores con human-in-the-loop (HITL). Requiere aprobación manual para llamadas a write_file o execute_command. La especificación MCP recomienda esto; haz que sea un requisito obligatorio en tu entorno.
• Detección de intención conductual. Los sistemas estáticos basados en reglas no son suficientes. La protección moderna de MCP debe evaluar la intención de cada solicitud, marcando agentes autenticados que intentan acceder a archivos sensibles o exfiltrar datos — incluso si la solicitud pasa la autenticación inicial.

2. Túneles limitados en alcance y efímeros

Nunca tunnelices todo tu directorio raíz. Si un agente trabaja en project-x, tu túnel solo debe conceder acceso a esa subcarpeta. Este es el principio de menor privilegio aplicado al acceso agentico.

Una amenaza más sutil en 2026 es el secuestro de redirecciones OAuth mediante subdominios de túnel. Si detienes un túnel y un actor malicioso reclama el mismo subdominio — común en planes gratuitos con alta rotación — pueden interceptar solicitudes de enlaces antiguos. Usa subdominios persistentes y rotativos de manera deliberada.

3. Alcance y identidad del token

El incidente en GitHub MCP y CVE-2025-6514 comparten una causa raíz: scope de token demasiado amplio. Los Tokens de Acceso Personal que otorgan acceso a todos los repositorios son un riesgo. La actualización de la especificación MCP de junio de 2025 abordó esto clasificando los servidores MCP como Servidores de Recursos OAuth y exigiendo que los clientes implementen Resource Indicators (RFC 8707). Un Resource Indicator declara explícitamente el destinatario del token, evitando que un servidor comprometido use un token destinado a un servicio para acceder a otro — una clase de ataque conocida como malredención de tokens.

Para despliegues empresariales, OpenID Connect (OIDC) para identidad MCP se está convirtiendo en estándar. Solo una instancia específica y firmada criptográficamente de tu agente debería tener acceso a tu herramienta de base de datos local.

4. Sandboxing y descubrimiento

Ejecuta servidores MCP locales en un sandbox que limite explícitamente lo que pueden ejecutar y acceder. La especificación MCP no impone auditorías, sandboxing o verificación de servidores — esa responsabilidad recae en la organización. Establece un registro interno de servidores MCP verificados, y escanea continuamente configuraciones, prompts y definiciones de herramientas en busca de cambios no autorizados o entradas sospechosas. Los servidores MCP en sombra — desplegados sin supervisión de TI — son invisibles por defecto y se vuelven más peligrosos con el tiempo sin actualizaciones.

---

Tunneling para LLMs locales: ¿Qué funciona realmente en 2026?

La latencia es la dimensión de experiencia del desarrollador que define la calidad del flujo de trabajo agentico. Cuando un humano charla con una IA, una demora de dos segundos es molesta. Cuando un agente ejecuta un ciclo de pensamiento — Plan → Llamada a herramienta → Obtener resultado → Razonar → Próximo paso — una demora de dos segundos en cada salto es un problema serio. Una tarea de diez pasos con 500 ms de overhead en el túnel por salto suma cinco segundos de tiempo muerto. Ese contexto obsoleto degrada la calidad de salida notablemente.

El panorama del tunneling se ha fragmentado mucho desde que ngrok dominaba. El monopolio de ngrok terminó.

Estado de ngrok en 2026

ngrok ha pivotado hacia funciones empresariales de “Universal Gateway”, dejando su plan gratuito cada vez más restrictivo. A principios de 2026, el plan gratuito limita a 1 GB de ancho de banda mensual, un único endpoint activo y dominios efímeros aleatorios, además de una página de advertencia que hace que la URL parezca un enlace de phishing para stakeholders no técnicos. En febrero de 2026, el proyecto open-source DDEV abrió un issue público en GitHub para considerar eliminar ngrok como proveedor predeterminado debido a estas restricciones. Los planes de pago comienzan en $8/mes para uso personal, y suben a $20/mes en el nivel Pro.

ngrok sigue teniendo la mayor cantidad de integraciones de cualquier herramienta de tunneling y sigue siendo útil para equipos ya invertidos en su ecosistema. Pero ya no es la recomendación predeterminada para la mayoría de los flujos de trabajo de desarrolladores.

Cloudflare Tunnel

Cloudflare Tunnel (antes Argo Tunnel) es probablemente la opción gratuita más potente en 2026. Se integra directamente con la red global de Cloudflare, ofreciendo seguridad Zero Trust, protección DDoS, y integración con Web Application Firewall. Es realmente gratuito para la mayoría de los casos, sin límites de ancho de banda — una ventaja decisiva sobre ngrok.

Las desventajas son reales. Cloudflare Tunnel requiere un dominio gestionado por Cloudflare, lo que añade fricción en la configuración para desarrolladores que solo quieren exponer un servicio local rápidamente. Sus caídas globales, que han ocurrido varias veces, afectan tu endpoint local. Para demos temporales y ciclos de desarrollo diarios, herramientas con menos dependencia de infraestructura suelen ser más prácticas. Y su límite de 100 MB en carga es una restricción importante a conocer antes de comprometerse.

Para exposición persistente y de nivel producción de servicios locales — especialmente cuando se requiere autenticación Zero Trust — Cloudflare Tunnel es difícil de superar.

InstaTunnel

InstaTunnel ha emergido como la opción más amigable para desarrolladores en flujos de trabajo AI. Sus diferenciadores clave incluyen subdominios personalizados persistentes en el plan gratuito (eliminando la necesidad de actualizar configuraciones de webhook en cada reinicio), sesiones de 24 horas, y soporte nativo de primer nivel para endpoints MCP. El plan gratuito es más generoso que ngrok; el nivel Pro comienza en aproximadamente $5/mes frente a los $20/mes de ngrok para funciones similares.

Para trabajo local con LLM en particular, la capacidad crítica a verificar es el pass-through de SSE: el túnel debe reconocer encabezados text/event-stream y desactivar el buffering intermedio. Sin esto, los tokens de una instancia streaming de Ollama o LM Studio aparecen en lotes retrasados en lugar de en un flujo suave. Herramientas específicas como InstaTunnel manejan esto de forma nativa; los túneles de propósito general a menudo requieren configuración manual.

Tailscale

Tailscale adopta un enfoque arquitectónico completamente diferente. En lugar de enrutar tráfico a través de un relé central, construye conexiones encriptadas peer-to-peer usando WireGuard entre dispositivos en una red mesh privada. La exposición pública mediante Tailscale Funnel es una extensión deliberada de esta red, no su modo predeterminado. Esta arquitectura hace de Tailscale la opción más fuerte para acceso a infraestructura de equipo y escenarios donde cada participante puede instalar el cliente. No es la herramienta adecuada para demos rápidas o pruebas efímeras de webhooks.

Elegir la herramienta adecuada

La elección correcta depende de la intención:

• Exposición de LLM local y endpoint MCP durante desarrollo: InstaTunnel o Cloudflare Tunnel, dependiendo de si ya tienes un dominio gestionado por Cloudflare.
• Acceso persistente de nivel producción con autenticación Zero Trust: Cloudflare Tunnel.
• Infraestructura de equipo y redes mesh privadas: Tailscale.
• Auto-hospedado, independiente de proveedores: frp (Fast Reverse Proxy), con más de 100,000 estrellas en GitHub, es la opción open-source más adoptada.
• Pruebas rápidas y temporales sin cuenta: LocalTunnel, aunque sus servidores públicos suelen estar congestionados y son poco confiables bajo carga.

---

Verificación de tokens y streaming de tokens LLM locales

Si ejecutas un modelo local vía Ollama y lo expones mediante un túnel a un orquestador remoto, el cuello de botella suele ser tu ancho de banda de subida local. Sin embargo, la elección del túnel afecta la latencia en los márgenes, y los márgenes importan en ciclos agenticos.

Capacidades clave a verificar antes de comprometerte con un túnel para trabajo con LLM:

• Pass-through de SSE. El túnel debe reconocer encabezados text/event-stream y desactivar el buffering. Prueba transmitiendo una respuesta larga y verifica si los tokens aparecen progresivamente o en lotes retrasados.
• Soporte para conexiones de larga duración. El túnel no debe cerrar agresivamente conexiones durante pausas en inferencia, que pueden durar varios segundos en modelos grandes.
• Pinning regional. Escoge un proveedor de túnel con nodos cercanos geográficamente al orquestador del agente. La velocidad de la luz no es negociable.
• Subdominios persistentes. URLs efímeros requieren actualizar registros de webhook en cada reinicio. Los subdominios con nombre eliminan esta fricción por completo.

---

Construyendo tu pila agentica 2026

La era de integraciones API manuales da paso a infraestructura agentica plug-and-play. Para operar de forma segura y eficiente en este entorno:

El Cerebro: Claude (remoto vía API) o un modelo local vía Ollama, según tus requisitos de latencia y privacidad.

Las Manos: servidores MCP para acceso a sistema de archivos, ejecución de shell, GitHub, bases de datos y otras integraciones.

El Puente: InstaTunnel para flujos de trabajo de desarrollo de baja latencia, Cloudflare Tunnel para exposición segura en producción.

El Escudo: un Gateway MCP dedicado con controles HITL, detección de intención conductual, ejecución sandboxed y un registro interno verificado.

La Capa de Identidad: identidad basada en OIDC para MCP, tokens de acceso con scope limitado usando RFC 8707 Resource Indicators, y subdominios de túnel con nombre en lugar de efímeros.

Exponer tus herramientas locales a un agente AI es un verdadero superpoder para la productividad del desarrollador. Los protocolos maduran rápidamente, las herramientas se vuelven de nivel empresarial, y la superficie de ataque se mapea en tiempo real por la comunidad de seguridad. Los desarrolladores que construirán sobre esta infraestructura de forma segura son quienes traten sus servidores MCP con la misma disciplina que sus APIs de producción — menor privilegio, acceso auditado, y sin suposiciones de confianza.

---

Todos los vulnerabilidades de seguridad referenciadas son CVEs documentados o investigaciones de seguridad publicadas. Los detalles de la especificación MCP provienen del changelog oficial y de la hoja de ruta MCP de marzo de 2026 publicada por los mantenedores principales.