Desde su introducción en 2024, el Modelo de Protocolo Contextual (MCP) desarrollado por Anthropic se ha consolidado como un estándar fundamental en la integración de agentes de inteligencia artificial con herramientas y datos. Firmas de peso como Microsoft, Google y OpenAI adoptaron rápidamente esta tecnología, mientras que la Linux Foundation asumió su mantenimiento, situando al MCP como infraestructura crítica en el ámbito tecnológico.
Durante los primeros años, la implementación del MCP se realizó de manera convencional, siguiendo las prácticas habituales para otras integraciones: se instalaba y se confiaba en los ajustes predeterminados. Sin embargo, en 2026 se reveló un desafío esencial que no reside en la infraestructura en sí, sino en los permisos que operan por debajo de ella.
Este cambio de perspectiva es crucial para afrontar los problemas de seguridad que el MCP presenta. Mientras que una actualización de parche se limita a solucionar un fallo específico en un servidor concreto, la revisión de los permisos obliga a plantearse interrogantes más complejos: ¿Por qué un servidor requiere acceso a recursos que no eran necesarios para su función original? 
Un informe de la encuesta realizada en 2026 por SANS sobre amenazas a la identidad, que recogió opiniones de más de 500 expertos en seguridad, estimó que el 76 % de las empresas han experimentado un aumento significativo en el uso de identidades no humanas. Además, el 74 % de dichas organizaciones utilizan sistemas de inteligencia artificial que dependen de credenciales permanentes para operar de forma autónoma. Sin embargo, a pesar de estos datos preocupantes, menos del 40 % de las compañías emplean medidas básicas de protección como procesos de aprobación, sandboxing o registros de actividad.
El origen de numerosos incidentes de seguridad reside en permisos excesivos o mal configurados. Por ejemplo, en mayo de 2025, un atacante aplicó una técnica conocida como «inyección de prompt» contra un servidor MCP de GitHub para acceder a datos privados de repositorios. El problema no fue un error tradicional del sistema, sino que el token de acceso personal utilizado tenía un alcance mucho mayor al necesario para la tarea. En otro caso, una falla lógica en la integración MCP de Asana permitió el acceso cruzado entre diferentes clientes por no respetar los límites de aislamiento en la capa de permisos.
Los expertos clasifican estas vulnerabilidades bajo patrones como «envenenamiento de herramientas», en que una descripción de una herramienta del servidor lleva instrucciones ocultas, y el problema del «delegado confundido», donde un agente recibe más confianza de la que debería para la tarea concreta que realiza.
Rediseñando los permisos: el reto de la segmentación
La solución recurrente no pasa por mejorar los sistemas de detección, sino por segmentar rigurosamente el acceso. El blog de ingeniería de GitHub recomienda que cada instancia debe tener sus propios secretos específicos para la tarea que desempeña, limitando las solicitudes exclusivamente al usuario que actúa y fundamentando la autorización en la acción precisa, no simplemente tras la autenticación del usuario. Además, proponen reemplazar tokens fijos y permanentes por credenciales dinámicas y temporales generadas sobre la marcha.
En Webflow, el enfoque empleado para las integraciones MCP es similar al que se aplica a otros componentes de terceros con acceso a datos sensibles de clientes. Esto implica analizar periódicamente cada credencial concedida a un agente de IA para determinar si mantiene sentido en cuanto a alcance y vigencia.
Algunas reflexiones esenciales al incorporar qualsevol MCP incluyen:
- ¿Qué recursos puede alcanzar esta credencial actualmente más allá del alcance inicial previsto? El alcance tiende a ampliarse sin control, y salvo que ocurra algún incidente, las revisiones suelen posponerse indefinidamente.
- ¿La autorización se otorga por sitio, repositorio o área de trabajo, o es general para toda la organización? Se debe desconfiar de integraciones con acceso amplio sin opciones para restringir el alcance en el momento de la conexión.
- ¿El agente de IA hereda las credenciales del usuario o utiliza propias que ignoran dichas limitaciones? En casos como el token de acceso personal de GitHub, puede existir un acceso superior al del propio usuario que lo autorizó.
- ¿Se registran las acciones del agente con la misma trazabilidad y responsabilidad que las de un usuario humano? Sin un registro adecuado, la respuesta ante incidentes se vuelve extremadamente difícil.
- ¿Los cambios realizados por el agente entran en producción directamente o atraviesan un proceso de revisión que incluye borradores y aprobaciones? Aplicar las mismas normas de control de acceso humano a los agentes automatizados es fundamental para mantener la seguridad.
La identidad, antes que el acceso
La pregunta más difícil no es qué permisos otorgar, sino definir qué es un agente en términos de identidad. Actualmente, la práctica habitual es que un agente sea una «identidad prestada»: una especie de token OAuth humano «disfrazado». Los agentes heredan alcances, potencial para causar daños y credenciales del usuario que los crea, un modelo que resulta problemático cuando los agentes dejan de ser efímeros y comienzan a operar durante semanas o incluso meses.
Un agente con larga vida útil requiere una identidad propia, no una identidad prestada, además de contar con permisos más restringidos y actualizados conforme se extiende su tiempo de actividad. La comparación más adecuada es la diferencia entre un contratista que trabaja un día y un trabajador temporal integrado durante meses: ambos requieren niveles de acceso muy distintos y controlados.
El protocolo OAuth, diseñado inicialmente para la interacción humana, no está preparado para esta nueva realidad. Asume que una persona estará presente para confirmar los permisos, pero en los procesos sin intervención humana esta premisa se incumple casi siempre, debilitando la seguridad.
En este sentido, la comunidad técnica está explorando propuestas que permitan limitar la vida útil de los tokens al ciclo real de la tarea y asignar identidades estables a los agentes, desvinculándolos del usuario que los creó. Sin embargo, estas ideas siguen en fase temprana y todavía no se han convertido en estándares implementados.
En Webflow, el equipo de seguridad trabaja activamente en definir la frontera entre «tareas cortas con acceso amplio» y «agentes de larga duración con acceso restringido», colaborando con otros profesionales del sector para avanzar hacia soluciones prácticas que contemplen la duración del agente como un factor central en la gestión de permisos.
Permisos, una asignatura continua, no un trámite inicial
El rediseño de permisos, la actualización de protocolos y el desarrollo de modelos de identidad forman un trío imprescindible para afrontar el problema de la seguridad de los agentes IA. Estos tres elementos deben evolucionar y funcionar de manera integrada.
Crear una credencial adecuada desde el primer momento carece de sentido si no se verifica constantemente su validez a lo largo del tiempo. De igual modo, una mejora en el protocolo que diferencia el agente humano del artificial será inútil si persisten accesos genéricos y sin restricciones.
La clave está en no tratar el alcance, la identidad y la duración como evaluaciones aisladas, sino como un conjunto único que debe revisarse cada vez que cambie la función o la existencia del agente.
En la actualidad, la mayoría de los componentes tecnológicos no están preparados para plantear ni responder correctamente a estas preguntas. Por eso, las organizaciones que consigan integrar esta visión en sus sistemas serán las que establezcan un nuevo estándar en la seguridad del MCP.
