Servidores MCP: guía de seguridad esencial para CISOs

Tus desarrolladores están instalando servidores MCP en minutos, con un copia-pega. Tu equipo de seguridad probablemente no tiene inventario de ellos. Eso tiene que cambiar.

Qué es un servidor MCP — y por qué es diferente a todo lo anterior

MCP (Model Context Protocol) es el USB-C de los agentes de IA. Es un estándar que permite a los modelos de lenguaje — Claude, GPT, Gemini, o lo que corra dentro de tu centro de datos — conectarse con herramientas y fuentes de datos sin necesidad de código de integración personalizado para cada una.

Los sistemas más comunes a los que se conectan: repositorios de código (GitHub, GitLab), bases de datos (Postgres, MySQL, Snowflake), proveedores cloud (AWS, Azure, GCP), herramientas de gestión (Jira, Linear), plataformas de observabilidad (Grafana, Datadog), sistemas de pago (Stripe) y sistemas de ficheros internos. Un único servidor MCP puede conectar varios de estos a la vez.

Lo que lo diferencia de cualquier proveedor SaaS que hayas evaluado antes: un servidor MCP es una superficie de acción, no una fuente de datos pasiva. Cuando un desarrollador instala uno, está dando a un modelo de lenguaje acceso en tiempo real a un sistema — un acceso que puede leer, escribir, llamar a APIs y encadenar acciones sin necesariamente pedir confirmación en cada paso.

Tres propiedades lo hacen especialmente peligroso:

• Acceso directo al sistema. Los servidores MCP operan con la identidad y credenciales del usuario que los ejecuta — a menudo un desarrollador con acceso amplio a producción. Sin intermediario, sin limitador de velocidad, sin aprobación humana por defecto.
• Definiciones de herramientas dinámicas. Las capacidades pueden cambiar después de la instalación. Una herramienta que parecía inofensiva el día 1 puede añadir silenciosamente una función enviar_email el día 7. Tus revisiones trimestrales de proveedores no detectarán este cambio.
• Ejecución mediada por el LLM. El modelo decide cuándo y cómo invocar cada herramienta basándose en instrucciones en lenguaje natural — algunas de las cuales pueden provenir de documentos no confiables. Las descripciones de las herramientas son visibles para el modelo pero invisibles para el usuario final, lo que las convierte en un lugar perfecto para ataques de inyección de instrucciones.

Tres riesgos para explicar al consejo de administración

Exfiltración de datos. Un agente de IA puede recibir instrucciones — a través de un documento que lee, un ticket que procesa, un repositorio que indexa — para copiar datos silenciosamente a donde no debería. En mayo de 2025, Invariant Labs documentó un ataque de inyección en el servidor MCP de GitHub: contenido malicioso en un issue público convenció a un agente para filtrar el contenido de repositorios privados (incluyendo datos salariales) en un nuevo pull request público. Impacto: alto. Detección: difícil.

Sustitución en la cadena de suministro. Aprobaste una herramienta el lunes. El viernes cambió silenciosamente lo que hace — y nadie en tu equipo fue notificado. Investigadores de Knostic encontraron 1.862 servidores MCP expuestos en internet público sin ninguna autenticación a finales de 2025. Astrix Security reportó que el 43% de los servidores MCP de código abierto contienen vulnerabilidades de inyección de comandos. El CVE-2025-6514 por sí solo afectó a más de 437.000 entornos de desarrollo.

Exposición regulatoria. DORA, NIS2 y la Ley de IA de la UE exigen demostrar control sobre las herramientas de terceros conectadas a procesos de negocio críticos. Un servidor MCP no gestionado es, por definición, un tercero ICT no gestionado — un hallazgo que ningún auditor pasará por alto. El informe de IBM sobre el coste de las brechas de datos de 2025 cifra el sobrecoste de la “IA en la sombra” en 670.000 dólares adicionales respecto a una brecha estándar. Solo el 17% de las organizaciones monitoriza actualmente las interacciones entre agentes.

El patrón común en los tres casos: el atacante no necesita vulnerar tu perímetro. Las instrucciones maliciosas llegan como contenido ordinario por canales legítimos y son ejecutadas por herramientas que tu organización instaló voluntariamente. El radio de impacto lo definen exclusivamente los privilegios que concediste.

Qué preguntar antes de aprobar cualquier servidor MCP

Tu programa de gestión de riesgos de terceros asume un proveedor SaaS, un contrato y un ciclo de revisión trimestral. Los servidores MCP rompen las tres premisas. Esto es lo que realmente importa:

Procedencia y cadena de suministro

• ¿Quién lo mantiene, y está cada versión vinculada a un hash criptográfico?
• ¿Ha sido analizado de forma independiente — SAST, análisis de contaminación, escaneo de la cadena de suministro?
• ¿Cuál es la política de divulgación de vulnerabilidades y el SLA de parches?

Acceso y permisos

• ¿A qué sistemas puede acceder? Enuméralos. “Depende de la configuración” no es una respuesta válida.
• ¿Necesita credenciales persistentes o puede usar tokens de corta duración y alcance limitado?
• ¿Se puede restringir el acceso por usuario o por sesión?

Comportamiento en ejecución

• ¿Pueden cambiar las definiciones de herramientas tras la instalación? Si es así, ¿hay detección automática de desviaciones?
• ¿Realiza llamadas de red salientes, y a qué endpoints específicos?
• ¿Puede iniciar acciones de escritura o destructivas sin confirmación explícita del usuario?

Gobernanza y cumplimiento

• ¿Genera registros de auditoría estructurados aptos para el reporte DORA?
• ¿Está documentada la residencia de datos para flujos de datos de la UE?
• ¿Hay un contacto de seguridad identificado con un security.txt público?

Un servidor que no puede responder a todo esto no debería aprobarse para ningún sistema que maneje datos regulados, credenciales de producción o comunicaciones con clientes. Y esta lista no caduca — repítela en cada actualización de versión relevante.

Un plan de 90 días para pasar de cero a defensible

Solo el 38% de las organizaciones monitoriza actualmente el tráfico de IA de extremo a extremo. Aquí tienes un plan concreto para tomar el control.

Días 1-30 — Descubrimiento. Emite una política escrita: ningún servidor MCP nuevo conectado a producción durante esta fase. Revisa las herramientas de desarrollo (Cursor, Claude Desktop, VS Code Copilot, Cline, agentes personalizados). Añade los servidores MCP a tu CMDB como una nueva clase de activo, vinculados al usuario que los instaló y al proceso de negocio. Cruza con los registros de tráfico saliente para detectar servidores no registrados. Entregable: inventario validado con propietario, editor, versión y etiqueta de clasificación de datos por entrada.

Días 31-60 — Análisis. Ejecuta un proceso de certificación contra cada servidor del inventario: SAST, análisis de contaminación, cadena de suministro, escaneo de secretos. Puntúa cada uno. Clasifica por radio de impacto — Nivel 1 (producción + datos regulados), Nivel 2 (producción), Nivel 3 (solo sandbox). Entregable: catálogo con puntuación de riesgo y plan de remediación para todo lo que esté por debajo de una certificación básica.

Días 61-90 — Aplicación. Despliega una capa de ejecución que valide hashes criptográficos y nivel de certificación antes de que cualquier herramienta sea expuesta a un modelo. Conecta los eventos de ejecución a tu SIEM para el reporte de incidentes conforme a DORA. Define umbrales de alerta para nuevos endpoints, nuevas definiciones de herramientas y anomalías en el volumen de datos salientes. Entregable: documento de política + aplicación en tiempo de ejecución + informe de 90 días para el consejo que demuestre cobertura de controles.

Lo que debes llevarte de aquí

El centro de gravedad del riesgo MCP no es la seguridad de red — son el principio de mínimo privilegio, la procedencia y la atestación en tiempo de ejecución. Una organización que controla esos tres aspectos puede gestionar el resto. La que ignora alguno de ellos tendrá muy difícil explicar a un regulador por qué no sabía qué estaban haciendo sus agentes de IA.