- Los servidores MCP conectan modelos de IA con sistemas críticos, pero operan con permisos amplios y suelen quedar fuera de los inventarios y evaluaciones de riesgo.
- Vulnerabilidades como CVE-2025-6514 en mcp-remote y casos como el Postmark MCP malicioso evidencian riesgos de RCE y robo masivo de correos vía cadena de suministro.
- La combinación de MCP, modelos de IA y shadow AI puede exponer datos sensibles a proveedores no verificados, por lo que la visibilidad, el gobierno y el enfoque zero trust son esenciales.
- Herramientas como Microsoft Defender y el servidor MCP de Microsoft Sentinel ayudan a descubrir, monitorizar y securizar el uso de MCP dentro de una estrategia de IA responsable y alineada con la regulación.
La adopción de servidores MCP y proveedores de modelos de IA se ha disparado en muy poco tiempo, y con ella también han crecido los riesgos de seguridad asociados a estos nuevos componentes que muchas empresas todavía ni siquiera tienen inventariados. Mientras los equipos se centran en ganar productividad con agentes y asistentes inteligentes, surgen vectores de ataque silenciosos que no pasan por las vulnerabilidades clásicas, pero que pueden acabar con un compromiso total del entorno.
En este contexto, ya no hablamos solo de fallos de software aislados, sino de un ecosistema MCP y de modelos de IA que puede convertirse en una cadena de suministro opaca, llena de servidores, herramientas y paquetes de terceros que operan con permisos de alto nivel. Desde vulnerabilidades críticas como CVE-2025-6514 en mcp-remote, hasta servidores MCP maliciosos capaces de robar miles de correos electrónicos al día, el panorama obliga a replantearse cómo entendemos la seguridad en la era de la IA.
Qué es MCP y por qué sus servidores son tan sensibles
El Protocolo de Contexto de Modelo (Model Context Protocol, MCP) se ha diseñado para que modelos de IA, agentes y herramientas puedan comunicarse de forma estándar con datos, aplicaciones y servicios. Los servidores MCP actúan como “puentes inteligentes” entre el modelo y los sistemas reales: bases de datos, plataformas de correo, aplicaciones internas, herramientas de seguridad, etc.
En la práctica, un servidor MCP permite que un asistente de IA pase de ser un simple generador de texto a un agente operativo con capacidad para ejecutar acciones en tiempo real: buscar registros en un data lake, recuperar correos electrónicos, realizar consultas SQL o lanzar flujos de trabajo de seguridad. Esta capa de contexto es la que desbloquea gran parte del potencial de la IA aplicada a negocio.
El problema es que, para ofrecer esa utilidad, estos servidores suelen operar con permisos muy amplios sobre sistemas críticos y datos sensibles. Y, a diferencia de otros activos, con frecuencia no aparecen en los inventarios clásicos, ni pasan por procesos formales de evaluación de riesgo de proveedores, ni cuentan con controles de auditoría consistentes.
Los proveedores de modelos de IA basados en SaaS, por su parte, exponen capacidades avanzadas a través de APIs sencillas, lo que facilita que equipos de desarrollo integren rápidamente inteligencia en sus aplicaciones sin grandes inversiones en infraestructura ni en perfiles altamente especializados de machine learning. Pero cuando se combinan con servidores MCP, el alcance de lo que puede hacer (o romper) un agente de IA se multiplica.
Vectores de ataque emergentes en servidores MCP
El auge de MCP ha dado pie a una serie de vectores de ataque específicos que no encajan del todo en los modelos tradicionales de amenaza. Algunos de los más relevantes que se están observando en la práctica ilustran hasta qué punto un servidor MCP comprometido puede convertirse en la puerta de entrada a toda la organización.
Uno de los riesgos más claros es el envenenamiento de herramientas: una herramienta anunciada como inocente (por ejemplo, una calculadora o un conector aparentemente banal) puede esconder funciones maliciosas que se activan cuando el agente de IA la invoca. El nombre, la descripción e incluso un uso superficial pueden parecer normales, pero internamente puede borrar datos, exfiltrar información o realizar cambios destructivos.
Otro vector peligroso son las actualizaciones tipo rug-pull. Una herramienta legítima y segura el lunes puede recibir una nueva versión el viernes que introduce código malicioso. Si nadie revisa el diff o firma el código, los agentes de IA seguirán confiando en esa herramienta y la usarán rutinariamente, permitiendo que el atacante borre información, robe credenciales o manipule datos sin que se detecte de inmediato.
Los ataques RADE (engaño del agente de recuperación) aprovechan agentes que consultan documentos públicos o repositorios de conocimiento. Un atacante puede ocultar instrucciones MCP dentro de un documento aparentemente inocuo, de manera que cuando el sistema de recuperación lo ingiere, el agente termina ejecutando comandos que el usuario no ha pedido conscientemente.
También se han visto escenarios de suplantación de servidor MCP: un atacante levanta un servidor que replica nombre, API y herramientas de uno popular (por ejemplo, el que integra GitHub, Jira u otro servicio habitual). Si un cliente MCP apunta por error al servidor fraudulento, el atacante podrá interceptar y apropiar todas las llamadas, con acceso a datos, tokens y operaciones.
Finalmente, con despliegues donde coexisten varios servidores MCP, es posible el sombreado entre servidores. En este caso, un solo servidor comprometido puede interceptar, redirigir o anular llamadas destinadas a otros servidores de confianza, manipular respuestas o colarse en cadenas de agentes, creando una especie de “hombre en el medio” dentro del propio ecosistema MCP.
Vulnerabilidad crítica en mcp-remote: CVE-2025-6514
Más allá de los vectores conceptuales, también han aparecido vulnerabilidades técnicas concretas, como el fallo crítico descubierto en el proyecto mcp-remote, un proxy open source utilizado para conectar clientes MCP con servidores remotos. Este componente se usa precisamente para simplificar la conexión entre asistentes de IA y servidores externos.
La vulnerabilidad, identificada como CVE-2025-6514 con una puntuación CVSS de 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), permite la inyección de comandos de sistema operativo al conectarse a un servidor MCP no confiable. El impacto potencial incluye ejecución remota de código (RCE) y el compromiso total del dispositivo donde se ejecuta mcp-remote.
El problema reside en la fase de autorización OAuth: un servidor malicioso puede enviar en el campo authorization_endpoint una URL específicamente manipulada. En Windows, esta URL se transforma de tal forma que la librería empleada por Node.js para abrirla termina ejecutando comandos de shell con parámetros arbitrarios. En macOS y Linux, el impacto se traduce en la ejecución de archivos arbitrarios, aunque con ciertas limitaciones en comparación con Windows.
En resumen, la forma en que Node.js convertía la URL y el uso de la librería open para gestionarla abría la puerta a que un servidor MCP malicioso desencadenara la ejecución de código no autorizado. El fallo afecta a todas las versiones de mcp-remote desde la 0.0.5 hasta la 0.1.15, por lo que la superficie de instalaciones potencialmente afectadas es amplia.
Las recomendaciones son claras: actualizar inmediatamente a la última versión de la biblioteca, evitar conectarse a servidores MCP no confiables y exigir siempre HTTPS para las comunicaciones. No se han documentado workarounds efectivos, por lo que la mitigación pasa necesariamente por el parcheo y la restricción de confianza hacia servidores remotos.
Robo masivo de correos: el caso del servidor Postmark MCP malicioso
La teoría sobre servidores MCP comprometidos se ha materializado de forma muy tangible con el hallazgo de un servidor MCP malicioso capaz de robar silenciosamente correos electrónicos confidenciales, sin necesidad de aprovechar vulnerabilidades tradicionales ni explotar errores de configuración en los servidores de correo.
En este caso, el ataque se centró en el paquete “Postmark MCP Server”, un componente muy utilizado que se descargaba alrededor de 1.500 veces por semana y formaba parte de cientos de flujos de trabajo de desarrolladores. El atacante tomó el código legítimo del repositorio oficial de GitHub, le añadió una única línea de código que reenviaba todos los correos procesados a un servidor bajo su control (giftshop.club) y lo publicó en npm bajo el mismo nombre.
Este movimiento convierte al ataque en un ejemplo de compromiso de la cadena de suministro: no hace falta “romper” nada, basta con que los desarrolladores o los agentes de IA instalen y utilicen el paquete desde la fuente manipulada. Como señalaba uno de los investigadores, el problema es que se confía ciegamente en un paquete que se ejecuta con permisos completos, sin que nadie revise en profundidad qué hace cada actualización.
Según los análisis, el servidor malicioso llegó a copiar entre 3.000 y 15.000 correos por día, que incluían facturas, memorandos internos y documentación sensible. Lo más preocupante es que este flujo de datos no era detectado por los mecanismos clásicos como los gateways de correo o las soluciones de prevención de fuga de datos (DLP), ya que la exfiltración se producía dentro del propio flujo de trabajo de la herramienta MCP.
Este caso deja claro que el verdadero peligro puede estar en los paquetes de la cadena de suministro software y no solo en los ataques externos directos. Un simple módulo npm, aparentemente inofensivo, puede convertirse en un canal de exfiltración masiva cuando se combina con asistentes de IA que operan sobre él miles de veces al día.
Ante esta situación, las recomendaciones emitidas incluyen eliminar de inmediato la versión 1.0.16 del paquete Postmark MCP Server, rotar todas las credenciales que pudieran haber sido expuestas, auditar todos los servidores MCP en uso para confirmar que proceden de repositorios oficiales, revisar el código fuente y monitorizar los cambios en cada actualización, así como establecer controles de seguridad específicos para estos servidores (inventario de activos, evaluación de riesgos y procesos formales de aprobación).
Riesgos de MCP en la empresa: shadow AI, fugas de datos y cadena de suministro
Más allá de casos concretos, el despliegue de MCP a escala empresarial conlleva una serie de riesgos estructurales. Entre ellos destaca el fenómeno de la shadow AI o uso no autorizado de herramientas de IA, donde equipos de ingeniería o de negocio integran servidores MCP o proveedores de modelos sin pasar por los canales oficiales de IT o seguridad.
En muchas organizaciones, un desarrollador puede reconfigurar un asistente de código o una herramienta interna para que apunte a un proveedor de modelos o un servidor MCP no aprobado. Esto puede suponer la exposición involuntaria de información sensible, incumplimiento de normativas de protección de datos o introducción de amenazas como prompt injections, shadowing de servidores y de herramientas, o cadenas de agentes maliciosas.
Además, MCP puede exponer datos delicados a proveedores de contexto que no han sido verificados, lo que abre la puerta a fugas de información, abusos en encadenamientos de agentes y ataques a la cadena de suministro. Todo ello suele ocurrir sin registros homogéneos ni controles centralizados, lo que dificulta su detección y respuesta.
La combinación de IA generativa, herramientas MCP y ecosistemas multicloud crea un entorno en el que la visibilidad se vuelve crítica para mantener la seguridad. Sin un inventario claro de qué servidores MCP existen, qué modelos se consumen y con qué datos se nutren, es prácticamente imposible evaluar el riesgo real y aplicar políticas coherentes.
Por eso, la gestión de MCP no puede tratarse como un detalle técnico más: debe integrarse en las estrategias de gobierno de datos, cumplimiento normativo y gestión de proveedores, incluyendo controles de acceso, segmentación de permisos, monitorización de tráfico y procesos de revisión de dependencias software y configurar el servidor para que sea seguro.
Por eso, la gestión de MCP no puede tratarse como un detalle técnico más: debe integrarse en las estrategias de gobierno de datos, cumplimiento normativo y gestión de proveedores, incluyendo controles de acceso, segmentación de permisos, monitorización de tráfico y procesos de revisión de dependencias software.
Cómo está respondiendo Microsoft Defender al reto de MCP y modelos de IA
Algunas soluciones de seguridad han empezado a adaptarse específicamente a este nuevo escenario. Microsoft Defender, por ejemplo, ha ampliado sus capacidades para proteger el uso de MCP y proveedores de modelos de IA en entornos empresariales, tanto a nivel de descubrimiento como de gobierno y protección.
Por un lado, Defender for Cloud ha incorporado visibilidad sobre contenedores que ejecutan MCP en infraestructuras multicloud como AWS, GCP y Azure. Esto permite identificar qué servidores MCP están desplegados, qué agentes los utilizan y detectar errores de configuración o vulnerabilidades en las aplicaciones asociadas.
Además, Microsoft Defender for Cloud Apps ha extendido su catálogo de aplicaciones en la nube para incluir proveedores de modelos de IA y servidores MCP, integrándolos en un inventario de más de 35.000 aplicaciones detectables. Gracias a ello, los equipos de seguridad pueden analizar logs de tráfico, ver qué servicios de IA se usan realmente y evaluar la postura de riesgo de cada uno.
Este catálogo no se limita a listar nombres: incorpora parámetros como prácticas de manejo de datos, métodos de autenticación y alcance de integración, lo que permite valorar con más precisión la exposición y las dependencias. Con la inclusión de categorías específicas para “Proveedor de Modelo de IA” y “Servidor MCP de IA”, se facilita el filtrado y la aplicación de políticas diferenciadas.
Si la organización aloja sus propios servidores MCP, la funcionalidad de Gestión de Postura de Seguridad de IA en Defender for Cloud ayuda a descubrir todos los servidores MCP desplegados, identificar configuraciones débiles y priorizar la remediación usando análisis de vías de ataque. En esencia, se trata de llevar al terreno de MCP las mismas prácticas de hardening y visibilidad que ya existen para otros servicios cloud.
Con estas capacidades, Microsoft pretende que los equipos de seguridad puedan descubrir, monitorizar y gobernar tanto las aplicaciones de IA generativa como los proveedores de modelos y servidores MCP, reduciendo así el riesgo de shadow AI y proporcionando mecanismos de control y cumplimiento en tiempo real.
El servidor MCP de Microsoft Sentinel y sus casos de uso
Dentro de este contexto, Microsoft ha desarrollado un servidor MCP específico para Microsoft Sentinel, su plataforma de gestión de eventos y seguridad (SIEM). Este servidor MCP está orientado a habilitar herramientas de seguridad avanzadas, como la búsqueda semántica en tablas del lago de datos de Sentinel mediante herramientas como search_tables.
La interfaz unificada que ofrece este servidor permite a agentes y herramientas de IA descubrir, mediante lenguaje natural, qué tablas son relevantes para una investigación, recuperar metadatos de esas tablas y entender el contexto de los datos de seguridad. También facilita el análisis de entidades para obtener veredictos y evaluaciones de amenaza, integrándose con flujos de trabajo de caza de amenazas e investigación de incidentes.
Este tipo de servidor MCP está especialmente pensado para roles de seguridad como analistas, investigadores y threat hunters, que buscan incorporar IA a sus tareas diarias sin perder la trazabilidad ni el control sobre los datos que consultan. No se trata de un asistente de propósito general, sino de un protocolo centrado en el dominio de seguridad.
Entre sus limitaciones, se encuentra precisamente su enfoque de dominio: el servidor está optimizado para consultas relacionadas con la búsqueda de tablas en el lago de datos de Sentinel. Peticiones ajenas a ese contexto pueden producir resultados vacíos o no relevantes. Además, la calidad de las respuestas depende del estado del propio lago de datos: si la información está desactualizada o incompleta, las conclusiones también lo estarán.
Otra limitación importante es la dependencia de complementos y de una configuración adecuada de las herramientas que lo consumen. Si los plug-ins o fuentes de datos no se configuran correctamente, la experiencia puede ser pobre o incluso engañosa, lo que subraya la necesidad de un despliegue cuidadoso y de buenas prácticas de operación.
IA responsable, cumplimiento normativo y MCP
El despliegue de servidores MCP en entornos sensibles como la seguridad corporativa va acompañado de compromisos explícitos de IA responsable y cumplimiento normativo. En el caso de Microsoft, se insiste en principios como equidad, fiabilidad y seguridad, privacidad, inclusión, transparencia y responsabilidad como guía del diseño de estos sistemas.
El servidor MCP de Microsoft Sentinel se construye bajo estos principios y en alineación con los requisitos de la Ley de IA de la Unión Europea, buscando no solo cumplir formalmente la regulación, sino también ayudar a los clientes a usar la IA de forma compatible con las normativas aplicables.
Para ello, se trabaja en estrecha colaboración con autoridades europeas para definir prácticas de aplicación efectivas y marcos internos de gobernanza, reforzando los estándares de IA responsable y elevando el nivel de preparación para escenarios de supervisión regulatoria más exigentes.
El desarrollo del servidor MCP de Sentinel, en conjunción con soluciones como Security Copilot, busca mantener al factor humano en el centro del proceso, con sistemas de seguridad adicionales como anotación de contenido dañino, supervisión operativa y mecanismos para mitigar errores o usos indebidos. Programas de acceso anticipado por invitación sirven además para recoger feedback y pulir el producto antes de un despliegue generalizado.
Esta aproximación reconoce que la IA responsable no es un estado final, sino un recorrido continuo de mejora, en el que cada iteración del sistema busca hacerlo más fiable y digno de confianza, incorporando lecciones aprendidas y comentarios de los usuarios.
Todo este ecosistema de vulnerabilidades técnicas, ataques a la cadena de suministro, shadow AI y respuestas defensivas muestra que los servidores MCP se han convertido en piezas clave, tanto para la productividad como para la superficie de ataque. Integrarlos con garantías exige actualizar las prácticas de seguridad tradicionales: inventariar servidores y proveedores de modelos, revisar paquetes y actualizaciones, limitar permisos, vigilar los flujos de datos y aplicar principios de zero trust incluso a los asistentes de IA. Solo así se puede aprovechar el enorme potencial de MCP sin dejar la puerta abierta a amenazas silenciosas que operan con permisos de “nivel dios” sobre la información más crítica de la organización.
