Protege tu sistema MCP: 11 riesgos comunes y cómo protegerte contra ellos

Los riesgos de MCP se dividen, en términos generales, en tres categorías: manipulación del LLM, seguridad de datos y accesos, y vulnerabilidades de infraestructura.

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

Las personas y las empresas pueden tomar muchas medidas para garantizar que sus sistemas estén protegidos, y los protocolos siempre deben ser proporcionales a las capacidades y los datos que podrían exponer los servidores MCP conectados.

¿Qué es MCP y qué es la seguridad de MCP?

Model Context Protocol (MCP) es un estándar abierto creado por Anthropic para conectar apps 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. Luego puede enviar solicitudes para ejecutar funciones externas (herramientas) u obtener datos (recursos) o prompts para agregarlos a la ventana de contexto del LLM.

Ampliar

La seguridad de MCP se refiere a los protocolos que protegen las conexiones y los componentes de un sistema MCP. Hay varios desafíos clave exclusivos de MCP, como el hecho de que las apps de IA suelen tener capacidades agénticas y de que se pueden incrustar instrucciones maliciosas en los mensajes.

Los problemas ya conocidos que no son exclusivos de MCP, como la inyección de prompts, la autenticación débil y las integraciones inseguras de terceros, también representan un problema. Como cualquier sistema informático, MCP se protege con una combinación de protocolos de procedimiento, como usar solo servidores de confianza, y controles técnicos, como las puertas de enlace de API.

¿Qué tan graves son las amenazas de MCP?

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

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

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 el resultado de una herramienta que devuelve un servidor MCP. Si el host agrega este material a la ventana de contexto, es posible que el LLM lo confunda con instrucciones genuinas.

Además, estas instrucciones pueden parecer apropiadas a simple vista. Por ejemplo, un ticket de soporte recuperado podría indicarle al LLM que exporte registros confidenciales de clientes antes de generar una respuesta.

Cómo protegerse contra la inyección indirecta de prompts

Por lo general, las inyecciones de prompts deben abordarse a nivel del host. El contenido externo debe etiquetarse como no confiable, y las solicitudes de información confidencial deben requerir la aprobación informada de una persona que supervise el proceso (human in the loop). También pueden ser útiles las pruebas de seguridad que consisten en invocar 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 agrega 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 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 podría cambiar la manera en que un modelo usa herramientas de confianza, en lugar de invocar directamente una herramienta maliciosa.

Cómo protegerse contra el 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 cualquier cambio. Las verificaciones de parámetros pueden ayudar a identificar posibles capacidades peligrosas y marcarlas.

Amenaza n.º 3: Permisos excesivos

Es común que los usuarios otorguen 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 acumulación excesiva de permisos puede ampliar el alcance del daño de otras vulnerabilidades, como las llamadas maliciosas a herramientas. Es común que los permisos se vayan “sumando” a medida que los usuarios otorgan privilegios durante su trabajo diario con herramientas de IA en una empresa (acumulación de privilegios).

Cómo protegerse contra los permisos excesivos

La forma más directa de protegerse contra este problema es restringir los permisos y los alcances de OAuth (lectura, escritura, acceso completo, etc.). Las aprobaciones de los usuarios, sobre todo para operaciones confidenciales, son una parte importante de esto, 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 las aplicaciones que se conectan a un servidor MCP. La autorización determina 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 que actores maliciosos obtengan acceso.

Cómo protegerse contra 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 una autorización débil. El acceso basado en roles es útil porque impide que los usuarios accedan a datos y herramientas que exceden sus permisos, incluso si el propio servidor tiene acceso.

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

Los servidores MCP usan habitualmente credenciales como claves de API y tokens de acceso de OAuth para conectarse a servicios externos. Si estas se exponen o se usan indebidamente, los atacantes pueden obtener acceso a datos y funciones confidenciales.

Un ejemplo es el paso directo 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 tiene protecciones adecuadas.

Cómo protegerse contra 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 en qué medida los actores maliciosos pueden usar los datos filtrados. Las claves de API y las credenciales siempre deben almacenarse de forma segura con un gestor de secretos.

Amenaza n.º 6: Ataques de suplente confundido (confused deputy)

Un ataque de suplente confundido ocurre cuando un atacante engaña a una aplicación de confianza para que use sus permisos y realice una acción que un usuario legítimo no autorizó. 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 contra 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 específico, 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 depender de dependencias comprometidas, como bibliotecas de terceros. Este es un problema de la cadena de suministro de software, más que un problema exclusivo de MCP.

Una forma sencilla en que esto 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 contra servidores maliciosos y dependencias comprometidas

Instala servidores MCP solo de fuentes confiables y verificadas. Si es posible, revisa su código y siempre verifica las dependencias externas. Asegúrate de que los servidores se actualicen y reciban 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) ocurre 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 tenía intención de 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 contra 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 ocurre cuando un atacante toma 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 contra

El riesgo de secuestro de sesión se puede reducir con una verificación estricta de identidad en todas las aplicaciones de un sistema MCP. El cifrado entre los clientes MCP y los servidores remotos también es esencial 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, 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 que se ubica entre el cliente y el servidor MCP. Un servidor de autorización es una aplicación que emite tokens de acceso de OAuth después de 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 (quizás 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 que el atacante se haga pasar por la aplicación autorizada y obtenga acceso a servicios protegidos.

Cómo protegerse contra 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 la máquina local del usuario, quien puede instalar el servidor de un tercero o crearlo por su cuenta. Si un atacante logra comprometer este servidor MCP local, podría obtener acceso 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 ejecuta 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 contra el compromiso de servidores MCP locales

Los entornos aislados (sandboxing) y los protocolos estrictos de consentimiento son importantes al usar 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 amenazas conocidas con una nueva cara

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 a través de las interacciones entre los LLM, los servidores MCP y los servicios externos.

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