MCP y la seguridad de los agentes de IA: cómo el protocolo abrió una nueva superficie de ataque

Model Context Protocol (MCP) ha vuelto modulares a los agentes de IA: ofrece una interfaz estándar única para conectarlos con cualquier herramienta o servicio. Pero esta unificación esconde un problema sistémico: cada nuevo servidor MCP amplía la zona de confianza del agente y crea un posible punto de ataque.

Por qué MCP ha creado nuevas vulnerabilidades

Los grandes modelos de lenguaje no tienen una frontera arquitectónica entre «datos» e «instrucciones». Todo lo que entra en el contexto del modelo es potencialmente ejecutable. MCP no resuelve este problema, sino que lo escala: ahora un agente puede tener decenas de herramientas conectadas, y cada una amplía la superficie de ataque.

Con la estandarización de MCP, un atacante que controle un solo servidor o que pueda colar datos en sus respuestas puede influir en toda la cadena de acciones del agente.

Tres grandes tipos de amenazas en el ecosistema MCP:

• Tool poisoning: la descripción de una herramienta en el servidor MCP contiene instrucciones ocultas que alteran el comportamiento del agente cuando la invoca
• Indirect prompt injection: las instrucciones maliciosas se esconden en un documento, un registro de base de datos o una página web que el agente lee mientras realiza una tarea
• Sampling abuse: la manipulación de la forma en que el agente solicita nuevas salidas al modelo, lo que permite eludir las restricciones del prompt de sistema

Incluso un PDF «inofensivo», la descripción de una herramienta o una fila de una base de datos pueden contener comandos que el agente ejecutará igual que las instrucciones legítimas.

Qué reveló la prueba práctica

Las vulnerabilidades no son teóricas. Un investigador realizó pruebas en un entorno MCP vulnerable configurado específicamente para ello y documentó la ejecución real de comandos inyectados. Entre los escenarios registrados figuran la interceptación de llamadas a herramientas mediante respuestas del servidor MCP diseñadas a propósito y la ejecución de instrucciones ocultas en documentos de texto que se entregaban al agente como «datos».

«Cada servidor MCP en el que confías amplía la zona de confianza de

todo el sistema, no solo con sus herramientas, sino con todo lo que pueda entregar al agente en forma de datos».

El escáner BarkingDog, desarrollado por el autor, detecta en tiempo real llamadas sospechosas a herramientas. Es una de las pocas herramientas prácticas de detección que los equipos de seguridad tienen hoy a su alcance.

Cómo intenta la industria cerrar el problema

Los fabricantes de infraestructura de IA avanzan en varias direcciones a la vez:

• MCP Gateways: una capa proxy que filtra y controla las llamadas a herramientas antes de que lleguen al agente; algunas soluciones añaden un registro de auditoría completo de las interacciones
• Sandboxing: aislamiento de la ejecución de los servidores MCP, con acceso restringido al sistema de archivos, la red y los recursos del sistema
• Arquitecturas OAuth: autorización explícita de cada herramienta con permisos mínimos; cada servidor MCP recibe solo los permisos que realmente necesita para una tarea concreta

Por ahora, todas estas soluciones son parciales. El problema de fondo es arquitectónico: mientras los modelos de lenguaje no aprendan a separar el data plane del control plane al procesar el contexto, cualquier dato de entrada seguirá siendo potencialmente ejecutable.

Qué significa esto

MCP se ha convertido en el estándar de facto para los agentes de IA, y su seguridad ha pasado del terreno académico al práctico. Los desarrolladores que despliegan agentes con servidores MCP deberían tratar cada herramienta conectada como un tercero de confianza, con auditoría obligatoria, aislamiento y el principio de mínimo privilegio en cada llamada.