Agents IA et sécurité Microsoft 365 : la nouvelle surface d'attaque à auditer

Il y a deux ans, la question était « faut-il activer Copilot ? ». En 2026, elle a changé de forme : vos collaborateurs créent et installent des agents IA - dans Copilot Studio, dans Teams, chez des éditeurs SaaS, et de plus en plus sur leur propre poste. Microsoft a donné un nom de produit au désordre qui en résulte (Agent 365, un registre et un plan de contrôle pour les agents), ce qui dit assez bien où en est le sujet. Le secteur parle d'agent sprawl : la prolifération d'agents.

Un agent n'est pas une fenêtre de conversation. C'est un logiciel qui agit : il lit des boîtes mail, écrit des fichiers, appelle des API, déclenche des workflows. Chaque agent est donc une identité dotée de permissions - un utilisateur non humain dans votre tenant - et la plupart des organisations n'en tiennent aucun inventaire.

Pourquoi c'est un problème de permissions, pas un problème d'IA #

Tout ce que l'on savait déjà sur Copilot reste vrai, en plus marqué. Copilot expose ce qu'un utilisateur peut déjà consulter ; un agent agit sur ce à quoi il a accès, en continu, sans la pause humaine qui rattrape parfois les erreurs. Trois schémas font l'essentiel des dégâts.

• Les applications OAuth sur-consenties. Un outil de comptes rendus de réunion qui demandait Mail.Read et l'accès complet aux fichiers, approuvé en un clic par un utilisateur en 2025, est toujours là et lit toujours. Les plateformes d'agents multiplient ces autorisations.
• Les agents hors circuit (shadow IA). Vos équipes connectent des outils IA personnels à leurs comptes professionnels parce que ça les fait avancer plus vite. Chaque connexion est un flux de données qui sort du tenant sans contrôle, invisible dans votre inventaire de licences - et difficile à documenter le jour où la CNIL, un client ou un auditeur NIS2 vous demande la liste de vos sous-traitants.
• Les agents orphelins. Le collaborateur qui avait bâti l'agent de workflow part ; l'agent continue de tourner avec des identifiants que plus personne ne se souvient d'avoir accordés. C'est le vieux problème des comptes de service, avec un rythme de création dix fois supérieur.

Le vrai basculement va du contrôle des accès au contrôle des actions. Les permissions classiques répondent à la question « qui peut ouvrir ce fichier ». Un agent en impose une seconde, que son écran de consentement n'a jamais posée : qu'a-t-il le droit de faire une fois entré, et cette action a-t-elle un sens dans le contexte ? Les garde-fous du modèle ne répondront pas à cette question. Le contrôle doit rester du côté de vos données, là où vous voyez réellement ce que chaque identité non humaine va chercher.

La checklist d'audit #

On ne gouverne pas ce qu'on ne voit pas. Le travail commence donc par un inventaire, pas par une politique.

1. Lister toutes les applications OAuth ayant des permissions consenties dans le tenant. Triez par étendue des droits (messagerie, fichiers, annuaire) et par personne ayant consenti. Signalez tout ce qui touche à l'IA et qu'un utilisateur a validé seul.
2. Repérer les autorisations à privilèges élevés. Mail.ReadWrite, Files.ReadWrite.All, Directory.Read.All détenues par des applications tierces méritent chacune un propriétaire nommé et une justification écrite.
3. Inventorier les agents Copilot Studio et Teams. Qui a construit chacun d'eux, à quoi se connecte-t-il, qui peut le déclencher, et son créateur fait-il toujours partie de l'effectif ?
4. Vérifier ce que les agents peuvent atteindre. Un agent branché sur « tout SharePoint » hérite de toutes vos erreurs de partage. Le travail de préparation à Copilot est aussi un travail de préparation aux agents : voir la checklist des permissions à passer avant Copilot et le repérage des liens de partage anonymes.
5. Chercher les secrets périmés et orphelins. Les agents s'authentifient avec des secrets d'application et des certificats qui expirent, se recopient et survivent à leurs propriétaires.
6. Définir un circuit de validation. Une page suffit : qui a le droit de créer un agent, quelles portées passent en revue, et à quelle fréquence l'inventaire est repris. Sans circuit, les utilisateurs vous contournent.

Un agent IA, c'est un nouveau collaborateur qui travaille à la vitesse de la machine, ne dort jamais, et a été recruté par celui qui a cliqué sur « accepter ». La question d'audit est la plus ancienne de la sécurité : qui accède à quoi, et qui l'a décidé ?

Obtenir l'inventaire sans lancer un chantier PowerShell #

Microsoft Graph expose les consentements OAuth, les principaux de service et les permissions d'application. Vous pouvez les énumérer en PowerShell si vous acceptez de maintenir les scripts et de les relancer tous les mois - la prolifération repousse dès qu'on arrête de regarder. La voie rapide est un scan en lecture seule : Olyteck Cyber parcourt le tenant via Graph et restitue les applications OAuth et leurs portées de permissions, à côté des constats de partage et d'identité, sans exporter le contenu des fichiers. Nous comptons les constats, jamais vos fichiers. Le scan est en lecture seule par défaut, et la plateforme est hébergée en UE, droit français - ce qui simplifie la partie sous-traitance de votre registre RGPD.

Dans les deux cas, traitez l'inventaire de juillet comme une base de référence, pas comme un correctif. Les organisations qui gardent la main sur les agents en 2026 ne sont pas celles qui les ont interdits - une interdiction ne produit que des agents mieux cachés. Ce sont celles qui savent répondre, à tout moment, à une question simple : qu'est-ce qui tourne dans notre tenant, et sur quelle autorité ?

FAQ #

Qu'est-ce qu'un agent IA dans Microsoft 365 ? #

C'est un composant logiciel qui exécute des actions dans votre tenant pour le compte d'un utilisateur ou de manière autonome : lire une boîte mail, créer un fichier, appeler une API, déclencher un workflow. Il peut venir de Copilot Studio, d'une application Teams, d'un éditeur SaaS tiers ou d'un outil installé par un collaborateur. La différence avec un assistant conversationnel tient à cette capacité d'action, qui suppose une identité et des permissions durables.

Comment savoir quelles applications IA ont accès à notre tenant Microsoft 365 ? #

L'information se trouve dans les applications d'entreprise d'Entra ID et dans les consentements OAuth associés, interrogeables via Microsoft Graph. Il faut lister les principaux de service, les portées accordées et l'identité de la personne qui a consenti, puis isoler les autorisations larges sur la messagerie, les fichiers et l'annuaire. Un scan en lecture seule produit cette liste en une passe, là où un script PowerShell demande d'être maintenu et relancé régulièrement.

Les agents IA posent-ils un problème au regard du RGPD ? #

Oui, dès lors qu'un agent tiers accède à des données personnelles hébergées dans votre tenant. Cet éditeur devient un sous-traitant qui doit figurer dans votre registre des traitements, avec un contrat, une localisation d'hébergement et un encadrement des transferts hors UE. Le cas le plus délicat reste l'agent installé par un collaborateur sans passer par la DSI : le traitement existe, mais rien ne le documente.

Faut-il interdire les agents IA aux salariés ? #

L'interdiction pure déplace le problème plutôt qu'elle ne le règle : les usages continuent sur des comptes personnels, hors de toute visibilité. Un circuit de validation court, avec une liste d'agents autorisés et une revue des portées de permissions, donne de meilleurs résultats qu'un refus de principe. L'objectif est de rendre le chemin officiel plus rapide que le contournement.