Una investigación de la empresa de ciberseguridad Silverfort ha puesto al descubierto una vulnerabilidad en Microsoft Entra ID (antes Azure AD) que abría la puerta a una escalada de privilegios crítica. El fallo afectaba a la nueva función privilegiada Agent ID Administrator, diseñada para gestionar identidades de agentes de IA, pero que en la práctica podía utilizarse para tomar el control de cuentas de servicio altamente sensibles.
Nueva vulnerabilidad en Microsoft Entra ID y el rol Agent ID Administrator
Microsoft introdujo la plataforma agent identity para habilitar AI agents dentro de Microsoft Entra ID. Estos agentes no son usuarios humanos, sino componentes software o servicios que necesitan autenticarse de forma segura y acceder a recursos en el tenant de la organización. Para gestionarlos, se creó la función integrada Agent ID Administrator, pensada para cubrir todo el ciclo de vida de estas identidades: creación, actualización, gestión de claves y credenciales.
En teoría, el alcance de esta función debía limitarse exclusivamente a identidades de agentes. Sin embargo, de acuerdo con Silverfort, un error en la definición del scope de permisos permitió que dicha función impactara también en otros tipos de identidades críticas dentro de Entra ID.
De administrar agentes a tomar control de service principals
La investigación reveló que un usuario con rol Agent ID Administrator podía intervenir sobre cualquier service principal del tenant. Los service principals son objetos de identidad especiales que utilizan aplicaciones, automatizaciones y servicios para autenticarse y acceder a recursos en la nube. Normalmente, su gestión está fuertemente restringida porque a menudo concentran permisos muy amplios.
Según detalló el investigador de Silverfort, Noa Ariel, el problema residía en que el administrador de agentes podía nombrarse a sí mismo propietario de cualquier service principal, incluso si no estaba relacionado con agentes de IA, y a continuación agregar sus propias credenciales (claves o certificados) para autenticarse en su nombre. El resultado práctico era la toma de control total de ese service principal y de todos los permisos asociados en Microsoft Entra ID.
Si el service principal afectado formaba parte de roles privilegiados del directorio o contaba con permisos de alto impacto en Microsoft Graph (por ejemplo, lectura/escritura de correo, archivos o configuración de seguridad), el atacante podía aprovecharlo para una escalada de privilegios y expandir progresivamente su control sobre la infraestructura en la nube.
Riesgos de seguridad asociados a la toma de control de un service principal
En entornos cloud maduros, los service principals suelen ser el corazón de procesos como CI/CD, integraciones con soluciones SaaS, copias de seguridad, automatización de tareas de administración y operación de aplicaciones de negocio críticas. Diversos estudios, como los informes anuales de incidentes de seguridad en la nube, han mostrado que las identidades no humanas suelen acumular más privilegios que los usuarios finales por razones de comodidad y continuidad operativa.
Comprometer un service principal con permisos amplios equivale a disponer de las mismas capacidades que la aplicación legítima: lectura y modificación de configuraciones del directorio, acceso a correos y calendarios, manipulación de archivos en repositorios corporativos o extracción de secretos almacenados en bóvedas. Combinado con privilegios de gestión de identidades, esto proporciona un vector sólido para movimiento lateral, persistencia y, potencialmente, el control total del tenant.
Respuesta de Microsoft y corrección de la vulnerabilidad
Silverfort notificó responsablemente la vulnerabilidad a Microsoft el 1 de marzo de 2026. Tras analizar el problema, Microsoft desplegó un parche en todas las nubes afectadas el 9 de abril de 2026, ajustando el alcance de la función Agent ID Administrator.
Con la corrección aplicada, cualquier intento de asumir la propiedad de un service principal que no sea de tipo “agente” utilizando este rol es ahora bloqueado, devolviendo un código de error 403 Forbidden. De este modo se impide que la función se utilice para manipular identidades fuera de su ámbito previsto.
Identidades no humanas y diseño seguro de roles en la nube
El incidente ilustra la importancia de validar exhaustivamente los scopes de roles y permisos, especialmente cuando se construyen nuevas capacidades (como identidades para agentes de IA) sobre primitivas existentes como los service principals. Un error aparentemente menor en el diseño de un rol puede derivar en un sobredimensionamiento de privilegios con impacto sistémico.
Este caso se enmarca en una tendencia más amplia: el crecimiento masivo de identidades no humanas en la nube (cuentas de servicio, microservicios, contenedores, robots software, etc.). Cuando estas identidades comparten componentes y APIs con otros tipos de cuenta sin un aislamiento estricto, cualquier fallo en la segmentación de permisos puede traducirse en rutas inesperadas de escalada de privilegios.
Recomendaciones de ciberseguridad para Microsoft Entra ID
Para reducir la superficie de ataque en entornos que dependen de Microsoft Entra ID y service principals, conviene reforzar los controles de identidad y acceso más allá de los parches del fabricante. Entre las medidas recomendadas destacan:
1. Monitorizar el uso de roles sensibles. Registrar y vigilar actividades relacionadas con la propiedad de service principals y la modificación de sus credenciales. Cualquier operación inusual debe generar alertas automáticas en el SIEM.
2. Controlar los cambios de propietarios de service principals. Limitar el conjunto de administradores autorizados y revisar sistemáticamente la asignación de nuevos propietarios, ya que es un claro indicador de posible abuso de privilegios.
3. Proteger los service principals privilegiados. Aplicar el principio de mínimo privilegio, revisar periódicamente roles y permisos, y almacenar claves y certificados únicamente en repositorios seguros (como bóvedas de secretos gestionadas).
4. Auditar la creación y actualización de credenciales. Asegurarse de que los registros de autenticación y de cambios en Entra ID permiten detectar rápidamente eventos sospechosos relacionados con claves, certificados y secretos.
La adopción acelerada de agentes de IA y otras identidades no humanas hace que la gestión fina de roles y permisos en la nube sea un pilar de seguridad ineludible. El caso de la función Agent ID Administrator subraya que toda nueva funcionalidad basada en mecanismos de identidad existentes debe someterse a revisiones rigurosas de seguridad. Las organizaciones que combinen los parches oficiales con una estrategia propia de Zero Trust, monitorización continua y gobierno sólido de identidades estarán mejor preparadas para resistir este tipo de vulnerabilidades emergentes.
