Entra Agent ID Takeover : Vol Service Principal [2026]

Ce qui s'est passé

Conçu pour orchestrer les nouvelles identités d'agents IA au sein de Microsoft Entra, le rôle Agent ID Administrator souffrait d'un défaut de périmètre critique, divulgué publiquement le 28 avril par les chercheurs de Silverfort puis confirmé par Microsoft. Annoncé comme strictement « agent-only » et censé se limiter aux objets propres à l'écosystème Entra ID Agent ID — Blueprints et Agent Identities —, ce rôle permettait en réalité de modifier des service principals classiques, y compris ceux adossés à des applications d'entreprise hautement privilégiées. Un attaquant disposant de cette délégation pouvait ainsi ajouter ses propres identifiants sur un service principal existant, s'authentifier sous son identité et hériter de permissions Graph étendues. Le scénario ouvre la voie à une élévation de privilèges silencieuse jusqu'au niveau tenant, sans franchir aucune barrière d'authentification multifacteur ni déclencher les alertes associées aux comptes à privilèges.

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.

Cet incident s'inscrit dans une trajectoire déjà documentée d'abus de la couche d'identité machine chez Microsoft. En 2023, la campagne Storm-0558 avait démontré qu'une clé de signature MSA volée permettait de forger des tokens d'accès pour des comptes à privilèges dans Entra ID ; en 2024, des groupes affiliés à Midnight Blizzard exploitaient des service principals OAuth mal configurés pour maintenir une persistance discrète dans des tenants Microsoft 365. Le défaut Agent ID Administrator relève d'une même famille de risques structurels : la confusion entre périmètre annoncé d'un rôle et périmètre technique réellement appliqué par le plan de contrôle Entra. Sa spécificité tient à son contexte d'apparition — la généralisation, depuis fin 2025, des identités d'agents IA autonomes dans les environnements Microsoft 365 Copilot et Azure AI Foundry, qui a poussé de nombreuses organisations à attribuer rapidement ce rôle à des équipes MLOps ou plateforme sans en auditer la portée réelle.

Silverfort, dont l'équipe de recherche a mené la divulgation responsable, souligne que la faille n'a nécessité aucune faille de code exploitable au sens classique : il s'agissait d'un défaut de conception dans la logique d'autorisation associée au rôle, ce qui explique l'absence d'identifiant CVE et son traitement par Microsoft comme un correctif de plateforme silencieux plutôt que comme un bulletin de sécurité numéroté. Cette absence de CVE complique paradoxalement le suivi par les équipes SOC habituées à scanner des identifiants publiés : sans référence CVE, l'alerte a surtout circulé via les canaux de recherche indépendants et les flux MSRC spécialisés, avec un risque réel que des tenants exposés n'aient pas eu connaissance du correctif avant plusieurs semaines. Microsoft a confirmé avoir corrigé le comportement au niveau du plan de contrôle global, sans notification individualisée aux administrateurs de tenants ayant attribué le rôle avant le 9 avril 2026, renvoyant de fait la charge de l'audit rétroactif aux équipes IAM elles-mêmes.

Sur le plan sectoriel, les organisations les plus exposées sont celles ayant adopté tôt les agents IA d'entreprise — services financiers, éditeurs SaaS et grands comptes du secteur public engagés dans des programmes pilotes Copilot Studio — précisément les profils où la pression au déploiement rapide entre en tension avec la rigueur de moindre privilège attendue sur les rôles d'annuaire à fort impact.