Gobernanza de MCP: la puerta trasera de tus agentes de IA

Cada vez que conectas un agente de IA a tu correo, tu CRM o tu base de datos a través de MCP (Model Context Protocol, el estándar abierto que usan ChatGPT, Claude y Gemini para hablar con tus sistemas), estás confiando en un servidor que probablemente nadie ha auditado. Según Enkrypt AI, que escaneó 25.000 servidores MCP y 268.000 herramientas conectadas a ellos, el 73% tenía al menos una vulnerabilidad explotable — 143.000 fallos en total. Y según Astrix Security, que auditó 5.205 servidores MCP de código abierto en octubre de 2025, solo el 8,5% usa OAuth; el resto se conecta con claves que no caducan nunca, muchas veces guardadas en texto plano.

MCP resuelve un problema real: antes, conectar un agente de IA a cada herramienta (Gmail, Slack, un CRM, una base de datos) exigía escribir una integración a medida. MCP estandariza esa conexión. El problema es que la rapidez con la que se ha adoptado no ha venido acompañada de gobierno: cualquiera puede montar un servidor MCP en una tarde, y la mayoría de las empresas los conecta a sus agentes sin preguntarse quién lo mantiene, qué hace exactamente, ni qué puede tocar.

Qué es un MCP Gateway y por qué tu empresa ya depende de uno

Un MCP Gateway es la capa que se coloca entre tus agentes de IA y los servidores MCP a los que se conectan: decide qué servidor puede hablar con qué agente, qué herramientas puede invocar, con qué credenciales y qué queda registrado. Sin esa capa, cada agente se conecta directamente a cada servidor MCP, y el control de acceso depende de la configuración que, por defecto, trajera ese servidor concreto — que, según los datos de abajo, casi nunca es la adecuada.

La diferencia con una integración clásica es esta: una API tradicional la instala y la revisa tu equipo de IT, con un contrato y una ficha de seguridad. Un servidor MCP, en la mayoría de los casos, lo descubre un desarrollador en un repositorio público, lo prueba, funciona, y se queda ahí conectado a los agentes de producción. Nadie lo dio de alta como activo de seguridad porque, formalmente, nunca pasó por ese proceso.

Las cifras que no salen en la demo de «conecta tu IA a todo»

En la demo se ve lo rápido que un agente de IA resuelve una tarea conectándose a diez herramientas distintas. Lo que no se ve es si alguien auditó esas diez conexiones. Los datos disponibles, todos de estudios independientes de 2025 y 2026, dicen que probablemente no:

• El 73% de 25.000 servidores MCP escaneados por Enkrypt AI tenía al menos una vulnerabilidad real, con 143.000 fallos encontrados en total — inyección de comandos, omisión de autorización e inyección de prompts, entre otros.
• En un escaneo anterior de Enkrypt AI sobre 1.000 servidores, el 33% tenía vulnerabilidades críticas, con una media de 5,2 fallos por servidor. Uno de ellos, un servidor MCP para gestionar clústeres de Kubernetes muy usado, tenía 26 vulnerabilidades — 6 de inyección de comandos con la puntuación máxima de gravedad (CVSS 9,8) — capaces de entregar el clúster entero a quien las explotara.
• El 53% de 5.205 servidores auditados por Astrix Security depende solo de claves de API estáticas que no caducan nunca; el 79% de esas claves se guardan en variables de entorno sin cifrar. Solo el 8,5% usa OAuth, el estándar que sí permite revocar el acceso sin tocar el servidor.
• Entre enero y abril de 2026 se publicaron más de 40 CVE distintos contra implementaciones de MCP en Python, TypeScript, Java y Rust — la base del protocolo, no casos aislados de un proveedor concreto.

El aviso que ya se hizo realidad: CVE-2025-6514

Esto no es un riesgo teórico. En julio de 2025, el equipo de investigación de JFrog descubrió que mcp-remote — un paquete que permite a clientes de IA conectarse a servidores MCP remotos, descargado más de 437.000 veces — tenía un fallo de inyección de comandos (CVE-2025-6514, gravedad 9,6 sobre 10). Un servidor MCP malicioso podía ejecutar código directamente en el ordenador de quien se conectara a él, sin que la víctima hiciera nada más que establecer la conexión. Fue, según JFrog, la primera vez que se demostró una ejecución remota de código completa a través de una conexión MCP en un caso real, no en un laboratorio. El fallo afectaba a las versiones 0.0.5 a 0.1.15 y se corrigió en la 0.1.16.

La lección no es «no usar MCP». Es que cada servidor MCP que conectas a tus agentes es, en la práctica, código de un tercero con permiso para actuar dentro de tu empresa — y se está tratando, en la mayoría de los casos, como si fuera inofensivo por defecto.

Lo que nadie dice cuando vende «agentes conectados a todo»

El discurso dominante sobre agentes de IA es «cuantas más herramientas conecte, más vale». Nadie vende la frase contraria, que es la que de verdad protege a una empresa: cada servidor MCP que conectas es una puerta nueva, y la inmensa mayoría de esas puertas, hoy, no tiene ni cerradura real ni quien lleve el registro de quién entró. El problema no es la IA ni el protocolo en sí — MCP es, de hecho, una buena idea técnica. El problema es que se está desplegando al mismo ritmo que una moda, sin el proceso de alta de proveedor, auditoría de seguridad y revisión de acceso que cualquier otra pieza de software de terceros tendría que pasar antes de tocar un sistema de producción.

Qué exige gobernar de verdad un MCP Gateway

De los datos anteriores se pueden extraer cinco controles concretos, no opcionales, para cualquier empresa que conecte agentes de IA a servidores MCP:

1. Lista blanca de servidores MCP aprobados. Ningún agente se conecta a un servidor MCP nuevo sin que alguien lo revise antes — igual que no se instala software sin pasar por IT. 2. OAuth o un sistema equivalente de credenciales que caducan, nunca claves estáticas guardadas en texto plano. Hoy lo hace menos de 1 de cada 10 servidores auditados. 3. Registro de auditoría por cada llamada a cada herramienta: qué agente, qué servidor, qué acción, cuándo — no un log genérico de la aplicación. 4. Aislamiento de red del servidor MCP, para que un fallo de inyección de comandos no se traduzca en acceso al resto de la infraestructura. 5. Revisión periódica de qué servidores siguen conectados y por qué — los proyectos piloto que pasan a producción sin revisión son, según los propios datos de abuso de MCP, uno de los puntos de entrada más repetidos.

Un ejemplo de cómo falla esto en el día a día

Un ejemplo ilustrativo, no un caso real: un equipo conecta su agente de IA a un servidor MCP de código abierto que sincroniza tickets de soporte con un CRM, encontrado en un repositorio público y probado en una tarde porque «funcionaba bien». El servidor usa una clave de API fija, sin caducidad, guardada en una variable de entorno del propio contenedor del agente. Nadie lo dio de alta como proveedor ni pasó por una revisión de seguridad porque, al no ser «un contrato con una empresa», no activó ninguno de los procesos habituales. Meses después, una actualización del servidor —fuera del control de la empresa— introduce una función nueva que lee también los campos de facturación del CRM, no solo los tickets. Nadie lo nota, porque no existe un registro que distinga qué datos tocó el servidor antes y después del cambio. El fallo no está en el agente de IA: está en haber tratado una pieza de software de terceros como si no lo fuera.

En Optima Quantum no conectamos agentes de IA a servidores MCP sin pasar antes por esta revisión: qué servidor es, quién lo mantiene, con qué credenciales se conecta y qué queda registrado de cada acción. Si tu empresa ya tiene agentes de IA conectados a herramientas por MCP y no sabrías responder hoy mismo cuántos servidores distintos son ni quién los aprobó, es exactamente lo que cubre una auditoría de ciberseguridad. Contáctanos antes de que lo descubras por un incidente, no después.

Preguntas frecuentes

¿Qué es MCP (Model Context Protocol)? Es un estándar abierto que permite que un agente de IA se conecte a herramientas y fuentes de datos externas (correo, CRM, bases de datos, repositorios de código) de forma uniforme, sin que cada integración se programe a medida. Lo usan, entre otros, Claude, ChatGPT y Gemini.

¿Un MCP Gateway es lo mismo que un firewall? No exactamente. Un firewall filtra tráfico de red en general; un MCP Gateway controla específicamente qué agente puede hablar con qué servidor MCP, con qué credenciales y qué herramientas puede invocar, y deja constancia de cada llamada — es un control de acceso y auditoría a nivel de protocolo, no de red.

¿Por qué el 73% de los servidores MCP tiene vulnerabilidades si el protocolo lo respaldan empresas serias? Porque el protocolo en sí no es el problema: lo son las implementaciones. Cualquiera puede publicar un servidor MCP, y la mayoría de los que están en uso hoy los ha escrito un desarrollador independiente o un equipo pequeño, sin el mismo proceso de revisión que pasaría un proveedor de software empresarial.

¿Cómo se sabe si un agente de IA ya está usando servidores MCP sin control en mi empresa? Revisando, servidor por servidor, a qué se conecta cada agente desplegado, con qué tipo de credencial y quién aprobó esa conexión. Si la respuesta a «¿quién aprobó esto?» no está clara, no hay gobierno real, haya o no un incidente todavía.

¿Esto afecta solo a empresas que desarrollan sus propios agentes de IA? No. Cualquier empresa que use un asistente de IA conectado a sus herramientas internas a través de MCP —aunque el agente lo haya montado un proveedor externo— depende de la seguridad de esos servidores. La pregunta que hay que hacerle a cualquier proveedor es la misma: qué servidores MCP usa, con qué autenticación, y quién los auditó.

Relacionado: esa misma pregunta hay que hacérsela antes a cualquier proveedor que vaya a tener acceso a tus sistemas, no solo a los que llegan vía MCP — lo tratamos en riesgo de proveedores con IA.