Une seule approbation d’agent IA malveillant pourrait ouvrir l’accès à l’environnement cloud Microsoft d’une entreprise. Les attaquants pourraient ensuite créer d’autres identités d’agents en utilisant les autorisations accordées par la demande de consentement initiale.
Proofpoint a révélé BluePhishing le 9 novembre 2026, montrant comment les blueprints d’agents Microsoft Entra malveillants peuvent exploiter des demandes de consentement légitimes pour obtenir un accès au cloud. Les attaquants peuvent créer des identités d’agents et obtenir des jetons porteurs des autorisations approuvées. Les chercheurs n’ont pas observé cette technique dans des attaques réelles.
« Les utilisateurs sont conditionnés à faire confiance aux agents IA et à leur accorder de l’autonomie, mais les contrôles de sécurité et la sensibilisation autour de ces identités sont encore à la traîne », a déclaré Yaniv Miron, directeur de la recherche sur les menaces chez Proofpoint.
Selon Miron, BluePhishing montre comment des techniques de phishing familières peuvent être adaptées aux agents IA, au risque de transformer une seule approbation de consentement en centaines d’identités de confiance au sein d’une organisation.
Comment BluePhishing crée des identités d’agents
BluePhishing étend le phishing par consentement OAuth, qui incite les utilisateurs à autoriser des applications malveillantes sans voler leurs mots de passe. La campagne de phishing par code d’appareil N0va a de même détourné l’authentification légitime de Microsoft, mais selon un mécanisme différent.
Dans sa divulgation de recherches du 9 novembre, Proofpoint a montré comment des attaquants pouvaient cibler Microsoft Entra Agent ID.
Un attaquant crée un blueprint d’agent dans un tenant qu’il contrôle, configure ses autorisations, puis envoie un lien de consentement à une cible. L’approbation établit un principal de blueprint dans le tenant de la victime.
Le principal est ainsi créé AgentIdentity.CreateAsManager, ce qui permet à l’attaquant de créer des identités d’agents en utilisant les identifiants du blueprint et l’identifiant d’objet d’un sponsor issu du tenant de la victime. Ces identités peuvent obtenir des jetons porteurs des autorisations configurées pour être héritées et accordées par le consentement.
Le consentement administrateur peut autoriser des autorisations d’application à l’échelle du tenant. Le consentement d’un utilisateur standard est limité à l’accès délégué autorisé, qui nécessite une authentification supplémentaire pour être utilisé dans les flux d’agents.
Proofpoint a démontré l’accès à l’aide de User.Read.All et Group.Read.All, permettant d’effectuer des requêtes Microsoft Graph pour obtenir des informations sur l’annuaire. L’attaque n’accorde pas automatiquement un accès administratif illimité.
Risques liés aux identités d’agents et mesures de protection
Un blueprint peut prendre en charge jusqu’à 250 identités d’agents. La documentation de Microsoft sur les autorisations confirme que les autorisations approuvées peuvent s’étendre à ces identités lorsque les conditions d’héritage sont remplies. Les autorisations héritées ne sont pas affichées individuellement dans les vues d’administration standard d’Entra.
Ces limites de visibilité aggravent les défis liés à la gestion des identités des agents IA, notamment en matière de propriété et de réexamen des accès. Microsoft a également introduit des contrôles de sécurité supplémentaires pour les agents IA, même si certaines fonctionnalités restent en préversion.
Proofpoint a cité une annonce de Microsoft autorisant les utilisateurs Entra par défaut à créer des blueprints d’agents à partir de novembre 2026. Les organisations doivent vérifier l’état du déploiement dans leur tenant et donner la priorité aux mesures de protection suivantes :
- Restreindre le consentement et la création : Examiner les politiques de consentement Entra et limiter les approbations de blueprints non fiables ainsi que les privilèges de mise à disposition d’agents.
- Auditer les identités et les autorisations : Désigner des propriétaires, examiner les principaux de blueprints et les identités associées, puis supprimer les accès excessifs.
- Appliquer le principe du moindre privilège : Limiter les autorisations d’application et appliquer les politiques d’accès conditionnel pour les agents.
- Surveiller les activités suspectes : Enquêter sur les octrois de consentement inhabituels, la création d’agents, les connexions et l’activité des jetons en utilisant les identifiants associés aux blueprints.
- Endiguer les accès non autorisés : Révoquer les autorisations malveillantes, désactiver les principaux de blueprints concernés, puis enquêter sur les identités et les jetons associés.
- Tester les plans de réponse aux incidents : Simuler un consentement malveillant et la mise à disposition non autorisée d’agents, notamment la révocation et la préservation des éléments d’audit.
Bien que BluePhishing n’ait pas été observé dans des attaques actives, sa capacité démontrée à créer des identités d’agents par le biais d’un consentement légitime révèle une faille dans la gouvernance des accès au cloud. Les organisations doivent s’assurer qu’elles peuvent identifier et révoquer les accès pour chaque identité associée à un blueprint suspect.
Pour aller plus loin : sécuriser les agents IA en tant que clients d’API nécessite des jetons strictement limités, une surveillance des appels d’API et des contrôles qui limitent l’utilisation abusive des accès autorisés.