Seguridad MCP: la pregunta no es qué ataques existen, sino dónde deben estar las defensas

¿Qué es esto?

MCP-DPT es una taxonomía de ubicación de defensas para el Model Context Protocol, publicada en arXiv (2604.07551) el 8 de abril de 2026. La mayoría del trabajo sobre seguridad de MCP ha sido hasta ahora centrado en el ataque: describe cómo funcionan el tool poisoning, los rug pulls o el tool shadowing y con qué frecuencia tienen éxito. MCP-DPT plantea una pregunta distinta y más operativa: dado el diseño multiparte y de confianza distribuida de MCP, ¿dónde debe aplicarse cada defensa y qué actor es responsable de ella?

El hallazgo central del artículo, tras mapear las defensas académicas e industriales existentes, es contundente: la protección es «desigual y predominantemente centrada en la herramienta, con brechas persistentes en las capas de orquestación del host, transporte y cadena de suministro». Es decir, el campo ha acumulado mitigaciones en la capa más fácil de razonar —la herramienta— mientras que las capas estructuralmente críticas quedan poco defendidas. Los autores sostienen que estas brechas son estructurales —un desajuste arquitectónico— y no fallos de implementación aislados. Esto da continuidad a una línea de trabajo sobre amenazas a MCP que incluye los vectores de ataque vía sampling de MCP de Unit 42 (diciembre de 2025), las consideraciones de diseño de seguridad de MCP de la NSA y la taxonomía de amenazas MCP-38.

Cómo funciona

MCP es un protocolo host–cliente–servidor: una aplicación host orquesta un LLM, un cliente MCP habla el protocolo y servidores MCP operados de forma independiente exponen herramientas. MCP-DPT lo descompone en seis capas, cada una una frontera de confianza propiedad de un actor distinto:

1. Proveedor del modelo / Alineamiento del LLM — el comportamiento de rechazo y razonamiento del propio modelo.
2. Host / Aplicación MCP — orquestación, solicitudes de aprobación, ensamblaje del contexto.
3. Cliente / SDK MCP — análisis del protocolo, gestión de parámetros, estado de sesión.
4. Servidor MCP / Ejecución de herramientas — donde el código de la herramienta se ejecuta realmente.
5. Transporte / Red — el canal: autenticación, vinculación de sesión, protección contra repetición y manipulación.
6. Registro / Marketplace y cadena de suministro — descubrimiento, publicación, actualizaciones, nomenclatura.

Para cada ataque, el artículo identifica una capa de defensa primaria —«la primera frontera arquitectónica donde puede aplicarse una prevención significativa con autoridad y visibilidad suficientes»— y una capa secundaria de respaldo. Si un solo control nunca basta es por la propia forma del protocolo: un ataque puede entrar en una capa pero solo volverse observable o detenible en otra. Un registro solo puede inspeccionar metadatos estáticos en el momento del envío, pero el comportamiento de una herramienta maliciosa puede manifestarse únicamente en tiempo de ejecución, dentro del host. Defender solo la herramienta deja, por tanto, una ventana abierta en cada otra frontera.

Cuando los autores categorizan después las defensas reales (estáticas/preejecución, en tiempo de ejecución/conductuales, de aislamiento/arquitectura y a nivel de decisión) y revisan el utillaje desplegado, el mapa de cobertura resulta desequilibrado: las medidas se concentran en la inspección de herramientas y prompts, mientras que el transporte, la orquestación del host y la gobernanza de registro/cadena de suministro son escasas. No hace falta ningún exploit ni payload para ver la consecuencia: es una brecha de cobertura, no un ataque nuevo.

Por qué importa

Si ejecuta agentes sobre MCP, la lección práctica es que comprar un escáner de herramientas no es una estrategia de seguridad de MCP. Un escáner que inspecciona las descripciones de herramientas en la instalación no hace nada frente a un transporte sin vinculación de sesión, un host que aprueba automáticamente las llamadas a herramientas o un registro que permite a un atacante ocupar un nombre de servidor y luego enviar una actualización maliciosa (un «rug pull»). Son actores y capas diferentes.

El encuadre «estructural, no accidental» también ajusta las expectativas. Como ningún actor controla toda la pila de MCP, la seguridad es necesariamente un problema de responsabilidad compartida —más cercano al IAM en la nube que a parchear una biblioteca—. Los equipos que asumen que el protocolo o un único proveedor «se ocupa de la seguridad» son precisamente los que el análisis de cobertura predice como expuestos en las capas de host, transporte y cadena de suministro.

Defensas

Use el modelo por capas como una lista de verificación y coloque cada control en su punto de aplicación primario en lugar de esperar que la capa de herramienta lo atrape todo.

• Orquestación del host (la capa más desatendida). Exija aprobación humana explícita para las llamadas a herramientas de alto impacto, aplique mínimo privilegio por herramienta y aísle la salida de herramienta no confiable de las instrucciones de confianza en el contexto. No apruebe automáticamente.
• Transporte / red. Use canales autenticados y con integridad protegida, con vinculación de sesión y protección contra repetición. Trate «MCP supone un canal confiable» como una vulnerabilidad, no como una suposición.
• Registro / cadena de suministro. Fije identidades y versiones de servidores, verifique la procedencia y reevalúe las herramientas en cada actualización —no solo en la primera instalación— para detectar rug pulls y ocupación de nombres. La revisión de metadatos estáticos en el envío es necesaria pero no suficiente.
• Servidor / ejecución de herramientas. Aísle la ejecución de herramientas en sandbox, limite el acceso al sistema de archivos y la salida de red, y valide los parámetros contra un esquema antes de ejecutar.
• Defensa en profundidad, por diseño. Para cada ataque que le preocupe, pregunte: ¿cuál es la primera capa capaz de detenerlo con suficiente autoridad y cuál es la de respaldo? Asigne un responsable a cada una. Un control que solo se activa cuando el daño ya está aguas abajo es una defensa secundaria, no primaria.

Estado

Capa	Actor típico	Cobertura según MCP-DPT
Proveedor del modelo / alineamiento	Proveedor del modelo	Parcial (solo rechazos)
Host / aplicación MCP	Integrador	Desprotegida
Cliente / SDK MCP	Mantenedor del SDK	Desigual
Servidor MCP / ejecución de herramientas	Autor de la herramienta	Sobrerrepresentada (centrada en herramienta)
Transporte / red	Integrador / infraestructura	Desprotegida
Registro / cadena de suministro	Ecosistema / registro	Desprotegida

El artículo es una taxonomía y un análisis de cobertura, no una divulgación de vulnerabilidad: no hay nada que parchear ni payload que retener. Su valor está en el reencuadre: las debilidades recurrentes de MCP se leen mejor como defensas mal ubicadas, y la solución es aplicar cada control en la capa que realmente es su propietaria. Publicado el 8 de abril de 2026; las clases de ataque que organiza (tool poisoning, shadowing, rug pulls, manipulación del transporte, ocupación de registro) están todas ya documentadas en la literatura pública sobre seguridad de MCP.