Comment bloquer les agents IA de Microsoft Entra

Points clés à retenir

Microsoft Entra peut bloquer automatiquement les agents IA signalés comme présentant un risque élevé avant qu'ils n'accèdent aux ressources.
Une politique d'accès conditionnel ciblant les identités des agents assure le contrôle au niveau de l'authentification, empêchant ainsi les agents à risque d'obtenir des jetons.
L'exécution préalable de la politique en mode « rapport uniquement » permet d'identifier les faux positifs et d'éviter de perturber les flux de travail légitimes basés sur l'IA.
Les évaluations des risques liés aux agents s'appuient sur Microsoft Entra ID Protection, qui analyse en permanence l'identité des agents et peut déclencher des mesures de sécurité immédiates lorsque les niveaux de risque augmentent.
Cette protection s'applique uniquement aux identités d'agents ; les agents opérant via des autorisations utilisateur de type « au nom de » (OBO) nécessitent des contrôles d'accès conditionnel distincts, axés sur l'utilisateur.

Les agents IA autonomes s'authentifient avec leur propre identité dans votre tenant Microsoft Entra, indépendamment de tout utilisateur ; ainsi, un agent compromis ou défaillant équivaut en réalité à un attaquant disposant d'identifiants valides et agissant à la vitesse de l'ordinateur.

Microsoft Entra ID Protection évalue le niveau de risque associé aux identités des agents de la même manière qu'il évalue celui des utilisateurs, et vous pouvez bloquer les agents à haut risque au niveau de l'authentification avant même qu'ils n'accèdent à une ressource.

Ce blog est un guide détaillé qui vous explique comment configurer une politique de sécurité adaptée pour les agents IA, afin de vous aider à empêcher les agents à haut risque d'accéder à Microsoft Entra.

Bloquer les agents à haut risque à l'aide d'une politique d'accès conditionnel

Il s'agit là du bloc technique approprié. Une politique d'accès conditionnel vise à contrôler l'accès au niveau de l'authentification et pas seulement au niveau de l'interface utilisateur.

Remarque : les agents « On-behalf-of » ne sont pas concernés par cette politique. Si un utilisateur se connecte à un agent, ce dernier peut accéder aux ressources en utilisant les autorisations déléguées de cet utilisateur. Dans ce scénario, la politique d’accès conditionnel s’applique à l’utilisateur et non à l’identité de l’agent ; par conséquent, l’alerte de risque liée à l’agent ne se déclenche pas.

Les étapes :

1. Connectez-vous à entra.microsoft.com en tant qu'administrateur global.

2. Accédez à Entra ID > Accès conditionnel > Politiques.

3. Cliquez sur « Nouvelle stratégie ».

4. Donnez un nom à la stratégie (par exemple : CA-Block-Entra-Admin-Center-Non-Admins)

5. Cliquez sur « Utilisateurs et agents ». Sous « À quoi s'applique cette politique ? », sélectionnez « Agents » :

Inclure: toutes les identités d'agent

6. Dans la section « Ressources cibles », sélectionnez « Ressources » (anciennement « Applications cloud »).

7. Sélectionnez « Inclure » > « Toutes les ressources » (anciennement « Toutes les applications cloud »).

8. Cliquez sous « Conditions ».

9. Cliquez sous « Risque lié à l'agent » (Aperçu) et sélectionnez « Configurer » > « Oui » > « Élevé ».

10. Cliquez sur « Terminé ».

11. Sous « Autorisation », sélectionnez « Bloquer l'accès ».

12. Réglez l'option « Activer la politique » sur « Activé » (ou sur « Rapport uniquement » pour les premiers tests).

13. Cliquez sur Créer.

Bonnes pratiques : application des politiques

Exécutez la stratégie en mode « Rapport uniquement » pendant au moins une semaine avant de la mettre en service. Pendant cette période, consultez la section Entra ID > Surveillance > Journaux de connexion et filtrez les résultats par identité d'agent pour voir ce qui aurait été bloqué.

Recherchez en particulier les agents légitimes qui sont signalés, car il s'agit là de vos faux positifs, et vous devez les résoudre avant que l'application de la politique ne commence. Ne passez en mode « Activé » que lorsque vous êtes certain que la politique identifie bien les entités concernées et qu'elle ne perturbe pas les flux de travail réels.

Pourquoi c'est important

À mesure que les agents IA accèdent aux systèmes d'entreprise, ils deviennent en réalité des identités non humaines au sein de votre tenant. Un agent compromis peut utiliser des identifiants valides pour accéder à des ressources, automatiser des actions et aggraver les risques à une vitesse que les humains peuvent à peine imaginer. Limiter l'accès des agents à haut risque constitue une couche de défense importante pour plusieurs raisons :

Elle bloque la menace avant qu'elle n'atteigne vos données : la mise en œuvre s'effectue au niveau de l'authentification, de sorte qu'un agent signalé n'obtient tout simplement pas le jeton, et vous n'avez pas à réparer les dégâts une fois qu'il a déjà accédé à une ressource.
C'est automatique et instantané : le blocage se déclenche dès qu'un signal de risque est détecté par Identity Protection. Ainsi, dès qu'un agent est classé comme présentant un risque élevé, y compris lorsque vous confirmez qu'il a été compromis, la mesure de sécurité est appliquée sans intervention humaine.
Il s'adapte là où la vérification manuelle ne suffit pas : les agents apparaissent plus vite qu'on ne peut les répertorier. En bloquant ceux qui présentent un risque élevé, vous laissez le moteur de gestion des risques se charger du triage, au lieu de devoir vérifier chaque agent à la main.
C'est simple : une politique bien ciblée bloque uniquement les agents à haut risque, sans affecter vos utilisateurs ni les agents sains, ce qui offre une protection efficace sans nuire à la productivité.

Foire aux questions

Que signifie « risque lié à l'agent » et comment est-il évalué ?

Le risque lié aux agents provient de Microsoft Entra ID Protection, qui évalue les identités des agents de la même manière qu'il évalue les utilisateurs et les connexions à risque. Vous pouvez consulter les agents signalés dans le rapport « Agents à risque » du centre d'administration Entra, où les détections de risque restent visibles pendant 90 jours maximum, avec des détails sur le nom d'affichage de l'agent, son état de risque, son niveau de risque, son type et ses sponsors. Un agent peut également être manuellement classé comme présentant un risque élevé lorsque vous confirmez qu'il a été compromis.

Qu'arrive-t-il à un agent légitime qui est signalé comme présentant un risque élevé ?

Il est empêché de demander des jetons, comme n'importe quel autre agent à haut risque, ce qui constitue un faux positif et peut perturber un véritable flux de travail. C'est pourquoi il est recommandé d'appliquer d'abord la politique en mode « Rapport uniquement » : activez-la dans ce mode pendant au moins une semaine avant de la mettre en application, puis consultez les journaux de connexion pour voir ce qui aurait été détecté.

Cette politique s'applique-t-elle aux agents agissant pour le compte d'un utilisateur ?

Non. Dans le flux « au nom de » (OBO), un utilisateur se connecte à l'application de l'agent, et l'agent accède aux ressources à l'aide des autorisations déléguées par l'utilisateur. Dans ce flux, le sujet de l'accès conditionnel est l'utilisateur, et non l'identité de l'agent ; par conséquent, le risque lié à l'agent n'est pas évalué, et cette stratégie n'a aucun effet. Pour contrôler ce à quoi les agents OBO peuvent accéder, vous devez définir une stratégie d'accès conditionnel ciblant l'utilisateur et dont la portée est limitée aux ressources concernées.

À propos de
Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

Comment bloquer les agents IA à haut risque dans Microsoft Entra