TL; DR
El Microsoft Plataforma de identidad de agente (Vista previa) otorga a los agentes de IA sus propias identidades en Entra ID (planos, identidades de agentes, usuarios de agentes) para que pueda gobernarlos y protegerlos como cualquier otro principal. Para administrar ese nuevo plano de control, Microsoft introdujo el Administrador de ID de agente función. En teoría, su alcance se limita a objetos relacionados con agentes.
Descubrimos que las cuentas con único El rol de Administrador de ID de agente podría asumir entidades de servicio arbitrarias, incluidas aquellas que no tienen nada que ver con las identidades de los agentes, al convertirse en propietario, agregar credenciales y autenticarse como esa entidad. Eso es una adquisición principal de servicio completo.En los inquilinos donde existen directivos de servicio altamente privilegiados, se convierte en un escalada de privilegios camino.
Aunque el rol de Administrador de ID de Agente aún no se utiliza ampliamente, la mayoría de los inquilinos cuentan con al menos una entidad de servicio privilegiada. También observamos que muchos inquilinos ya utilizan identidades de agente, en ocasiones a gran escala. A medida que aumente la adopción del rol de Administrador de ID de Agente, esta brecha de alcance podría convertirse en un riesgo significativo para la seguridad de la identidad.
Revelamos este comportamiento al Centro de Respuesta de Seguridad de Microsoft (MSRC), y estaba fijo en cada nubeEl rol de Administrador de ID de agente ya no puede gestionar a los propietarios de entidades de servicio que no sean agentes.
Si ya está familiarizado con los conceptos descritos anteriormente, pase directamente a Donde se rompe el límite.
El análisis que se presenta a continuación se basa en los resultados completos de nuestra investigación.
Lo que necesitas saber
Aplicaciones y principios de servicio en Entra ID
Cómo registrar una aplicación en Microsoft Entra ID crea dos objetos relacionados en el inquilino de vivienda, que es el inquilino donde la aplicación está registrada originalmente: un objeto de aplicación y director de servicio.
El Postulación El objeto sirve como definición global de la aplicación y describe su configuración.
El director de servicio representa la aplicación como una identidad dentro de un inquilino y es el objeto que se autentica, se le asignan roles y permisos, y accede a los recursos. Si la aplicación está configurada como multiinquilinoAdemás, se crean entidades de servicio adicionales en otros inquilinos cuando se utiliza la aplicación en ellos, todas basadas en el mismo objeto de aplicación.
Microsoft Entra ID tiene diferentes tipos de principios de servicio, como servicio de aplicación directores y identidades gestionadas. An principal del servicio de aplicación es la instancia de una aplicación en un inquilino, creada a partir del objeto de la aplicación.
En este blog, nos centramos únicamente en este tipo, ya que el comportamiento que se describe aquí se aplica específicamente a las entidades de servicio de la aplicación.
ID de agente de Microsoft Entra
ID de agente de Microsoft Entra te permite tratar a los agentes de IA como identidades de primera clase en Entra ID. Eso significa acceso condicional, gobernanza y gestión del ciclo de vida para los agentes de IA en su inquilino. En el fondo, está construido sobre la Plataforma de identidad de agente de MicrosoftSe trata de un marco de identidad y autorización para agentes de IA. Introduce nuevos tipos de objetos (planos, identidades de agente, usuarios de agente), todos gestionables mediante Microsoft Graph (actualmente, solo API beta). La plataforma aún está en fase de vista previa, pero los roles ya están disponibles públicamente para su asignación y uso.
En resumen, la plataforma introduce:
- Plano: Las plantillas que definen y crean identidades de agentes.
- Principios del plan maestro: La instancia específica del inquilino de un plano cuando se agrega a un inquilino.
- Identidades de los agentes: Principios de servicio especiales que los agentes de IA utilizan para autenticarse en las API y los servicios.
- Usuarios del agente: Se trata de objetos opcionales similares a los de un usuario para agentes que necesitan un UPN o un correo electrónico y que se utilizan en flujos de autenticación en nombre de terceros.
Por qué esto importa: Las identidades de los agentes se construyen sobre elementos básicos de directorio ya conocidos: aplicaciones, entidades de servicio y usuarios. Precisamente en esa base común reside nuestro hallazgo.
Rol de administrador de ID de agente
Microsoft añadió el Administrador de ID de agente función para gestionar el nuevo plano de control de identidad del agente. Según la documentación, Es limitado a:
En otras palabras: Solo cosas de agentesNo todos los principales de servicio. Esa distinción es importante. Los principales de servicio son las identidades detrás de la automatización, la integración y entrega continuas (CI/CD), las herramientas de seguridad y las integraciones privilegiadas. Quien los controla controla una parte importante del entorno.
Una observación más: los documentos dicen que este rol es privilegiadoSin embargo, en la interfaz de usuario de Entra (que se basa en las definiciones de roles de directorio beta) no se muestra como tal. Esto puede llevar a los administradores a asignarlo sin el mismo rigor que aplicarían a los roles con privilegios.
Microsoft confirmó que la discrepancia entre la interfaz de usuario de Entra y la documentación con respecto a el indicador “privilegiado” se arreglará.
Donde se rompe el límite
Esto es lo que observamos: Un usuario con el rol de Administrador de ID de agente puede agregarse como propietario de entidades de servicio más allá de las identidades relacionadas con el agente, incluyendo entidades de servicio arbitrarias en el inquilino. A partir de ahí, puede agregar credenciales y autenticarse como esas aplicaciones.
Paso 1: agregarpropietario(s) (tuvo éxito contra entidades principales de servicios que no son agentes; puede agregarse a sí mismo u otras entidades principales):
Paso 2: Agregar credenciales (Solo funcionó después de que nos convertimos en propietarios):
En resumen: La propiedad es un toma de control primitiva – conviértete en propietario, luego agrega un secreto y autentícate como esa entidad principal del servicio.
Si bien el rol está destinado a agente identidades, en la práctica puede cambiar la propiedad en cualquier director de servicio.
Por qué creemos que esto sucede: Algunas de las identidades de agente se implementan como entidades de servicio (y tipos relacionados). El rol tiene acciones como:
microsoft.directory/agentIdentities/owners/updatemicrosoft.directory/agentIdentityBlueprintPrincipals/owners/update
Por lo tanto, los administradores pueden gestionar los propietarios de los objetos de agente. Si esas comprobaciones no se limitan estrictamente a las entidades de servicio respaldadas por agentes, el permiso se extiende al plano general de las entidades de servicio.
Una clásica brecha de alcance cuando un tipo de objeto hereda de otro.
Lo hicimos No ver lo mismo para aplicacionesSe denegó la adición de sí mismo como propietario en el recurso Aplicación. Por lo tanto, el problema parece ser específico de la superficie del principal de servicio.
Tras la corrección, los intentos de asignar la propiedad de entidades de servicio que no son agentes mediante el rol de Administrador de ID de agente ahora están bloqueados. La operación produce el siguiente error:
Generar impacto
Adquisición del principal del servicio
Obtener la propiedad de una entidad de servicio proporciona una poderosa base para un ataque. Una vez que un atacante se convierte en propietario, puede agregar credenciales, autenticarse como la entidad de servicio y operar dentro del alcance de sus permisos existentes, como el acceso a la API, los roles de directorio o las integraciones.
El impacto depende de los privilegios asignados a la entidad de servicio objetivo. En entornos donde las entidades de servicio se utilizan ampliamente o poseen permisos elevados, esto puede provocar una escalada significativa. La postura del inquilino también puede influir en el impacto, por ejemplo, en casos de aplicaciones con amplios permisos o configuraciones permisivas.
Antes de la corrección, la función de Administrador de ID de agente permitía asignar la propiedad de entidades de servicio más allá de las identidades relacionadas con el agente, lo que habilitaba capacidades similares a las de funciones como Administrador de aplicaciones, pero sin estar específicamente limitada a los casos de uso del agente.
Cuando el objetivo tiene privilegios
El enfoque de escalada es simple: if Un servidor principal tiene privilegios elevados (roles de directorio, permisos de Graph de alto impacto); al tomar el control de este servidor, se obtienen dichos privilegios. Muchas organizaciones cuentan con este tipo de servidores principales.
Puedes descubrir qué entidades de servicio tienen privilegios y luego atacarlas. En la práctica, esto significa dos tipos de comprobaciones:
- Entidades de servicio con roles de directorio privilegiados: Utilice la API de Microsoft Graph (Beta,
isPrivilegeden las definiciones de roles) para enumerar qué entidades de servicio tienen roles de directorio de nivel de administrador. - Entidades de servicio con permisos de Graph de alto impacto: Consultar las asignaciones de roles de la aplicación a Microsoft Graph para permisos confidenciales (por ejemplo
Directory.ReadWrite.All,RoleManagement.ReadWrite.Directory,Application.ReadWrite.All).
Enumerar los directivos de servicios privilegiados
Ejecute lo siguiente después az login. Requiere jqUtilice una cuenta que pueda leer las asignaciones de roles y las asignaciones de roles de la aplicación (por ejemplo, Administrador de ID de agente).
1. Entidades de servicio con roles de directorio privilegiados
BASE="https://graph.microsoft.com"
roles="$(az rest -m GET --url "${BASE}/beta/roleManagement/directory/roleDefinitions?\$filter=isPrivileged eq true&\$select=id,displayName" -o json)"
u="${BASE}/beta/roleManagement/directory/roleAssignments?\$expand=principal(\$select=id,displayName)&\$top=999"
{
echo -e "SP_NAME\tSP_ID\tROLE"
echo -e "--------\t------\t----"
while :; do
j="$(az rest -m GET --url "$u" -o json 2>/dev/null)" || break
jq -r --argjson roles "$roles" '
($roles.value | map(select(.displayName|test("Reader";"i")|not) | {key:.id, value:.displayName}) | from_entries) as $r
| .value[]
| select(.principal."@odata.type"=="#microsoft.graph.servicePrincipal")
| select($r[.roleDefinitionId] != null)
| [.principal.displayName, (.principal.id // .principalId), $r[.roleDefinitionId]] | @tsv
' <<<"$j"
u="$(jq -r '."@odata.nextLink"//empty' <<<"$j")"
[[ -z "$u" ]] && break
done | sort -t$'\t' -k1,1
} | column -t -s $'\t'
2. Entidades de servicio con permisos de alto impacto para la aplicación Graph
BASE="https://graph.microsoft.com"
PERM_IDS='["9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8","06b708a9-e830-4db3-a914-8e69da51d44f","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9","19dbc75e-c2e2-444c-a770-ec69d8559fc7","dd199f4a-f148-40a4-a2ec-f0069cc799ec","50483e42-d915-4231-9639-7fdb7fd190e5","01c0a623-fc9b-48e9-b794-0756f8e8f067","62a82d76-70ea-41e2-9197-370581804d09","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7"]'
PERM_NAMES='{"9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8":"RoleManagement.ReadWrite.Directory","06b708a9-e830-4db3-a914-8e69da51d44f":"AppRoleAssignment.ReadWrite.All","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9":"Application.ReadWrite.All","19dbc75e-c2e2-444c-a770-ec69d8559fc7":"Directory.ReadWrite.All","dd199f4a-f148-40a4-a2ec-f0069cc799ec":"RoleAssignmentSchedule.ReadWrite.Directory","50483e42-d915-4231-9639-7fdb7fd190e5":"UserAuthenticationMethod.ReadWrite.All","01c0a623-fc9b-48e9-b794-0756f8e8f067":"Policy.ReadWrite.ConditionalAccess","62a82d76-70ea-41e2-9197-370581804d09":"Group.ReadWrite.All","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7":"User-PasswordProfile.ReadWrite.All"}'
GRAPH_SP_ID="00000003-0000-0000-c000-000000000000"
az rest --method GET --url "${BASE}/v1.0/servicePrincipals(appId='${GRAPH_SP_ID}')/appRoleAssignedTo" -o json 2>/dev/null \
| jq -r --argjson ids "$PERM_IDS" --argjson names "$PERM_NAMES" '
["SP_NAME", "SP_ID", "PERMISSIONS"], ["--------", "------", "-------------"],
([.value[] | select(.appRoleId as $rid | $ids | index($rid))] | group_by(.principalId)[] |
[.[0].principalDisplayName, .[0].principalId, ([.[].appRoleId | $names[.]] | join(", "))]) | @tsv
' | column -t -s $'\t'
Nota: Estas técnicas no filtran específicamente a los proveedores de servicios que no son agentes.
Flujo de ataque de extremo a extremo
La figura siguiente tira enumeración (los guiones anteriores) y toma de posesión en una sola vista.
Grabación de demostración
El vídeo muestra el flujo: encontrar una entidad de servicio con privilegios (para la demostración solo buscamos roles de directorio), tomar el control y, a continuación, iniciar sesión.
Demostración: Un usuario de prueba con Administrador de ID de agente toma el control de un privilegiado no agente El usuario principal del servicio (al que se le asignó el rol de Administrador Global) inicia sesión con las nuevas credenciales: escalada de privilegios.
La demostración fue simulado con el Gráfico beta API; nosotros también confirmado el mismo comportamiento del error en v1.0.
Instantánea del mundo real
Analizamos los entornos de los clientes: Administrador de ID de agente Aunque el rol aún no se utiliza de forma generalizada, la configuración para la vía de escalamiento ya está establecida. Aproximadamente el 99% de los inquilinos tener al menos un principal de servicio privilegiado (no necesariamente relacionado con el agente). Un poco más de la mitad Utilizan identidades de agente, y de ellas, casi la mitad tienen más de 100. A medida que más organizaciones asignan la función de gestionar las identidades de agente, la brecha de alcance se convierte en un riesgo real.
Conclusiones:
Microsoft ha abordado este problema, pero la conclusión sigue siendo la misma: los nuevos tipos de identidad suelen basarse en primitivas existentes, lo que puede generar lagunas en la definición del alcance de los permisos de rol. En este caso, se produjo un acceso más amplio del previsto. Es fundamental validar estas suposiciones. Además, el riesgo general se ve influenciado por la postura del inquilino, especialmente en lo que respecta a las entidades de servicio privilegiadas, donde el abuso de propiedad sigue siendo una vía de ataque bien conocida y de gran impacto.
Por qué esto fue fácil de pasar por alto
- Los cambios de propiedad en las entidades de servicio pueden parecer una actividad normal de administración de aplicaciones, a menos que se correlacione quién realizó la acción con el tipo de entidad de servicio de destino.
- Los roles que no estén claramente marcados como altamente privilegiados en la interfaz de usuario de Entra pueden asignarse con menos escrutinio.
- No existe ninguna señal integrada que indique cuándo un rol está actuando fuera de su ámbito previsto; para ello es necesario correlacionar la actividad del rol con el recurso afectado.
Recomendaciones
- Supervisar el uso de roles sensibles: especialmente acciones que impliquen cambios en la propiedad del proveedor de servicios o en las credenciales.
- Alerta sobre cambios en la propiedad del servicio principal.Estos son algunos de los eventos de mayor relevancia en la gobernanza de la aplicación Entra.
- Tratar a los directivos de servicios privilegiados como joyas de la corona.: auditar qué entidades de servicio tienen roles de directorio o permisos de Graph de alto impacto; protegerlas y supervisarlas.
- Creación de credenciales de auditoría para entidades proveedoras de serviciosLos nuevos secretos o certificados sobre entidades de servicio de alto valor deben ser escasos y estar sujetos a revisión.
Detecciones
Nota: Estas detecciones se crearon para el problema descrito, pero dado que ya se ha solucionado, pueden utilizarse como plantillas para identificar patrones similares.
Cuentas asignadas al administrador de ID de agente
- Mediante la CLI de Azure: obtener las asignaciones actuales:
# Role definition ID for Agent ID Administrator
az rest --method GET \
--url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=roleDefinitionId eq 'db506228-d27e-4b7d-95e5-295956d6615f'" \
--query "value[].principalId" -o tsv
- Mediante análisis de registros (registros de auditoría): Consultar las actividades de asignación de roles para el rol de Administrador de ID de agente (ajustar la tabla y el rango de tiempo según sea necesario).
AuditLogs
| where OperationName has "Add member to role"
| where tostring(TargetResources) has "db506228-d27e-4b7d-95e5-295956d6615f" //
Agent ID Administrator
| mv-expand TR = TargetResources
| summarize
Role = max(iff(TR.type == "Role", tostring(TR.displayName), "")),
Assignee = max(iff(TR.type != "Role", tostring(TR.displayName), "")),
AssigneeUPN = max(iff(TR.type != "Role", tostring(TR.userPrincipalName),"")),
AssigneeId = max(iff(TR.type != "Role", tostring(TR.id), ""))
by TimeGenerated,
Result,
Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName),
tostring(InitiatedBy.app.displayName))
| order by TimeGenerated desc Actividades (Análisis de registros / Registros de auditoría)
- Agregar propietario al director del servicio: eventos exitosos. Ajuste el intervalo de tiempo según sea necesario.
let AgentIdAdminActors = dynamic(["obj-id1","obj-id2"]); // principals assigned
Agent ID Administrator
AuditLogs
| where OperationName == "Add owner to service principal"
| where Result == "success"
| where coalesce(InitiatedBy.user.id, InitiatedBy.app.id) in (AgentIdAdminActors)
| order by TimeGenerated desc - Agregar credenciales al director del servicio: eventos exitosos.
AuditLogs
| where OperationName == "Add service principal credentials"
| where Result == "success"
| project
TimeGenerated,
OperationName,
Result,
Actor = coalesce(InitiatedBy.user.userPrincipalName,
InitiatedBy.app.displayName),
TargetSP = TargetResources[0].displayName,
TargetSPId = TargetResources[0].id
| order by TimeGenerated desc Cronograma de divulgación
- 24 de febrero de 2026 – Se identifica una vulnerabilidad.
- 1 de marzo de 2026 – Informe presentado a Microsoft (MSRC)
- 3 de marzo de 2026 – Microsoft abre un caso
- 26 de marzo de 2026 – Microsoft confirmó el comportamiento
- 4 de abril de 2026 – La corrección llegó a la fase de prelanzamiento y el comportamiento ya no era reproducible.
- 9 de abril de 2026 – MSRC ha confirmado que la solución se ha implementado por completo.
Identidades de los agentes Forman parte de la tendencia general hacia las identidades no humanas, diseñadas para la era de los agentes de IA. La plataforma de identidad de agentes de Microsoft representa un importante avance en la forma en que las organizaciones pueden gestionarlas y controlarlas.
Esta investigación pone de relieve un aspecto importante de dicho modelo: las identidades de los agentes dependen de componentes de identidad preexistentes, como las entidades de servicio. Cuando se aplican permisos de rol sobre bases compartidas sin un alcance estricto, el acceso puede extenderse más allá de lo previsto inicialmente. En este caso, esa brecha dio lugar a un acceso más amplio, especialmente cuando intervenían entidades de servicio privilegiadas.
Microsoft ha abordado este problema.Pero refuerza una conclusión más amplia: validar cómo se definen los roles y dónde se aplican los permisos es esencial, especialmente cuando se trata de componentes de identidad compartida.
Para obtener orientación práctica sobre cómo monitorear y fortalecer su entorno, consulte la Recommendations (Lazy section loading) bajo la sección Conclusiones: la sección de arriba.
