El fallo de seguridad de MCP no está en el protocolo, sino en los permisos
MCP se ha convertido en infraestructura crítica y los incidentes se repiten por la misma causa: credenciales permanentes y alcances mayores de lo que exige la tarea.
Anthropic puso MCP en producción a finales de 2024 y el protocolo se ha extendido sin freno desde entonces: miles de servidores, adopción por parte de Microsoft, Google y OpenAI, y el mantenimiento en manos de la Linux Foundation. La conclusión que se ha asentado este año es que el agujero no está en la infraestructura, sino en la capa de permisos que hay debajo. Parchear un servidor concreto resuelve ese caso; revisar los permisos obliga a preguntar por qué ese servidor necesitaba acceso a algo que nunca le hizo falta.
La encuesta SANS 2026 Identity Threats Survey, con más de 500 profesionales de seguridad, apunta en esa dirección: el 76% de las empresas ha visto aumentar las identidades no humanas y el 74% usa sistemas de IA que se apoyan en credenciales permanentes para operar por su cuenta. Ninguna de las medidas de protección habituales —procesos de aprobación, sandboxing, registro— la aplica más del 40% de las empresas.
El mismo origen, otra vez
Cada incidente conocido lleva al mismo sitio. En mayo de 2025 un atacante usó inyección de prompt contra el servidor MCP de GitHub para sacar datos de repositorios privados, y no por un fallo al uso: el token de acceso personal que había detrás tenía un alcance mucho mayor que la tarea. Días después, un error de lógica en la integración MCP de Asana permitió acceso entre inquilinos porque la capa de permisos nunca aplicó la frontera de aislamiento entre clientes. La investigación en seguridad agrupa estos casos en dos patrones: tool poisoning, donde la descripción de la propia herramienta esconde instrucciones, y el problema del diputado confundido, donde el agente hereda más confianza de la que exige la tarea que tiene delante.
Compartimentar antes que escanear
La respuesta que se repite no es un escáner mejor, sino compartimentar el acceso. El blog de ingeniería de GitHub recomienda que cada instancia tenga sus propios secretos para la tarea concreta, que toda petición se limite al usuario que actúa, que la autorización se base en la acción y no se dé por hecha tras autenticar al usuario, y que los tokens fijos y permanentes se sustituyan por credenciales dinámicas generadas al vuelo. En Webflow tratan las integraciones MCP como cualquier otro componente de terceros con acceso a datos de clientes.
Las preguntas que conviene hacerse antes de conectar nada: qué alcanza hoy esa credencial, no para qué se pensó; si la autorización es por sitio, por repositorio o por espacio de trabajo, o es todo o nada; si el agente hereda las credenciales de la persona o se crea unas nuevas que se saltan esos permisos; si los registros permiten atribuir lo que hizo el agente igual que se atribuye lo de un humano; y si sus cambios van directos a producción o pasan por rama, borrador y cola de aprobación.
Queda un problema de fondo que no se arregla con configuración. Un agente no tiene identidad propia: hereda el alcance, el radio de explosión y a menudo la credencial literal de quien lo lanzó, algo que se puede resumir como un token OAuth humano con gabardina. Mientras un agente vive minutos u horas eso se sostiene; cuando empiece a vivir semanas o meses, necesitará identidad propia y permisos que se estrechen con el tiempo, no que se ensanchen. OAuth no se diseñó para eso y no es solo una función que falte: su modelo de consentimiento asume un humano delante de la rueda de alcances, y aquí no lo hay.
