Le rôle Agent ID Administrator d'Entra ID permettait de prendre le contrôle des service principals du tenant. Microsoft a corrigé la faille le 9 avril 2026.
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À propos de l'auteur
Ayi NEDJIMI
Auditeur Senior Cybersécurité & Consultant IA
Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense
ayi@ayinedjimi-consultants.fr
Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.
À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.
Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.
Domaines d'expertise
Ressources & Outils de l'auteur
Articles connexes
Hackers nord-coréens : Calendly piégé pour voler la crypto
Une campagne nord-coréenne se sert d'invitations Calendly piégées pour déployer un stealer Windows/macOS sur les cibles du secteur crypto.
Vercel piraté via Context.ai : OAuth volé, Google compromis
Vercel a divulgué une intrusion partie d'une compromission chez Context.ai. Des tokens OAuth ont permis de pivoter de Google Workspace vers la production.
CVE-2026-32202 : Windows Shell, exploitation active confirmée
Microsoft confirme l'exploitation active de CVE-2026-32202 dans Windows Shell : LNK auto-parsé déclenche une coercition NTLM zero-click. Patch urgent.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire