Protege tu sistema MCP: 11 riesgos habituales y cómo protegerse frente a ellos

Los riesgos de MCP se dividen, a grandes rasgos, en tres categorías: manipulación de LLM, seguridad de datos y accesos, y vulnerabilidades de infraestructura.

Como los servidores MCP suelen dar acceso a una amplia variedad de sistemas internos, el posible riesgo de seguridad es alto. Sin embargo, la probabilidad depende en gran medida de la configuración.

Hay muchas medidas que tanto particulares como empresas pueden tomar para garantizar la protección de sus sistemas, y los protocolos siempre deben ser proporcionales a las capacidades y los datos que podrían exponer los servidores MCP conectados.

¿Qué son MCP y la seguridad de MCP?

Model Context Protocol (MCP) es un estándar abierto creado por Anthropic para conectar aplicaciones basadas en LLM (o hosts) con sistemas externos.

Un sistema MCP tiene tres componentes principales: el host, el cliente y el servidor. El host, que suele ser un asistente de IA, se conecta a un servidor MCP externo a través de un cliente. A partir de ahí, puede enviar solicitudes para ejecutar funcionalidades externas (herramientas) u obtener datos (recursos) o prompts que añadir a la ventana de contexto del LLM.

Ampliar

La seguridad de MCP hace referencia a los protocolos que protegen las conexiones y los componentes de un sistema MCP. Existen varios retos clave exclusivos de MCP, como el hecho de que las aplicaciones de IA suelen tener capacidades agénticas y de que pueden incrustarse instrucciones maliciosas en los mensajes.

Los problemas ya conocidos que no son específicos de MCP, como la inyección de prompts, la autenticación débil y las integraciones de terceros inseguras, también plantean dificultades. Como cualquier sistema informático, MCP se basa en una combinación de protocolos de procedimiento, como usar solo servidores de confianza, y controles técnicos, como las pasarelas de API, para protegerse.

¿Qué gravedad tienen las amenazas de MCP?

MCP se ha convertido rápidamente en una tecnología de LLM popular, y muchas organizaciones y aplicaciones de consumo la utilizan. Como los servidores MCP son programas escritos en código, tienen vulnerabilidades como cualquier otra aplicación.

Sin embargo, cuando las organizaciones utilizan MCP en implementaciones controladas, por lo general es seguro. Hay una diferencia abismal entre crear un sistema con servidores de confianza y permisos verificados y conectar un agente autónomo a una docena de servidores sin verificar.

Amenaza n.º 1: Inyección indirecta de prompts

Un atacante puede colocar instrucciones dirigidas al LLM dentro de un documento, una página web o la salida de una herramienta que devuelva un servidor MCP. Si el host añade este material a la ventana de contexto, es posible que el LLM lo confunda con instrucciones auténticas.

Es más, estas instrucciones pueden parecer apropiadas a primera vista. Por ejemplo, un tique de soporte recuperado podría indicar al LLM que exporte registros confidenciales de clientes antes de generar una respuesta.

Cómo protegerse frente a la inyección indirecta de prompts

Las inyecciones de prompts suelen abordarse a nivel del host. El contenido externo debe etiquetarse como no fiable, y las solicitudes de información confidencial deben requerir la aprobación informada de una persona que supervise el proceso. También pueden resultar útiles las pruebas de seguridad que consisten en recurrir a documentos o datos maliciosos para ver cómo responden el host y el LLM.

Amenaza n.º 2: Envenenamiento de herramientas y rug pulls

En un ataque de envenenamiento de herramientas, se añade código malicioso a la descripción o al esquema de una herramienta MCP. Esto puede influir en el LLM durante la fase de descubrimiento, cuando el MCP expone por primera vez las herramientas disponibles.

Ampliar

Un rug pull es un tipo especial de envenenamiento de herramientas en el que se modifican metadatos aprobados. Esta forma de envenenamiento de herramientas puede cambiar la manera en que un modelo usa herramientas de confianza, en lugar de invocar directamente una herramienta maliciosa.

Cómo protegerse frente al envenenamiento de herramientas y los rug pulls

El host debe inspeccionar la definición completa de cada herramienta antes de usarla y compararla con una lista de herramientas de confianza aprobadas para detectar así cualquier cambio. Las comprobaciones de parámetros pueden ayudar a identificar posibles capacidades peligrosas y marcarlas.

Amenaza n.º 3: Permisos excesivos

Es habitual que los usuarios concedan a los servidores MCP y a los LLM conectados (a través del host) más permisos de los necesarios para una tarea. Por ejemplo, permisos de escritura cuando bastaría con permisos de solo lectura, o acceso completo a un sistema interno de archivos (como Google Drive).

Esta extensa proliferación de permisos puede aumentar el radio de impacto de otras vulnerabilidades, como las llamadas maliciosas a herramientas. Es habitual que los permisos «se vayan sumando» a medida que los usuarios conceden privilegios en el transcurso de su trabajo diario con herramientas de IA en una empresa (acumulación de privilegios).

Cómo protegerse frente a los permisos excesivos

La forma más directa de protegerse frente a este problema es restringir los permisos y los ámbitos de OAuth (lectura, escritura, acceso completo, etc.). Las aprobaciones de los usuarios, sobre todo para operaciones confidenciales, son una parte importante de ello, pero los permisos también deben controlarse a nivel del sistema (sistema operativo, host MCP y servidor).

Amenaza n.º 4: Autenticación y autorización débiles

La autenticación verifica la identidad de los usuarios o aplicaciones que se conectan a un servidor MCP. La autorización establece a qué herramientas y recursos pueden acceder.

Los servidores MCP mal configurados pueden aceptar solicitudes o tokens sin autenticar correctamente a los usuarios ni aplicar restricciones de acceso. Además, si la validación es débil, las credenciales robadas pueden permitir el acceso a actores malintencionados.

Cómo protegerse frente a la autenticación y la autorización débiles

La autenticación basada en OAuth para servidores MCP remotos, los tokens de corta duración y el control de acceso basado en roles (RBAS) son medidas que ayudan a mitigar la autorización débil. El acceso basado en roles es útil porque impide que los usuarios accedan a datos y herramientas más allá de sus permisos, aunque el propio servidor tenga acceso.

Amenaza n.º 5: Filtración y uso indebido de credenciales

Los servidores MCP utilizan habitualmente credenciales como claves de API y tokens de acceso de OAuth para conectarse a servicios externos. Si quedan expuestas o se usan indebidamente, los atacantes pueden acceder a datos y funcionalidades confidenciales.

Un ejemplo es el paso de tokens (token passthrough), en el que un servidor MCP reenvía un token de acceso a otro servicio sin verificar que realmente esté destinado al servicio receptor. Esto, a su vez, puede provocar filtraciones si el servicio receptor no cuenta con protecciones adecuadas.

Cómo protegerse frente a la filtración y el uso indebido de credenciales

Los tokens de corta duración y alcance limitado, junto con la rotación de credenciales, son eficaces para limitar hasta qué punto los actores malintencionados pueden usar los datos filtrados. Las claves de API y las credenciales siempre deben almacenarse de forma segura mediante un gestor de secretos.

Amenaza n.º 6: Ataques de suplente confundido

Un ataque de suplente confundido (confused deputy) se produce cuando un atacante engaña a una aplicación de confianza para que use sus permisos y realice una acción que no ha autorizado un usuario legítimo. En este caso, el servidor MCP es el suplente.

Ampliar

El atacante aprovechará una vulnerabilidad del servidor MCP (como verificaciones de OAuth débiles) para ejecutar un proceso malicioso, como una llamada a una herramienta o una recuperación de datos.

Cómo protegerse frente a los ataques de suplente confundido

La validación de la autorización, en la que se verifica que cada llamada a una herramienta pertenece a un usuario concreto, ayuda a limitar los ataques de suplente confundido. Además, las acciones confidenciales, como las exportaciones de datos, deben requerir una autorización explícita.

Amenaza n.º 7: Servidores maliciosos y dependencias comprometidas

Los servidores MCP pueden contener código malicioso (en esencia, son programas externos) o basarse en dependencias comprometidas, como bibliotecas de terceros. Se trata de un problema de la cadena de suministro de software, más que de un problema exclusivo de MCP.

Una forma sencilla en la que podría ocurrir es que un atacante distribuya una integración que parezca legítima. Una vez configurada, puede robar y reutilizar credenciales, acceder a datos confidenciales y ejecutar operaciones no autorizadas.

Cómo protegerse frente a los servidores maliciosos y las dependencias comprometidas

Instala servidores MCP solo de fuentes de confianza y verificadas. Si es posible, revisa su código y comprueba siempre las dependencias externas. Asegúrate de que los servidores se actualicen y se les apliquen parches con regularidad.

Amenaza n.º 8: Falsificación de solicitudes del lado del servidor (SSRF)

La falsificación de solicitudes del lado del servidor (SSRF) se produce cuando un atacante engaña a un servidor MCP para que envíe solicitudes de red a direcciones internas a las que el usuario no pretendía acceder.

Esto puede ocurrir cuando un servidor MCP expone una herramienta que obtiene información de una URL. Si un atacante puede influir en el parámetro de la URL, puede cambiarlo por la dirección de red que desee, como una API interna o un servicio en la nube. Esto puede provocar que se obtengan datos confidenciales y que, potencialmente, queden accesibles

Cómo protegerse frente a la falsificación de solicitudes del lado del servidor (SSRF)

Los servidores MCP siempre deben validar las URL, bloquear el acceso a direcciones de red internas restringidas e impedir el acceso de red saliente. Las redirecciones también deben seguir este protocolo.

Amenaza n.º 9: Secuestro de sesión

El secuestro de sesión consiste en que un atacante tome el control de una conexión activa entre un cliente MCP y un servidor.

Por ejemplo, podría robar un identificador de sesión de una aplicación MCP mal protegida (p. ej., un host o un servidor). Si el servidor MCP acepta este identificador, el atacante podría llamar a herramientas con los permisos legítimos del usuario.

Cómo protegerse frente a

El riesgo de secuestro de sesión puede reducirse con una verificación estricta de la identidad en todas las aplicaciones de un sistema MCP. El cifrado entre los clientes MCP y los servidores remotos también es fundamental para evitar que se descubran los identificadores de sesión.

Amenaza n.º 10: Ataques de confusión (mix-up)

En un ataque de confusión (mix-up), el atacante engaña a un cliente MCP para que envíe un código de autorización a un servidor de autorización malicioso situado entre el cliente y el servidor MCP. Un servidor de autorización es una aplicación que emite tokens de acceso de OAuth tras comprobar que el acceso solicitado está autorizado.

Ampliar

Si un host MCP se conecta a varios servicios, cada uno con un servidor de autorización distinto, un atacante podría controlar uno de ellos (quizá registrando un servicio malicioso) y hacer que el cliente envíe al servidor malicioso un código de autorización emitido por un servidor legítimo. Esta confusión puede permitir al atacante suplantar a la aplicación autorizada y acceder a servicios protegidos.

Cómo protegerse frente a los ataques de confusión

Los clientes MCP deben verificar la identidad del servidor de autorización durante todo el proceso de OAuth. En concreto, deben comparar el identificador del emisor del servidor (iss) con la identidad esperada y rechazar las discrepancias.

Amenaza n.º 11: Compromiso de servidores MCP locales

Muchos servidores MCP se ejecutan en el equipo local del usuario, que puede instalar el servidor de un tercero o crearlo por su cuenta. Si un atacante consigue comprometer este servidor MCP local, podría acceder a gran parte del sistema local.

Un atacante puede obtener acceso de varias formas. Puede distribuir un servidor malicioso disfrazado de integración legítima, modificar la configuración de un host MCP para que emita un comando malicioso o acceder a un servidor MCP que se ejecute en un entorno con controles de seguridad insuficientes, por ejemplo, mediante DNS rebinding, que engaña a un navegador para que envíe solicitudes a un servicio de localhost.

Cómo protegerse frente al compromiso de servidores MCP locales

El uso de entornos aislados y de protocolos de consentimiento estrictos es importante al trabajar con servidores MCP locales. Los servidores MCP solo deben instalarse desde proveedores de confianza, y los permisos del sistema operativo deben restringir a qué directorios pueden acceder.

Las vulnerabilidades de MCP suelen ser viejas amenazas con nuevo disfraz

Las vulnerabilidades de MCP suelen surgir de nuevas aplicaciones de riesgos y metodologías de ataque ya conocidos. MCP introduce nuevas formas de que los atacantes aprovechen estas vulnerabilidades mediante las interacciones entre los LLM, los servidores MCP y los servicios externos.

Por supuesto, existen amenazas específicas de MCP. Sin embargo, conviene tener en cuenta que los protocolos de seguridad estándar, como aplicar una autorización estricta, usar proveedores de confianza y protegerse frente a las inyecciones de prompts, contribuirán en gran medida a proteger cualquier implementación de MCP.