Comment sécuriser les agents IA dans Microsoft 365 grâce à Microsoft Entra Agent ID ?
15 octobre 2026
Aucun commentaire
Lire la suite »
Un agent IA peut désormais rechercher une information dans SharePoint, appeler une API, générer un document ou déclencher une action sans qu’un utilisateur ait besoin de lui détailler chaque étape.
Cette capacité offre des gains de productivité importants, mais elle change aussi la nature du risque : un agent n’est plus seulement un outil, c’est un acteur logiciel capable d’accéder à des données et d’agir dans le système d’information.
La question n’est donc plus uniquement « Que peut faire cet agent ? », mais aussi « Sous quelle identité agit-il, avec quels droits et sous la responsabilité de qui ? »
Microsoft Entra Agent ID apporte une réponse dédiée à la gestion des identités non humaines. Découvrez comment cette solution peut constituer le point de départ d’une gouvernance Microsoft 365 plus claire, plus sécurisée et mieux maîtrisée.
Tous les agents n’accèdent pas aux ressources de la même manière. Microsoft distingue trois scénarios principaux pour comprendre et encadrer leurs droits d’accès :
L’agent assistif agit au nom d’un utilisateur connecté. Dans le flux OBO (On-Behalf-Of, « au nom de »), il reçoit un jeton représentant l’utilisateur et utilise ses autorisations déléguées. C’est notamment le cas d’un assistant qui prépare une réponse à partir de la boîte Outlook de son utilisateur.
L’agent autonome agit sans utilisateur présent, avec sa propre identité et ses propres autorisations. Il peut, par exemple, traiter des tickets chaque nuit ou analyser des journaux de sécurité. Ce modèle est puissant, mais il rend le principe du moindre privilège indispensable : une autorisation trop large reste active même lorsque personne ne surveille l’agent.
Le compte utilisateur d’agent correspond à un travailleur numérique disposant d’un compte dédié, éventuellement associé à une boîte aux lettres, un calendrier et un accès aux ressources Microsoft 365. Ce compte ne remplace pas l’identité de l’agent : il ajoute une couche supplémentaire lorsque le scénario nécessite des ressources conçues pour un utilisateur.
À retenir : avant de configurer une politique de sécurité, il est essentiel d’identifier le modèle d’accès utilisé par l’agent. Les règles de sécurité ne s’appliquent pas de la même manière selon qu’il utilise les droits d’un utilisateur, sa propre identité ou un compte dédié.
Microsoft Entra Agent ID introduit une distinction essentielle entre le blueprint d’identité et l’identité propre à chaque agent.
Le blueprint sert de modèle : il définit le rôle d’une famille d’agents, ses capacités, ses sources autorisées et les règles de sécurité applicables. Chaque agent créé à partir de ce modèle reçoit ensuite sa propre identité, tout en héritant des garde-fous définis.
Cette approche permet d’éviter de traiter chaque agent comme une exception isolée.
Une DSI peut, par exemple, définir un blueprint « Onboarding RH » autorisant la consultation d’une base documentaire précise et l’ouverture d’un ticket, tout en interdisant l’envoi de messages externes.
Les agents déployés dans différents établissements conservent ainsi un périmètre de sécurité commun, tout en restant identifiables individuellement dans les journaux.
Mais la gouvernance ne se limite pas aux aspects techniques.
Chaque identité doit également être associée à deux responsables :
Un sponsor métier, responsable de la pertinence de l’agent et de son cycle de vie.
Un propriétaire technique (owner), responsable de son fonctionnement et de la gestion des incidents.
Cette séparation permet de réduire le risque d’agents orphelins, c’est-à-dire des agents qui continuent de fonctionner après le départ de leur créateur, sans personne pour réexaminer leurs accès ou décider de leur désactivation.
Depuis juillet 2026, Microsoft indique que Copilot Studio crée automatiquement un Microsoft Entra Agent ID pour chaque nouvel agent.
L’enjeu se déplace donc progressivement de la création de l’identité vers sa gouvernance : modèle utilisé, droits accordés, responsables désignés et règles de désactivation.
À retenir : un agent IA doit être considéré comme un véritable actif de l’entreprise, avec un objectif, un périmètre d’action, un sponsor et un propriétaire clairement identifiés. Il ne doit pas devenir un simple script oublié dans un environnement de test.
Le principe du Zero Trust reste le même : ne jamais accorder un accès permanent par défaut, vérifier le contexte et limiter chaque action au strict nécessaire.
Microsoft Entra étend cette approche aux agents IA grâce à l’accès conditionnel et aux signaux de risque.
Pour un agent autonome, une politique peut cibler directement son identité ou son blueprint.
Elle peut notamment permettre de :
Bloquer les agents présentant un risque.
Restreindre l’accès à certaines ressources sensibles.
Appliquer des conditions d’accès adaptées au contexte.
Le ciblage au niveau du blueprint présente un avantage important : tout nouvel agent créé à partir de ce modèle peut bénéficier automatiquement de la même politique de sécurité.
Des attributs de sécurité personnalisés permettent également de regrouper les agents par métier, environnement ou niveau de sensibilité.
Concernant les autorisations, il est préférable de privilégier des droits précis, limités et régulièrement réévalués.
Par exemple, un agent de support n’a pas besoin d’un accès en écriture à l’ensemble de SharePoint. De même, un agent de reporting n’a pas nécessairement besoin de pouvoir envoyer des e-mails vers l’extérieur.
Les accès temporaires, les revues périodiques et les journaux d’authentification permettent aux équipes de sécurité et de conformité de contrôler ces autorisations.
Point de vigilance : l’accès conditionnel protège les ressources dont l’authentification passe par Microsoft Entra. Un agent utilisant directement une clé API peut emprunter un autre chemin d’accès et ne pas être soumis aux mêmes contrôles.
L’identité de l’agent ne constitue donc pas une protection universelle. Elle doit s’accompagner d’une architecture d’accès cohérente et d’un contrôle des outils utilisés.
À retenir : l’identité permet d’appliquer des politiques de sécurité, mais c’est l’association entre permissions minimales et contrôle des chemins d’accès qui réduit réellement les risques.
Une gouvernance efficace doit accompagner l’agent IA tout au long de son cycle de vie, depuis sa création jusqu’à sa désactivation.
Trois étapes permettent de mettre en place cette démarche sans freiner l’innovation.
1. Inventorier les agents
Recensez les agents déployés dans Copilot Studio, Microsoft 365 et Power Platform, ainsi que, lorsque cela est possible, les agents tiers ou locaux.
Pour chacun, documentez son usage, son modèle d’accès, les données exploitées et son sponsor.
2. Standardiser les pratiques
Créez des blueprints réutilisables, mettez en place une validation avant la mise en production et associez des autorisations limitées à chaque cas d’usage.
Les agents peuvent ensuite être référencés et supervisés à l’aide du registre et du plan de contrôle Microsoft Agent 365, selon les fonctionnalités disponibles.
3. Surveiller et désactiver les agents
Exploitez les journaux de connexion, les traces d’activité et les données de télémétrie pour détecter d’éventuels comportements anormaux.
Planifiez des revues d’accès régulières et définissez une date de fin d’utilisation. Lorsqu’un agent n’est plus nécessaire, désactivez son identité, révoquez ses secrets et supprimez ses connexions inutiles.
Cette méthode offre une meilleure visibilité aux équipes informatiques sans imposer un processus identique à tous les métiers.
Elle facilite également les audits, puisque l’entreprise peut identifier qui a autorisé un agent, quelles données il peut consulter, quelles actions il a réalisées et quand ses accès seront réévalués.
Un agent IA est une identité non humaine à gouverner, et pas seulement une fonctionnalité à activer.
Les blueprints permettent d’appliquer des règles de sécurité cohérentes à plusieurs agents et d’éviter les configurations isolées.
Le sponsor métier et le propriétaire technique garantissent une responsabilité clairement définie.
L’accès conditionnel, le principe du moindre privilège et les journaux d’activité doivent être adaptés au modèle d’accès utilisé.
La gouvernance doit couvrir l’ensemble du cycle de vie de l’agent, y compris la révision de ses droits et sa désactivation.
Avec Microsoft Entra Agent ID, Microsoft propose d’intégrer les agents IA dans un cadre de sécurité familier aux DSI : une identité, des autorisations, des contrôles d’accès, une traçabilité et un cycle de vie maîtrisé.
Cette approche ne supprime pas tous les risques liés à l’intelligence artificielle, notamment les injections de prompt ou les risques de propagation entre agents, mais elle constitue une base concrète pour mieux les maîtriser.
La première décision à prendre n’est donc pas de choisir le modèle d’IA le plus puissant, mais de définir sous quelle identité l’agent agira, quels droits lui seront accordés et qui sera responsable de ses accès.
En structurant cette gouvernance dès le départ, les entreprises peuvent déployer leurs agents IA plus sereinement, limiter les risques de sécurité et conserver une meilleure maîtrise de leur environnement Microsoft 365.
Vérifier les prérequis de licence et la disponibilité régionale des contrôles Entra Agent ID, Agent 365 et de l’accès conditionnel pour les agents à la date de publication.
Conserver la distinction entre identité d’agent, blueprint et compte utilisateur d’agent.
Confirmer les libellés français utilisés dans l’interface Microsoft présentée dans les captures d’écran.
Faire relire l’article par un référent sécurité si les exemples de permissions ou de flux OAuth doivent être adaptés à un contexte client.
Microsoft Learn — What is Microsoft Entra Agent ID? — Identités, blueprints et intégrations Microsoft et tierces.
Microsoft Learn — Microsoft Entra security for AI overview — Modèles d’agents, risques, Zero Trust, gouvernance et cycle de vie.
Microsoft Learn — Conditional Access for Agents in Microsoft Entra — Flux d’accès, ciblage des identités et des blueprints, limites de l’accès conditionnel.
Microsoft Copilot Blog — New and improved: GitHub Copilot harness, agent skills, and richer context — Création automatique d’un Entra Agent ID pour les nouveaux agents Copilot Studio depuis juillet 2026 et télémétrie.
Microsoft Security Blog — Microsoft Agent 365 now generally available — Registre, observabilité, gouvernance et sécurisation des agents Microsoft, tiers et locaux.
