Seguridad MCP: riesgos del Model Context Protocol y buenas prácticas

La seguridad MCP consiste en controlar qué puede hacer una IA cuando la conectas, mediante el Model Context Protocol, a tus aplicaciones, tus archivos y tus datos. MCP facilita mucho la integración, pero cada servidor que añades es código de terceros que el modelo puede invocar y que suele tener acceso a credenciales. Aquí tienes los riesgos documentados, lo que exige la especificación oficial y los controles operativos que aplicamos.

Qué es MCP y por qué importa su seguridad

El Model Context Protocol (MCP) es un protocolo abierto que estandariza cómo una aplicación de IA se conecta con fuentes de datos y herramientas externas. Funciona con tres piezas: el host (la aplicación de IA, por ejemplo un asistente de escritorio o un agente), los clientes (los conectores que viven dentro del host) y los servidores, que ofrecen recursos (datos y contexto), prompts (plantillas) y herramientas (funciones que el modelo puede ejecutar). Es la pieza que permite que un agente de IA consulte tu ERP, lea un repositorio o cree una incidencia sin una integración a medida para cada caso.

La especificación lo dice sin rodeos: MCP habilita «acceso arbitrario a datos y rutas de ejecución de código», y eso exige que quien lo implementa trate con cuidado la seguridad. El protocolo define principios, pero reconoce que no puede imponerlos por sí mismo: el consentimiento, la autorización y los controles de acceso los tiene que construir cada aplicación.

Los riesgos de seguridad MCP documentados

Los riesgos de MCP combinan un modelo que obedece instrucciones en lenguaje natural, servidores de procedencia variable y credenciales con acceso real. Estos son los descritos en la especificación y en investigaciones publicadas.

Servidores MCP de terceros no confiables

Un servidor MCP es software que se ejecuta con acceso a tus datos o a tu equipo. La especificación advierte de que las herramientas «representan ejecución arbitraria de código» y que las descripciones de su comportamiento deben considerarse no confiables salvo que procedan de un servidor de confianza. Instalar un servidor de un repositorio público sin revisar es instalar software desconocido que, además, el modelo invocará solo.

Envenenamiento de descripciones de herramientas (tool poisoning)

El modelo decide qué herramienta usar leyendo su nombre y su descripción. Invariant Labs publicó en 2025 un ataque que aprovecha esto: una herramienta que en apariencia solo suma dos números incluía en su descripción instrucciones ocultas para leer el archivo de configuración MCP del cliente y la clave SSH privada del usuario, y enviarlos al servidor a través de un parámetro sin uso. En su prueba con un agente de programación, el agente leyó los archivos y los envió, y el diálogo de confirmación no mostraba los argumentos sensibles.

Es una variante de prompt injection indirecta: el texto malicioso no lo escribe el usuario, llega por un canal que el modelo trata como información de contexto. La misma investigación describe el shadowing: la descripción de una herramienta maliciosa cambia cómo el agente usa otra herramienta legítima de un servidor distinto, por ejemplo para redirigir correos a otra dirección, sin que la herramienta maliciosa llegue a invocarse.

Actualizaciones maliciosas (rug pull)

Un servidor puede comportarse bien cuando lo apruebas y cambiar después. Invariant Labs lo llama rug pull: el servidor modifica la descripción de sus herramientas tras la instalación e introduce instrucciones maliciosas cuando ya tiene la confianza del usuario, igual que una actualización maliciosa de un paquete de software. El protocolo permite que la lista de herramientas cambie en caliente, así que hay que vigilar esos cambios.

El «confused deputy» en servidores proxy

El problema del confused deputy aparece cuando un servidor MCP actúa de intermediario ante una API de terceros (un proxy) y usa un identificador de cliente OAuth fijo para todos los usuarios. Según las «Security Best Practices» oficiales, si además permite el registro dinámico de clientes y el servidor de autorización de terceros guarda una cookie de consentimiento, un atacante puede registrar un cliente malicioso, enviar un enlace a la víctima y obtener un código de autorización sin que esta vea la pantalla de consentimiento. El resultado: el atacante accede a la API de terceros suplantando al usuario. La mitigación obligatoria es pedir consentimiento por cada cliente en el propio servidor MCP antes de redirigir al tercero, validar exactamente las URL de redirección y usar el parámetro state correctamente.

Robo y abuso de tokens

Los tokens de acceso son la llave de los sistemas conectados. La especificación de autorización advierte de que un atacante que obtenga tokens guardados por el cliente, o cacheados o registrados en el servidor, puede acceder a los recursos con peticiones que parecen legítimas. Un caso particular es el token passthrough: un servidor que acepta tokens emitidos para otro servicio y los reenvía tal cual a la API de destino. Esto rompe la trazabilidad, permite saltarse controles y convierte al servidor en un proxy para exfiltrar datos con un token robado. La especificación lo prohíbe expresamente.

Credenciales expuestas en la configuración local

Muchos servidores MCP se ejecutan en local mediante el transporte stdio, y la especificación indica que, en ese caso, las credenciales se obtienen del entorno en lugar de mediante OAuth. En la práctica, eso hace que claves de API y tokens acaben escritos en archivos de configuración del cliente o en variables de entorno del equipo. Si un servidor malicioso o un ataque de tool poisoning logra que el modelo lea esos archivos, como en el ejemplo anterior, se lleva las credenciales de todos los demás servidores. Si te preocupa este punto, lo desarrollamos en credenciales y agentes de IA.

Servidores con permisos excesivos

Un servidor que solo necesita leer el calendario no debería poder borrar archivos ni enviar correos. La guía oficial describe el riesgo de tokens con alcances amplios (del tipo files:*, db:* o admin:*): si se roban, permiten acceso lateral a datos y encadenar privilegios, y revocarlos rompe todos los flujos a la vez. OWASP recoge el mismo problema como «agencia excesiva» (LLM06): funciones, permisos o autonomía que van más allá de lo que la tarea necesita.

Ejecución de comandos en el equipo local

La configuración de un servidor local incluye el comando que lo arranca, y ese comando se ejecuta con los privilegios del usuario. Las «Security Best Practices» muestran ejemplos de comandos de arranque maliciosos que instalan un paquete y, a la vez, envían la clave SSH privada a un servidor externo. Los riesgos que enumeran son ejecución arbitraria de código, falta de visibilidad sobre lo que se ejecuta, comandos ofuscados para parecer legítimos y pérdida de datos.

Qué exige la especificación oficial de MCP

La especificación de MCP fija un marco de seguridad claro, aunque su cumplimiento depende de cada implementación. Estos son los puntos clave para quien decide qué se conecta en una empresa.

Consentimiento y control del usuario. Los usuarios deben consentir de forma explícita y entender todo acceso a datos y toda operación. El host debe obtener consentimiento antes de exponer datos del usuario a un servidor y antes de invocar cualquier herramienta. En la página de herramientas, la especificación recomienda que siempre haya una persona en el circuito con capacidad de denegar invocaciones, que la interfaz muestre qué herramientas están expuestas y que se pida confirmación en operaciones sensibles, enseñando los argumentos antes de llamar al servidor.

Autorización basada en OAuth 2.1. La autorización es opcional, pero los servidores accesibles por HTTP deberían seguir el marco de la especificación, basado en OAuth 2.1. Sus requisitos principales:

• El cliente debe indicar para qué servidor pide el token (Resource Indicators, RFC 8707) y el servidor debe validar que el token se emitió para él.
• Los servidores no deben aceptar ni reenviar tokens emitidos para otros servicios.
• PKCE obligatorio para proteger los códigos de autorización, HTTPS en los endpoints y URL de redirección registradas y validadas de forma exacta.
• Almacenamiento seguro de tokens y, según la especificación, tokens de acceso de vida corta para limitar el daño si se filtran.

Mínimo privilegio en los alcances. La guía oficial propone empezar con un conjunto mínimo de permisos de solo lectura y elevarlos de forma incremental cuando se intenta una operación privilegiada, en lugar de pedir todo de entrada. Entre los errores comunes cita los alcances comodín («*», «all», «full-access») y agrupar permisos que no tienen relación.

Controles en las herramientas. Los servidores deben validar todas las entradas, aplicar controles de acceso, limitar la frecuencia de invocaciones y sanear las salidas. Los clientes deberían validar los resultados antes de pasarlos al modelo y registrar el uso de herramientas.

Servidores locales con consentimiento previo. Si un cliente permite instalar un servidor local con un clic, debe mostrar el comando exacto que se va a ejecutar, sin recortar, advertir de que es una operación peligrosa y pedir aprobación explícita. Además, se recomienda ejecutar los servidores en un entorno aislado con privilegios mínimos.

Buenas prácticas operativas para usar MCP en la empresa

La especificación cubre el protocolo; la seguridad del día a día depende de cómo gobiernas los servidores que usa tu organización. Estas son las prácticas que recomendamos:

1. Inventario y aprobación de servidores. Lista de servidores permitidos, con responsable, finalidad, datos a los que acceden y fecha de revisión. Todo lo que no está en la lista no se conecta. Sin este control, MCP se convierte en otra vía de shadow AI en la empresa.
2. Versiones fijadas y revisión de cambios. Nada de instalar «la última versión» de forma automática. Se fija la versión, se revisa cada actualización y se comparan las descripciones de las herramientas entre versiones para detectar un rug pull.
3. Revisión de código y procedencia. Antes de aprobar un servidor se revisa su código o, como mínimo, quién lo mantiene, qué dependencias usa y qué permisos pide. En integraciones críticas, suele compensar un servidor propio.
4. Permisos mínimos y cuentas dedicadas. Cada servidor usa credenciales propias, con el menor alcance posible: solo lectura si basta, acceso a una carpeta y no a todo el disco, una cuenta de servicio y no la del director. La autorización real se aplica en el sistema de destino, no en lo que el modelo decida.
5. Aislamiento. Servidores locales en contenedores o entornos restringidos, sin acceso a la carpeta personal ni a claves SSH, y con la salida a red limitada a los destinos necesarios.
6. Confirmación humana en acciones sensibles. Enviar, borrar, pagar o modificar datos maestros requiere aprobación explícita, mostrando los argumentos completos. El diseño de este control forma parte de lo que llamamos el harness de un agente de IA.
7. Registros y alertas. Se registra qué herramienta se invocó, con qué argumentos, por qué usuario y con qué resultado, sin guardar secretos en los logs. Así se investigan incidentes y se detectan patrones raros.
8. Pruebas de ataque. Antes de pasar a producción, se prueban descripciones envenenadas, documentos con instrucciones ocultas y abusos de permisos. Lo explicamos en red teaming de IA, y el marco general de riesgos está en nuestro resumen del OWASP Top 10 para LLM.

Checklist rápido antes de conectar un servidor MCP

Antes de dar de alta un servidor MCP en tu empresa, comprueba al menos esto:

Cómo te ayudamos en Hive Mind Solutions

En Hive Mind Solutions integramos IA con ERP, CRM y otros sistemas, también mediante MCP, y lo hacemos con seguridad por diseño: servidores propios o revisados, permisos mínimos, aislamiento, confirmación humana en acciones sensibles y registros auditables. Es el mismo enfoque que aplicamos en nuestro RAG propio, que funciona en grupos de residencias líderes en España, con todo alojado en la UE y cumpliendo el RGPD.

Si ya usas MCP o quieres conectar tus agentes a sistemas internos, revisamos tu arquitectura y te proponemos controles concretos; y si los datos son especialmente sensibles, montamos una IA privada para empresas en infraestructura dedicada. Conoce nuestro servicio de seguridad y cumplimiento en IA, mira cómo desarrollamos agentes de IA para empresas o cuéntanos tu caso: trabajamos en remoto con empresas de toda España, con soluciones para todos los presupuestos y precios muy difíciles de batir.