Cada credencial MCP que tu equipo entregó probablemente fue una buena idea el día que la configuraron. Nadie ha vuelto a revisarla desde entonces. Esa es la brecha que están aprovechando los atacantes, no un fallo en el protocolo en sí.
El Protocolo de Contexto de Modelo (MCP) de Anthropic entró en producción a finales de 2024 y se extendió rápidamente. Desde entonces, se han creado miles de servidores MCP. Microsoft, Google y OpenAI lo adoptaron, y el mantenimiento del protocolo pasó a manos de la Linux Foundation. Hoy en día, el MCP se considera una infraestructura crítica. Actúa como intermediario entre un agente de IA y las herramientas y datos con los que interactúa. Para la mayoría de los equipos, se implementó igual que cualquier otro estándar de integración: lo instalaron y confiaron en la configuración predeterminada.
En 2026 quedó claro que el problema no estaba en la infraestructura, sino en los permisos que operan por debajo de ella.
Esto es crucial porque cambia la forma en que se abordan los problemas de seguridad del MCP. Un parche soluciona un problema específico en un servidor concreto, pero cambiar los permisos requiere plantearse una pregunta compleja: ¿por qué ese servidor necesitaba acceso a algo que nunca debió tocar? Según la encuesta de amenazas a la identidad de SANS 2026, que consultó a más de 500 expertos en seguridad, el 76 por ciento de las empresas notó un aumento en las identidades no humanas. El 74 por ciento utiliza sistemas de IA que dependen de credenciales permanentes para trabajar de forma autónoma. La misma encuesta reveló que ninguna de las medidas de protección, como procesos de aprobación, sandboxing o registro de actividades, es utilizada por más del 40 por ciento de las empresas.
Si miramos más allá de las divulgaciones individuales, la causa raíz sigue siendo la misma. En mayo de 2025, un atacante utilizó inyección de prompts contra el servidor MCP de GitHub para extraer datos de repositorios privados, no porque el servidor tuviera un error en el sentido tradicional, sino porque el token de acceso personal asociado tenía un alcance mucho mayor del necesario para la tarea. Días después, un fallo lógico en una integración MCP de Asana permitió el acceso entre diferentes clientes porque la barrera de aislamiento nunca se aplicó a nivel de permisos.
Los investigadores de seguridad ahora agrupan esto bajo un par de patrones reconocibles: el envenenamiento de herramientas, donde la descripción de la herramienta de un servidor contiene instrucciones ocultas, y el problema del "diputado confundido", donde un agente hereda más confianza de la que requiere la tarea que tiene delante.
Lo que realmente debes revisar en un rediseño de permisos
La solución que sigue apareciendo no es un mejor escáner, sino la compartimentación del acceso. El blog de ingeniería de GitHub, que analiza el desarrollo de servidores MCP remotos seguros, sugiere lo siguiente: cada instancia debe tener sus secretos ajustados a la tarea específica, todas las solicitudes deben limitarse al usuario que realiza la acción y la autorización debe realizarse acción por acción en lugar de asumirla tras la autenticación del usuario. Los tokens fijos y permanentes deben sustituirse por credenciales dinámicas y temporales generadas al momento.
Esta solución es escalonada y ha funcionado hasta ahora. En Webflow, tratamos las integraciones MCP de la misma manera que otros componentes de terceros con acceso a datos de clientes.
Cada credencial que el equipo otorga a un agente de IA probablemente fue una buena idea cuando se creó. La decisión difícil no es si el acceso era adecuado en ese momento, sino si todavía lo es, y la mayoría de los equipos no tienen la costumbre de hacerse esa pregunta.
Algunas cosas a considerar al integrar cualquier MCP:
¿A qué puede acceder esta credencial ahora, más allá del alcance para el que fue diseñada? Es probable que el alcance del acceso aumente silenciosamente. No habrá ninguna revisión programada hasta que algo falle.
¿La autorización se concede por sitio, por repositorio, por espacio de trabajo, o es todo o nada? Desconfía de cualquier integración que solo ofrezca acceso a nivel de organización. Si una integración no te permite controlar el alcance en el momento de la conexión, ese es el hallazgo principal, no una nota al pie.
¿El agente de IA hereda las credenciales existentes de la persona o crea una credencial completamente nueva que omite esos permisos? Esto último es lo que permite que un token de acceso personal de GitHub tenga más acceso a los repositorios que el propio usuario que lo autorizó.
¿Existe un registro de actividades que asigne responsabilidad por lo que hace el agente, igual que se hace con un humano? Si las actividades del agente son invisibles o no se pueden atribuir, la respuesta ante incidentes empieza desde cero.
¿Los cambios realizados por el agente pasan directamente a producción o atraviesan primero un proceso revisable como borradores, ramas o colas de aprobación? Esto no es más que aplicar a una nueva clase de entidad la disciplina de seguridad que el equipo ya tiene para los controles de acceso humanos.
La identidad va antes que el acceso
Antes de hablar de lo que se le permite hacer a un agente, debes responder a una pregunta más difícil: ¿qué es un agente en términos de identidad? Ahora mismo, la respuesta honesta para la mayor parte de la industria es "un token OAuth de un humano disfrazado". El agente no tiene su propia identidad. Hereda el alcance, el radio de impacto y, a menudo, la credencial literal de quien lo puso en marcha.
Eso es un problema en cuanto los agentes dejan de ser efímeros. La mayoría de los agentes actuales viven de minutos a horas: una tarea comienza, el agente se ejecuta y muere. Pero eso está cambiando. Nos dirigimos hacia agentes que funcionan durante semanas o meses, y algo que vive tanto tiempo necesita su propia identidad, no una prestada, con permisos que se vuelvan más estrictos, no más laxos, a medida que aumenta su tiempo de vida.
Piensa en la diferencia entre un contratista que viene una tarde y un trabajador temporal integrado en tus sistemas durante un trimestre. No le darías una credencial permanente al contratista de una tarde, y tampoco deberías darle al agente trimestral el mismo acceso que a un script de cinco minutos.
OAuth no se diseñó para esto; no es solo una función que falta, es un desajuste estructural y, en el fondo, un fallo de UX: un modelo de consentimiento pensado para un humano, aplicado a un proceso donde no hay ninguno. Todo su modelo asume que hay una persona frente a un cuadro de diálogo de permisos tomando una decisión informada, y ya sabemos cómo termina eso: nadie lee la lista de permisos, simplemente hacen clic en aceptar. Esa premisa, ya de por sí endeble, se desmorona por completo cuando no hay nadie leyendo nada.
La especificación base no contempla conceptos como "este cliente es un agente" o "se espera que esta concesión dure seis meses"; solo ofrece una fecha de caducidad establecida por el servidor a posteriori. Algunos borradores del IETF están empezando a esbozar una solución, vinculando la vida útil del token al ciclo de vida real de la tarea y etiquetando a los agentes con identidades estables distintas a las del humano que los invocó, pero son propuestas en fase inicial, no estándares implementados.
No tenemos una respuesta clara sobre dónde trazar la línea entre "tarea de corta duración con acceso amplio" y "agente de larga duración con acceso restringido". El equipo de seguridad de Webflow trabaja activamente en esto y estamos intercambiando impresiones con colegas del sector en lugar de fingir que lo hemos resuelto. Pero el planteamiento es lo que importa: trata la vida útil del agente como un factor fundamental de tu modelo de permisos, no como algo secundario.
Los permisos no son una casilla que se marca al aprovisionar
Rediseñar los permisos, actualizar el protocolo y ajustar el modelo de identidad son tres niveles distintos del mismo problema. Para que cada uno sea eficaz, los otros dos también deben serlo. Si creas una credencial con el alcance correcto el primer día, pero nadie verifica después que siga siendo válida, tu esfuerzo habrá sido en vano. Del mismo modo, si desarrollas un protocolo que por fin distingue a un agente del humano que lo respalda, pero todas las integraciones siguen ofreciendo acceso total por defecto, no habrás logrado gran cosa. Ninguno de estos enfoques aborda la cuestión de fondo: lo que se le permite hacer a un agente debería depender de cuánto tiempo existirá. Actualmente, casi todos los componentes de la pila tecnológica no saben ni cómo plantearse esa pregunta, mucho menos cómo responderla. Los equipos que acierten no serán los que desarrollen una herramienta de escaneo más eficiente. Serán los que dejen de ver el alcance, la identidad y la duración como tres evaluaciones separadas que ocurren una sola vez, y empiecen a tratarlas como un ajuste único que debe evaluarse cada vez que cambie la función o la existencia del agente.
