En bref

  • Le rôle Agent ID Administrator d'Entra ID permettait de prendre le contrôle de n'importe quel service principal du tenant.
  • Une démonstration publique montre l'élévation depuis ce rôle "agent uniquement" jusqu'au compte Global Administrator.
  • Microsoft a déployé un correctif global le 9 avril 2026 ; toute attribution antérieure du rôle doit être auditée sans délai.

Ce qui s'est passé

Introduit pour orchestrer les nouvelles identités d'agents IA dans Microsoft Entra, le rôle Agent ID Administrator présentait un défaut de périmètre majeur, divulgué publiquement le 28 avril par les chercheurs de Silverfort et confirmé par Microsoft. Présenté comme "agent-only" et destiné à manipuler des objets agent comme les Blueprints et les Agent Identities, il pouvait en pratique modifier l'ownership de presque tous les Application Service Principals du tenant. Concrètement, un opérateur disposant de ce rôle pouvait s'ajouter comme owner d'une principal arbitraire, y déposer ses propres credentials, puis s'authentifier comme cette identité — y compris si elle portait des permissions Microsoft Graph privilégiées ou un rôle d'annuaire à fort impact. Les chercheurs ont enregistré une démonstration où un Agent ID Administrator a hijacké un compte Global Administrator, sans déclencher d'alerte côté détection puisque les opérations restaient nominalement "dans les droits" du rôle attribué. La divulgation responsable date du 1er mars 2026, et le correctif a été déployé sur tous les environnements cloud le 9 avril.

Le correctif retire la capacité du rôle à manipuler les owners des service principals non liés aux agents. Il ne révoque cependant pas les ownerships ou credentials ajoutés pendant la fenêtre d'exposition : les actions effectuées avant le 9 avril 2026 restent persistantes dans l'annuaire et doivent être traitées manuellement. Les équipes IAM concernées par la documentation publique de la fin du modèle Service Principal classique d'Entra doivent considérer cet incident comme un cas d'école de scope overreach.

Pourquoi c'est important

D'après Silverfort, environ 99 % des annuaires d'entreprise hébergent au moins un service principal hautement privilégié, et la moitié des organisations interrogées exécutent déjà des identités d'agents IA en production, certaines en pilotant plus d'une centaine en parallèle. Cette concentration transforme un rôle pensé comme léger en porte d'entrée vers le tenant entier. Pour les défenseurs, l'incident illustre une dette croissante : les contrôles de gouvernance d'identité conçus avant l'ère des agents IA n'anticipent pas la chaîne de privilèges qu'un opérateur d'agents peut accumuler. Comme le rappellent les guides de durcissement Entra avec Conditional Access et MFA, la séparation logique annoncée par un rôle ne suffit plus : il faut auditer son périmètre effectif sur le tenant. Les recommandations s'alignent sur celles de PIM pour les accès privilégiés just-in-time et sur les principes de Zero Trust appliqué à Microsoft 365.

Ce qu'il faut retenir

  • Listez immédiatement toutes les attributions actuelles et passées du rôle Agent ID Administrator dans vos tenants Entra.
  • Recherchez dans le journal d'audit tout évènement Add owner ou Add service principal credentials émis entre le 1er mars et le 9 avril 2026 par un Agent ID Administrator.
  • Faites tourner les secrets et certificats des service principals modifiés dans cette fenêtre, et placez les rôles privilégiés sous PIM.

Comment savoir si mon tenant a été abusé via ce rôle ?

Filtrez le journal d'audit Entra sur les opérations "Add owner to service principal" et "Add service principal credentials" entre le 1er mars et le 9 avril 2026, et croisez l'initiateur avec la liste des comptes ayant détenu Agent ID Administrator. Toute principal modifiée par ce rôle doit être considérée comme suspecte tant que ses secrets, certificats et owners n'ont pas été révoqués.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact