TL; DR
Le Microsoft Plateforme d'identité des agents (Preview) donne aux agents IA leurs propres identités dans Entra ID (plans, Les identités des agents et les utilisateurs des agents peuvent ainsi être gérés et sécurisés comme n'importe quel autre principal. Pour gérer ce nouveau plan de contrôle, Microsoft a introduit… Administrateur d'identifiant d'agent rôle. Sur le papier, sa portée se limite aux objets liés à l'agent.
Nous avons découvert que les comptes avec uniquement le rôle d'administrateur d'identifiant d'agent pourrait prendre la relève des principaux de service arbitraires – y compris ceux qui n'ont rien à voir avec l'identité des agents – en devenant propriétaire, puis en ajoutant des informations d'identification et en s'authentifiant en tant que ce principal. Il s'agit d'une prise de contrôle principale à service completDans les immeubles où existent des prestataires de services hautement privilégiés, cela devient un les déplacements verticaux et élévations de privilèges chemin.
Bien que le rôle d'administrateur d'identifiants d'agent ne soit pas encore largement répandu, la plupart des locataires possèdent au moins un principal de service privilégié. Nous avons également constaté que de nombreux locataires utilisent déjà des identités d'agent, parfois à grande échelle. À mesure que l'adoption du rôle d'administrateur d'identifiants d'agent se développe, ce manque de fonctionnalités pourrait engendrer un risque important pour la sécurité des identités.
Nous avons signalé ce comportement au Centre de réponse aux incidents de sécurité Microsoft (MSRC), et il était corrigé dans tous les nuagesLe rôle d'administrateur d'identifiants d'agent ne peut plus gérer les propriétaires des principaux de service non-agents.
Si vous connaissez déjà les concepts décrits ci-dessus, passez directement à la section suivante. Là où la frontière se brise.
L'analyse ci-dessous est basée sur l'ensemble des résultats de nos recherches.
Ce que vous devez savoir
Applications et principes de service dans Entra ID
Enregistrement d'une application dans Microsoft Entra ID crée deux objets liés dans le locataire de maison, qui est le locataire auprès duquel l'application est initialement enregistrée : un objet d'application , l’aspect économique principal de service.
Le application Cet objet sert de définition globale de l'application et décrit sa configuration.
Le principal de service représente l'application en tant qu'identité au sein d'un locataire et constitue l'objet qui s'authentifie, se voit attribuer des rôles et des autorisations, et accède aux ressources. Si l'application est configurée comme multi-locataireDes principaux de service supplémentaires sont créés dans d'autres locataires lorsque l'application y est utilisée, tous basés sur le même objet d'application.
Microsoft Entra ID comporte différents types de prestataires de services, tels que service d'application principaux et identités gérées. An principal du service d'application est l'instance d'une application dans un locataire, créée à partir de l'objet application.
Dans ce blog, nous nous concentrons uniquement sur ce type, car le comportement décrit ici s'applique spécifiquement aux principaux de service d'application.
Microsoft Entrer l'ID de l'agent
Microsoft Entrer l'ID de l'agent vous permet de traiter les agents IA comme des entités de premier ordre dans Entra IDCela inclut le contrôle d'accès conditionnel, la gouvernance et la gestion du cycle de vie des agents d'IA dans votre environnement. En interne, cette solution repose sur… Plateforme d'identité d'agent MicrosoftMicrosoft Graph est un cadre d'identité et d'autorisation pour les agents d'IA. Il introduit de nouveaux types d'objets (modèles, identités d'agents, utilisateurs d'agents), tous gérables via Microsoft Graph (actuellement en version bêta uniquement). La plateforme est encore en préversion, mais les rôles sont déjà disponibles publiquement pour attribution et utilisation.
En résumé, la plateforme introduit :
- Blueprints: Les modèles qui définissent et créent les identités des agents.
- Principes directeurs: L'instance spécifique au locataire d'un modèle lorsqu'il est ajouté à un locataire.
- Identités des agents: Principals de service spéciaux utilisés par les agents d'IA pour s'authentifier auprès des API et des services.
- Utilisateurs d'agentsCe sont des objets optionnels de type utilisateur destinés aux agents qui ont besoin d'un UPN ou d'une adresse e-mail et qui sont utilisés dans les flux d'authentification « pour le compte de ».
Pourquoi cela compte: Les identités des agents reposent sur des éléments d'annuaire familiers : applications, principaux de service et utilisateurs. C'est précisément sur cette base commune que réside notre découverte.
Rôle d'administrateur d'identifiant d'agent
Microsoft a ajouté le Administrateur d'identifiant d'agent rôle consistant à gérer le nouveau plan de contrôle d'identité des agents. Selon la documentation, il est limité à :
En d'autres termes: Uniquement des affaires d'agentAttention, il ne s'agit pas de tous les responsables de service. Cette distinction est importante. Les responsables de service sont les acteurs clés de l'automatisation, de l'intégration continue et du déploiement continu (CI/CD), des outils de sécurité et des intégrations privilégiées. Quiconque les contrôle contrôle une part importante de l'environnement.
Une autre observation: la documentation indique que ce rôle est privilégiéCependant, dans l'interface utilisateur d'Entra (qui repose sur les définitions de rôles de l'annuaire bêta), cela n'apparaît pas comme tel. De ce fait, les administrateurs peuvent l'attribuer sans la même rigueur qu'ils appliqueraient aux rôles privilégiés.
Microsoft a confirmé l'écart entre l'interface utilisateur d'Entra et la documentation. en ce qui concerne l’indicateur « privilégié » sera réparé.
Là où la frontière se brise
Voici ce que nous avons constaté : un utilisateur disposant du rôle d’administrateur d’identifiants d’agent peut s’ajouter comme propriétaire de principaux de service autres que les identités liées aux agents, y compris des principaux de service arbitraires au sein du locataire. Il peut ensuite ajouter des informations d’identification et s’authentifier en tant qu’applications correspondantes.
Étape 1: ajouterpropriétaire(s) (réussi contre des prestataires de services non mandataires ; vous pouvez vous ajouter vous-même ou ajouter d’autres prestataires) :
Étape 2 : Ajouter les identifiants (n'a fonctionné qu'après que nous soyons devenus propriétaires) :
La ligne de fond: La propriété est un prise de contrôle primitive – Devenez propriétaire, puis ajoutez un secret et authentifiez-vous en tant que principal de service.
Bien que le rôle soit destiné à agent en matière d'identité, en pratique, cela peut changer la propriété sur tout principal de service.
Pourquoi nous pensons que cela se produit : Certaines identités d'agent sont implémentées en tant que principaux de service (et types associés). Ce rôle comporte des actions telles que :
microsoft.directory/agentIdentities/owners/updatemicrosoft.directory/agentIdentityBlueprintPrincipals/owners/update
Ainsi, les administrateurs peuvent gérer les propriétaires des objets d'agent. Si ces contrôles ne se limitent pas strictement aux principaux de service associés à l'agent, l'autorisation s'étend au plan général des principaux de service.
Un écart classique de cadrage lorsqu'un type d'objet hérite d'un autre.
Nous faisions pas voir la même chose pour applicationsL'ajout de soi-même en tant que propriétaire de la ressource Application a été refusé. Le problème semble donc spécifique à la surface du principal de service.
Suite à cette correction, les tentatives d'attribution de propriété à des principaux de service non-agents à l'aide du rôle d'administrateur d'ID d'agent sont désormais bloquées. L'opération génère l'erreur suivante :
Impact
Prise de contrôle du principal de service
S'approprier un principal de service constitue un point d'appui majeur pour une attaque. Une fois propriétaire, un attaquant peut ajouter des identifiants, s'authentifier en tant que principal de service et agir dans le cadre des autorisations existantes, telles que l'accès aux API, les rôles d'annuaire ou les intégrations.
L'impact dépend des privilèges attribués au principal de service ciblé. Dans les environnements où les principaux de service sont largement utilisés ou disposent de permissions élevées, cela peut entraîner une escalade significative. La posture du locataire peut également influencer cet impact, par exemple dans le cas d'applications bénéficiant d'un consentement général ou de configurations permissives.
Avant la correction, le rôle d'administrateur d'ID d'agent permettait d'attribuer la propriété de principaux de service au-delà des identités liées à l'agent, ce qui permettait effectivement des capacités similaires à celles de rôles tels qu'administrateur d'application, mais sans être spécifiquement limité aux cas d'utilisation des agents.
Lorsque la cible est privilégiée
L'angle d'escalade est simple : if Un principal de service possède des droits élevés (rôles d'annuaire, autorisations Graph importantes) ; en prendre le contrôle vous confère ces droits. De nombreuses organisations utilisent de tels principaux de service.
Vous pouvez identifier les principaux de service privilégiés et les cibler. Concrètement, cela implique deux types de vérifications :
- Principaux de service disposant de rôles d'annuaire privilégiés: Utilisez l'API Microsoft Graph (Bêta,
isPrivileged(sur les définitions de rôles) pour lister les principaux de service qui détiennent des rôles d'annuaire de niveau administrateur. - Principaux de service disposant d'autorisations Graph à fort impactInterrogez Microsoft Graph pour obtenir les autorisations sensibles relatives aux attributions de rôles d'application (par exemple).
Directory.ReadWrite.All,RoleManagement.ReadWrite.Directory,Application.ReadWrite.All).
Énumérer les principaux responsables de service privilégiés
Exécutez la commande suivante après az login. A besoin jqUtilisez un compte qui peut lire les attributions de rôles et les attributions de rôles d'application (par exemple, administrateur d'ID d'agent).
1. Principaux de service disposant de rôles d'annuaire privilégiés
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. Principaux de service disposant d'autorisations d'application Graph à fort impact
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'
À noter: Ces techniques ne permettent pas de filtrer spécifiquement les principaux de service non-agents.
Flux d'attaque de bout en bout
La figure ci-dessous tire énumération (les scripts ci-dessus) et prise de contrôle en une seule vue.
Enregistrement de démonstration
La vidéo montre le processus : trouver un principal de service privilégié (nous n’avons recherché que les rôles d’annuaire pour la démonstration), en prendre le contrôle, puis se connecter.
Démo : Un utilisateur test avec Administrateur d'identifiant d'agent prend le contrôle d'un privilégié non-agent Le principal de service (qui a le rôle d'administrateur global) se connecte ensuite avec les nouvelles informations d'identification – élévation de privilèges.
La démo était simulé grâce à la fonction Graphique bêta API ; nous également confirmé le même comportement du bug sur v1.0.
Aperçu du monde réel
Nous avons examiné les environnements clients : Administrateur d'identifiant d'agent Ce rôle n'est pas encore largement utilisé, mais la procédure d'escalade l'est déjà. Environ 99 % des locataires disposer d'au moins un principal de service privilégié (pas nécessairement lié à un agent). Un peu plus de la moitié L'utilisation d'identités d'agents est répandue, et parmi celles-ci, près de la moitié en possèdent plus de 100. À mesure que davantage d'organisations confient la gestion des identités d'agents à des personnes dédiées, le manque de responsabilités devient un risque réel.
Points clés à retenir
Microsoft a pris en compte ce problème, mais le constat demeure : les nouveaux types d’identité sont souvent construits sur des primitives existantes, ce qui peut engendrer des lacunes dans la définition des autorisations de rôle. Dans ce cas précis, cela a entraîné un accès plus étendu que prévu. Il est donc essentiel de valider ces hypothèses. Par ailleurs, le risque global est influencé par la sécurité du locataire, notamment en ce qui concerne les principaux de service privilégiés, où l’abus de propriété reste une méthode d’attaque bien connue et dévastatrice.
Pourquoi était-ce si facile à rater ?
- Les changements de propriétaire sur les principaux de service peuvent ressembler à une activité normale d'administrateur d'application, sauf si vous établissez une corrélation entre l'auteur de l'action et le type de principal de service cible.
- Les rôles qui ne sont pas clairement identifiés comme hautement privilégiés dans l'interface utilisateur d'Entra peuvent être attribués avec moins de rigueur.
- Il n'existe aucun signal intégré permettant de repérer les cas où un rôle agit en dehors de son périmètre prévu ; cela nécessite de corréler l'activité du rôle avec la ressource concernée.
Recommandations
- Surveiller l'utilisation des rôles sensibles: notamment les actions impliquant la propriété du principal de service ou des modifications d'identifiants.
- Alerte concernant les changements de propriétaire du principal de service: ce sont parmi les événements les plus importants en matière de gouvernance de l'application Entra.
- Traitez les directeurs de service privilégiés comme des joyaux de la couronne.: auditer quels principaux de service possèdent des rôles d'annuaire ou des autorisations Graph à fort impact ; les protéger et les surveiller.
- Création d'identifiants d'audit sur les principaux de serviceLes nouveaux secrets ou certificats concernant des principaux de service à forte valeur ajoutée doivent être rares et faire l'objet d'un examen.
Détections
NoteCes détections ont été créées pour le problème décrit, mais puisqu'il a été corrigé, elles peuvent être utilisées comme modèles pour identifier des schémas similaires.
Comptes auxquels l'administrateur d'identifiant d'agent a été attribué
- Via Azure CLI: obtenir les affectations actuelles :
# 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
- Via Log Analytics (AuditLogs): interroger les activités d'attribution de rôle pour le rôle d'administrateur d'ID d'agent (ajuster la table et la plage horaire selon les besoins).
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 Activités (Analyse des journaux / Journaux d'audit)
- Ajouter le propriétaire au responsable du service: événements réussis. Ajustez la plage horaire selon les besoins.
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 - Ajouter des informations d'identification au principal de service: événements réussis.
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 Calendrier de divulgation
- 24 février 2026 – Vulnérabilité identifiée
- 1er mars 2026 – Rapport soumis à Microsoft (MSRC)
- 3 mars 2026 – Dossier ouvert par Microsoft
- 26 mars 2026 – Microsoft a confirmé ce comportement
- 4 avril 2026 – Le correctif a atteint le stade de pré-publication et le comportement n'était plus reproductible.
- 9 avril 2026 – MSRC a confirmé que le correctif a été entièrement déployé.
Identités des agents Elles s'inscrivent dans une tendance plus large vers les identités non humaines, conçues pour l'ère des agents IA. La plateforme Microsoft Agent Identity représente une avancée majeure dans la manière dont les organisations peuvent les gérer et les gouverner.
Cette recherche met en lumière un aspect important de ce modèle : l’identité des agents repose sur des composants d’identité existants, tels que les principaux de service. Lorsque les permissions de rôle sont appliquées à des infrastructures partagées sans définition précise du périmètre, l’accès peut dépasser les limites initialement prévues. Dans ce cas précis, cette lacune a entraîné un accès plus large, notamment en présence de principaux de service privilégiés.
Microsoft a résolu ce problème.mais cela renforce un constat plus général : il est essentiel de valider la portée des rôles et l’application des autorisations, en particulier lorsqu’il s’agit de composants d’identité partagés.
Pour obtenir des conseils pratiques sur la surveillance et le renforcement de votre environnement, consultez le Recommandations sous le Points clés à retenir section ci-dessus.
