El Model Context Protocol (MCP) es la nueva interfaz universal para que los modelos de lenguaje interactúen con herramientas externas. En decir: conecta tu ChatGPT, Claude, o el asistente que uses, con tus archivos, tus bases de datos, tus servicios (Ej. Git, Jira). Y está creciendo rápido. Demasiado rápido para que la seguridad vaya al mismo ritmo.
La primera vez que conecté un MCP server a mi flujo de trabajo, fue prácticamente instantáneo. Configuré el cliente, apunté al servidor, y de repente mi asistente de IA podía leer tickets, consultar usuarios, y ejecutar cambios en mi nombre en el servidor. Funcionaba. Hermoso.
Y luego me detuve.
Llevo veinte años en esto. He visto el patrón tantas veces que lo reconocí al instante: estábamos conectando todo antes de pensar en quién debería tener acceso a qué. Lo mismo hicimos con las APIs en 2010. Lo mismo con los contenedores en 2015. Lo mismo con los servicios en la nube en 2018. Conectar es fácil. Asegurar es el trabajo que nadie quiere hacer.
Qué es MCP (y por qué debería importarte)
MCP es un protocolo abierto que Anthropic lanzó a finales de 2024. La idea es simple: en lugar de escribir una integración personalizada por cada herramienta que un modelo necesita usar, escribes un servidor MCP y cualquier cliente compatible puede usarlo. Es como el USB-C de la IA.
La arquitectura es así:
Tú < - > Aplicación de IA (Host) < - > Cliente MCP < - > Servidor(es) MCP < - > Herramientas / APIs / Datos
El cliente MCP conecta con uno o más servidores. Cada servidor expone herramientas: funciones que el modelo puede invocar. Y aquí está el detalle importante: el modelo decide qué herramientas invocar, cuándo, y con qué parámetros. No es código que tú escribiste y revisaste. Es el modelo leyendo descripciones de herramientas y tomando decisiones autónomas.
Eso cambia el modelo de amenaza por completo.
El patrón que se repite
Cada vez que aparece una nueva capa de abstracción, hacemos lo mismo:
- La construimos rápido porque resuelve un problema real.
- La conectamos a todo porque es conveniente.
- Descubrimos los riesgos cuando algo se rompe.
- Parcheamos lo que podemos.
- Escribimos guías de seguridad que nadie lee.
MCP está en la fase 2. Conectado a todo, conveniencia máxima, y la seguridad es un "deberías considerar" que vive al final de la documentación.
La especificación oficial dice explícitamente que "no impone seguridad a nivel de protocolo". Eso significa que todo el trabajo de autenticación, autorización, validación de entrada, y control de acceso es responsabilidad tuya. Del implementador. De quien conecta el servidor y no lee la letra pequeña.
Los riesgos reales
OWASP publicó su MCP Top 10 en 2025. Son diez categorías de riesgo válidas. Pero listar vulnerabilidades no ayuda a entender por qué importan. Voy a agruparlas en tres problemas que se materializan en el mundo real.
1. El "confused deputy": tu servidor tiene más permisos que tú
Imagina esto: conectas un MCP server a tu cuenta de Gmail. El MCP necesita leer tus correos para resumirlos. Le das acceso completo. Ahora el MCP puede leer, enviar, eliminar, y buscar en tus correos, al igual que tu agente de AI. Todo con tus credenciales.
El problema es que el servidor MCP ejecuta acciones con sus propios permisos, no con los tuyos. Si el MCP está comprometido, o si el modelo es manipulado vía inyección de prompts, el atacante tiene acceso a todo lo que el MCP puede hacer. No a lo que tú puedes hacer. A lo que el MCP puede hacer. Y eso suele ser más.
Esto se llama el problema del deputy confundido (confused deputy), y es un clásico de seguridad que lleva décadas existiendo. MCP lo amplifica porque actúa en tu nombre, con tokens de larga duración, y sin validación de sí la acción que va a ejecutar es realmente la que tú querías.
Lo que deberías hacer: tokens de corta duración, scopes mínimos (solo lectura si solo necesitas lectura), y confirmación humana para acciones destructivas o sensibles.
2. Tool poisoning: las descripciones son vectores de inyección
Cada herramienta MCP tiene una descripción. Es texto que el modelo lee para entender qué hace la herramienta y cómo usarla. Parece inofensivo, pero...
Un atacante puede inyectar instrucciones maliciosas en la descripción de una herramienta. El modelo lee la descripción, sigue las instrucciones, y ejecuta acciones que tú no esperabas. Esto se llama tool poisoning (envenenamiento de herramientas), y tiene variantes:
- Rug pulls: una herramienta aprobada cambia su descripción después de que tú diste consentimiento. Lo que era benigno se vuelve malicioso sin que nadie te notifique.
- Tool shadowing: un servidor malicioso introduce una herramienta con un nombre similar a una legítima, interceptando las llamadas.
- Schema poisoning: los parámetros de la herramienta se corrompen para engañar al modelo sobre qué valores son válidos.
OWASP lo puso en el puesto #3 de su Top 10. La NSA lo menciona explícitamente en su guía de mayo de 2026. Y, sin embargo, la mayoría de las implementaciones no verifican la integridad de las descripciones después de la instalación inicial.
Lo que deberías hacer: inspecciona todas las descripciones antes de aprobar, fija las definiciones con hashes criptográficos, y alerta si cambian. Herramientas como mcp-scan pueden detectar descripciones envenenadas automáticamente.
3. Supply chain: instalar MCP's de fuentes no verificadas
El ecosistema MCP está creciendo. Hay servidores para todo: GitHub, Slack, bases de datos, sistemas de archivos, APIs de pago. Muchos son paquetes de código abierto que instalas con un comando.
¿Revisaste el código antes de instalarlo? ¿Verificaste la integridad del paquete? ¿Sabes quién lo mantiene?
Si la respuesta es no, acabas de darle acceso a tus datos a código que no revisaste. Es el mismo problema de npm install sin auditoría, pero con la diferencia de que aquí el paquete no solo lee tus archivos: ejecuta acciones en tu nombre, con tus credenciales.
El typosquatting ya llegó a MCP. Hay paquetes con nombres como mcp-server-filesytm (nota la 'e' faltando) que esperan a que te equivoques al escribir el nombre correcto. Una vez instalado, tienes un MCP malicioso con acceso a tu sistema.
Lo que deberías hacer: instala solo de fuentes verificadas, revisa el código fuente, verifica checksums o firmas, y escanea dependencias por vulnerabilidades conocidas.
Qué hacer si ya tienes MCP en producción
Si ya conectaste servidores MCP a tu flujo de trabajo, no entres en pánico. Pero tampoco asumas que "porque funciona, está bien". Aquí van acciones concretas, priorizadas por impacto:
Inmediato (esta semana)
- Inventario: ¿Qué servidores MCP tienes conectados? ¿Qué permisos tienen? ¿Quién los instaló? Si no puedes responder esto, empieza aquí.
- Revisa scopes: ¿Tus servidores tienen acceso de lectura y escritura cuando solo necesitan lectura? Reduce al mínimo.
- Confirma antes de ejecutar: si tu configuración actual auto-aprueba llamadas a herramientas, desactívalo. Requiere confirmación humana para acciones destructivas o sensibles.
Corto plazo (este mes)
- Aísla servidores: corre servidores MCP en contenedores o entornos sandbox. Restringe acceso al sistema de archivos. Deshabilita red a menos que sea explícitamente necesaria.
- Verifica integridad: inspecciona las descripciones de todas las herramientas. Fíjalas con hashes criptográficos. Configura alertas si cambian.
- Audita dependencias: escanea los paquetes de tus servidores MCP por vulnerabilidades conocidas. Revisa el código fuente si puedes.
Continuo (de aquí en adelante)
- Monitorea anomalías: nuevas herramientas siendo llamadas, consultas a nivel de admin, frecuencia anormal de llamadas.
- Educa al equipo: MCP no es "solo otro API". Es una capa donde el modelo toma decisiones autónomas con acceso a sistemas reales. Eso cambia las reglas.
Llevamos veinte años repitiendo el mismo patrón. Construimos rápido, conectamos todo, y aseguramos después. Funcionó con las APIs. Funcionó con los contenedores. Funcionó con la nube. Pero MCP es diferente. No es una capa de abstracción más. Es una capa donde la IA decide qué hacer, con acceso a tus sistemas, en tu nombre. Eso no es un API que tú llamas. Es un agente autónomo que actúa por sí mismo.
La seguridad no es un feature que agregas al final. Es la arquitectura que defines al principio.
Referencias:
- OWASP MCP Top 10 (v0.1)
- OWASP MCP Security Cheat Sheet
- MCP Security Best Practices (especificación oficial)
- NSA: MCP Security Design Considerations (Mayo 2026)
- mcp-scan: Security Scanner for MCP Servers
- IETF Draft: Secure MCP — Message Signing & Tool Integrity
Foto de David Levêque en Unsplash
