El Model Context Protocol lo cambió todo. Por primera vez, los agentes de IA pueden leer tus bases de datos, llamar tus APIs, ejecutar código, modificar archivos y gestionar infraestructura en la nube — todo a través de una interfaz única y estandarizada. Anthropic liberó MCP como código abierto a finales de 2024. En cuestión de meses, ya estaba en todas partes. Microsoft, Google, Amazon, cientos de herramientas. La curva de adopción fue vertical.
Y ese es exactamente el problema.
Los MCP servers se están convirtiendo en la nueva capa de API — los guardianes entre agentes de IA y todo lo que importa en tu organización. Tus datos. Tu infraestructura. Tu lógica de negocio. Si estás construyendo, desplegando o dependiendo de uno, necesitas entender cómo funcionan realmente los MCP servers — y cuán expuestos están la mayoría. Porque la respuesta es incómoda.
Los números cuentan una historia preocupante
En 2025, Astrix Security realizó un análisis de más de 5.200 implementaciones open-source de MCP servers. Los hallazgos fueron alarmantes: el 53% depende de secretos estáticos de larga duración, como claves de API y tokens de acceso personal. Solo el 8,5% utiliza métodos modernos de autenticación como OAuth. La investigación de HiveTrail pintó un panorama aún más sombrío — el 43% de los MCP servers open-source analizados tiene fallos de inyección de comandos, el 33% permite búsquedas de URL sin restricción, y el 22% filtra archivos fuera de los directorios previstos.
Cerca de 2.000 MCP servers están expuestos públicamente en internet hoy sin autenticación y sin controles de acceso. No están mal configurados — simplemente están desprotegidos por diseño. La propia especificación de MCP ofrece orientación mínima sobre autenticación, lo que ha llevado a una postura de seguridad fragmentada y peligrosamente inconsistente en todo el ecosistema.
Esto no es un problema teórico. Solo en 2025, se divulgaron vulnerabilidades críticas de ejecución remota de código en MCP servers en producción: CVE-2025-6514, CVE-2025-53967 en el Framelink Figma MCP Server, y CVE-2025-49596 en el MCP Inspector de la propia Anthropic. Asana corrigió un fallo en su MCP server que podría haber expuesto datos de clientes. Se reportó una vulnerabilidad de inyección de prompt en el MCP server oficial de GitHub.
Los cinco vectores de ataque que todo equipo debe conocer
El emergente marco OWASP MCP Top 10 identifica varias categorías críticas de amenazas. Comprenderlas es el primer paso para construir una infraestructura resiliente.
1. Inyección de prompt
OWASP clasifica la inyección de prompt como el riesgo número uno para aplicaciones LLM (LLM01:2025). En el contexto MCP, este ataque utiliza entradas manipuladas para inducir a agentes de IA a ejecutar acciones no previstas a través de sus herramientas conectadas — exfiltración de datos, escalamiento de privilegios, modificaciones no autorizadas. La inyección indirecta de prompt es particularmente peligrosa: instrucciones maliciosas se incrustan en contenido externo que el agente de IA ingiere, invisibles para los operadores humanos pero fielmente ejecutadas por el modelo.
2. Envenenamiento de herramientas
El envenenamiento de herramientas es una forma de inyección indirecta de prompt exclusiva del ecosistema MCP. Los atacantes modifican los metadatos de una herramienta — su descripción, esquema de parámetros o documentación del tipo de retorno — para incrustar instrucciones ocultas que el modelo de IA sigue. La herramienta envenenada ni siquiera necesita ser invocada directamente; su mera presencia en la ventana de contexto del modelo puede alterar la forma en que el agente interactúa con otras herramientas legítimas.
3. Ataques a la cadena de suministro
Los MCP servers siguen un modelo de distribución similar a npm: los desarrolladores instalan paquetes de registros, los configuran vía JSON y los ejecutan con amplio acceso al sistema. Un solo paquete comprometido puede propagarse a través de miles de despliegues. A diferencia de los ecosistemas tradicionales de paquetes, los MCP servers frecuentemente se ejecutan con privilegios elevados — acceso directo a bases de datos, sistemas de archivos e infraestructura de red.
4. Shadow MCP
Shadow MCP es el equivalente MCP de shadow IT. Los ingenieros inician MCP servers no autorizados para prototipar rápidamente o integrar con un cliente de IA personal. Estos servidores operan fuera del perímetro de seguridad de la organización — sin gobernanza, sin supervisión, sin monitoreo. Acceden a bases de datos de producción con credenciales de desarrollador y realizan llamadas de API con tokens personales.
5. Brechas de autenticación y autorización
La especificación MCP requiere identificadores de sesión en URLs — una práctica que viola principios fundamentales de seguridad y expone material de credencial en logs del servidor, historiales de navegador y cabeceras HTTP referrer. La mayoría de los servidores no implementa integración SSO, control de acceso basado en roles, ni rotación de tokens. El resultado: una URL filtrada otorga acceso completo y persistente a todo el servidor.
Ya hemos visto este patrón antes
La deuda de seguridad acumulada en el ecosistema MCP no carece de precedentes. Lo vimos con APIs REST lanzadas sin limitación de tasa a principios de los 2010. Lo vimos con bases de datos NoSQL distribuidas con credenciales predeterminadas expuestas en internet. Lo vimos con contenedores Docker ejecutándose como root con montajes del sistema de archivos del host durante media década. Cada vez, el patrón es el mismo: una nueva tecnología entrega capacidades increíbles sin protección alguna, la adopción supera la conciencia sobre seguridad, y la industria dedica años a corregir retroactivamente lo que debió ser seguro desde el primer día.
El MCP está exactamente en ese punto de inflexión ahora. El ecosistema es lo suficientemente joven como para hacerlo bien. Pero la ventana se está cerrando.
Si un MCP server puede ejecutar código, acceder a datos y realizar llamadas de red — entonces debe estar aislado, autenticado y monitoreado desde el momento en que se ejecuta por primera vez. No después de la primera brecha. No después de la primera auditoría de cumplimiento. Desde su nacimiento.
Cómo se ve la seguridad integrada en el runtime
Vinkius es una plataforma cloud diseñada específicamente para desplegar MCP servers con seguridad como arquitectura fundamental — no como un interruptor de configuración. Cada server desplegado en Vinkius se ejecuta dentro de su propio V8 isolate, la misma tecnología de sandboxing que impulsa Cloudflare Workers y el aislamiento de pestañas de Chrome. El isolate aplica 34 reglas de ingeniería que gobiernan cada aspecto de la ejecución.
Sandboxing V8 isolate
Cada MCP server recibe su propio espacio de memoria aislado con un límite de heap configurable (predeterminado: 32 MB). No hay acceso al sistema de archivos. No hay contaminación de memoria entre servidores. El isolate ejecuta el código del desarrollador en un entorno completamente sellado: globalThis.console es un proxy agujero negro, process.env es un objeto vacío, y setInterval está intencionalmente desactivado.
Protección proxy SSRF
Todas las solicitudes de red salientes de MCP servers en Vinkius pasan a través de un SSRF guard con IP fijada. Antes de que cualquier solicitud HTTP abandone la plataforma, el DNS se resuelve a una dirección IPv4 y se valida contra una lista de bloqueo integral: rangos privados RFC 1918, loopback, direcciones link-local (incluyendo el célebre endpoint de metadatos de AWS en 169.254.169.254).
Prevención de pérdida de datos (DLP)
Controles DLP configurables inspeccionan todos los datos salientes en busca de patrones sensibles antes de abandonar la plataforma: claves de API, tokens de autenticación, información personal identificable, números de tarjetas de crédito y patrones personalizados. Cuando se detecta una coincidencia, los datos se redactan en tránsito. El DLP está habilitado por defecto en cada despliegue.
Autenticación HMAC
Cada solicitud a un MCP server alojado en Vinkius se firma criptográficamente mediante HMAC-SHA256. No hay claves de API estáticas que filtrar ni URLs que adivinar. La autenticación se verifica en tiempo constante — los ataques de canal lateral por temporización no pueden determinar coincidencias parciales de clave.
El camino hacia adelante para el ecosistema MCP
Creemos que los MCP servers serán tan ubicuos como las APIs REST en los próximos dos años. Cada empresa los operará. Cada framework de agentes de IA — desde LangChain hasta CrewAI y AutoGen — dependerá de ellos. La cuestión no es si el ecosistema escalará, sino si lo hará de forma segura. Por eso construimos Vinkius sobre un framework MCP open-source diseñado para producción desde el primer día.
Vinkius existe para hacer que el camino seguro sea el camino fácil. Cuando despliegas un MCP server en Vinkius, el aislamiento V8 no es opcional. La protección SSRF no es algo que configuras. El DLP no es un tier premium. La autenticación HMAC no es un flag que recuerdas activar. Esta es la arquitectura. Así es como todo MCP server seguro debería funcionar.
Este es el día uno
El ecosistema MCP aún es joven. Los estándares aún se están escribiendo. La infraestructura aún se está construyendo. Hay una ventana estrecha — ahora mismo — para integrar la seguridad en los cimientos de la infraestructura de agentes de IA, en lugar de dedicar la próxima década a remendarla.
Si estás construyendo MCP servers, si estás desplegando agentes de IA en producción, si te importa la integridad de la infraestructura de la que dependen tus modelos — nunca ha habido un momento más crítico para hacerlo bien.