Détecter les usages invisibles, protéger ses données et encadrer les agents IA avec Microsoft 365.
Pendant des années, les équipes informatiques ont appris à composer avec le Shadow IT : des applications et services utilisés sans validation préalable de l’entreprise.
Mais aujourd’hui, le phénomène prend une nouvelle dimension.
Un collaborateur peut copier des informations professionnelles dans ChatGPT, installer Claude Code sur son ordinateur ou connecter un agent IA à des outils internes via un serveur MCP.
Le Shadow IT nous faisait perdre la visibilité sur les applications. Le Shadow AI nous oblige également à surveiller les données et les actions accessibles à ces outils.
🔎 Notre objectif
Comprendre ce que Microsoft Defender et Purview permettent déjà de découvrir, de contrôler et de protéger, sans complexifier inutilement son environnement.
Entre les services d’IA générative, les agents autonomes, les serveurs MCP, les risques de fuite de données et les prompt injections, difficile de savoir par où commencer.
Faut-il interdire les outils IA ? Acheter de nouvelles licences ? Développer son propre système de détection ?
Pas nécessairement.
Plusieurs technologies Microsoft permettent déjà de retrouver de la visibilité sur ces usages. Certaines sont même disponibles avec des licences que de nombreuses entreprises possèdent déjà.
Encore faut-il savoir où regarder, comprendre ce que chaque solution apporte et identifier ses limites.
Découvrir
Quels outils IA sont utilisés ?
Comprendre
Quelles données sont concernées ?
Protéger
Comment réduire les risques ?
📑 Au programme
1. Du Shadow IT au Shadow AI : qu’est-ce qui change ?
Le Shadow IT concernait principalement les applications et services utilisés en dehors du cadre défini par l’entreprise.
Avec le Shadow AI, les risques évoluent. Il ne s’agit plus uniquement de surveiller les applications, mais aussi les informations qu’elles peuvent traiter et les actions qu’elles sont capables d’exécuter.
🌐 IA dans le navigateur
Un utilisateur copie un extrait de document professionnel dans un service d’IA générative.
💻 Application IA locale
Un collaborateur installe une application IA ou un assistant de développement sur son ordinateur.
🤖 Agent IA autonome
Un agent utilise des outils pour lire des fichiers, exécuter des commandes ou modifier des ressources.
🔌 Serveur MCP
Une connexion étend les capacités d’un agent à d’autres outils et sources de données.
Le Model Context Protocol (MCP) est particulièrement intéressant : il permet à des agents compatibles de communiquer avec des outils et des sources externes.
Un agent peut ainsi dépasser le simple échange de questions-réponses. Selon ses autorisations, il peut intervenir directement sur l’environnement de travail.
⚠️ Un agent IA n’est pas automatiquement dangereux
Le risque dépend de ses permissions, des données accessibles, des outils connectés et des contrôles de sécurité en place.
Un agent inconnu mérite une investigation, pas nécessairement une interdiction immédiate.
La première étape est donc simple : retrouver de la visibilité avant de décider quoi bloquer.
2. Comment découvrir les IA utilisées ?
Pour identifier le Shadow AI, nous devons distinguer deux familles : les services IA utilisés depuis Internet et les agents installés directement sur les postes.
Les services IA web avec Defender for Cloud Apps
Microsoft Defender for Cloud Apps permet de découvrir les applications cloud utilisées dans une organisation à partir des sources de trafic configurées.
Depuis le portail Microsoft Defender :
security.microsoft.com
On peut ainsi identifier les applications découvertes, analyser leur utilisation et consulter les évaluations de risque disponibles.
Cela permet de répondre à une question essentielle : quels services IA sont réellement consultés depuis notre environnement ?
Une application peut également être classée comme approuvée ou non approuvée. Avec l’intégration adéquate de Defender for Endpoint, le classement comme non approuvée peut entraîner son blocage sur les postes concernés.
⚠️ Attention au blocage
Le classement d’une application comme non approuvée n’est pas une simple étiquette descriptive dans toutes les configurations. Vérifiez les intégrations et les conséquences avant de l’appliquer.
Les agents locaux avec Defender for Endpoint
Le 29 octobre 2026, Microsoft a annoncé la disponibilité générale de la découverte des agents IA locaux avec Defender for Endpoint.
Cette fonctionnalité permet d’identifier de nombreux agents et assistants utilisés directement sur les postes : Claude Code, Codex CLI, ChatGPT Desktop, GitHub Copilot CLI ou certaines extensions de développement.
Microsoft Defender
L’inventaire rassemble notamment le nom de l’agent, sa version, l’appareil concerné et le compte utilisateur associé.
Inventaire des agents IA locaux
Illustration de la découverte des agents locaux — données d’identification et volumes masqués.
En ouvrant une fiche d’agent, l’administrateur peut aller plus loin et examiner son processus hôte, son utilisateur et les serveurs MCP identifiés lorsqu’ils sont pris en charge.
Détails d’un agent Claude Code
Exemple des informations associées à un agent local détecté.
Deux paramètres méritent une attention particulière :
- Processus approuvé : information de confiance relative au processus hôte, qui ne constitue pas une validation de l’outil par le service IT.
- Approbation automatique : indique si l’agent peut agir sans solliciter systématiquement une approbation de l’utilisateur.
Les configurations MCP constituent également un excellent point de départ pour examiner les outils auxquels l’agent peut accéder.
Quelles licences faut-il ?
| Fonctionnalité | Licence minimale |
|---|---|
| Découverte des agents locaux | Defender for Endpoint P2 |
| Inventaire et table AgentsInfo | Defender for Endpoint P2 |
| Niveau de risque et recommandations avancées de posture des agents | Microsoft 365 E7 ou Agent 365 avec Defender for Endpoint P2 |
Microsoft 365 E5 inclut Defender for Endpoint P2. Il n’est donc pas nécessaire d’acheter Agent 365 uniquement pour disposer de l’inventaire local et interroger ses données dans Advanced Hunting.
⚠️ Une visibilité qui dépend de l’activité
La découverte repose sur l’observation de l’activité des agents compatibles. Un outil installé mais jamais exécuté peut rester invisible.
Un même agent utilisé par plusieurs comptes ou appareils peut également générer plusieurs profils.
L’annonce Microsoft du 29 octobre inclut Windows et macOS dans la disponibilité générale. La documentation technique mentionne toutefois encore macOS en préversion au moment de la rédaction : vérifiez la matrice de prise en charge.
✅ Ce qu’il faut retenir
Defender permet de découvrir les applications IA web et les agents locaux via deux mécanismes complémentaires. Ce sont deux formes différentes du Shadow AI, qu’il ne faut pas confondre.
3. Comment identifier les données exposées ?
Découvrir qu’un collaborateur utilise ChatGPT est une première étape.
Mais quelles informations lui transmet-il réellement ?
C’est ici que Microsoft Purview Data Security Posture Management (DSPM) devient particulièrement intéressant.
DSPM rassemble des capacités de découverte, d’analyse et de remédiation pour mieux comprendre les risques associés aux données, notamment lorsqu’elles sont utilisées avec des solutions d’IA.
Découvrir les usages IA
Les rapports et l’explorateur d’activités permettent, selon les intégrations et politiques activées, d’examiner différentes catégories d’événements liés à l’IA.
On peut notamment rencontrer :
- AI website visit : visite d’un site d’IA générative ;
- AI interaction : interaction avec un service IA compatible ;
- DLP rule match : correspondance avec une politique de protection des données.
Utilisation de l’IA et risque
Vue issue du reporting Purview historique, en transition vers la nouvelle expérience DSPM.
L’objectif n’est pas simplement de compter les visites, mais de comprendre quelles familles de services IA sont utilisées et où se concentrent les interactions nécessitant une analyse.
Identifier les interactions sensibles
DSPM permet également de mettre en relation certaines activités IA avec des informations sensibles, des événements DLP et des étiquettes de confidentialité.
Données sensibles dans les interactions IA
Exemple de visibilité sur les informations sensibles et les étiquettes — volumes anonymisés.
Une nuance est essentielle : la présence d’une étiquette ou d’une catégorie sensible dans un rapport ne signifie pas automatiquement qu’une fuite de données est confirmée.
Il faut analyser l’événement, le contexte et les informations disponibles.
Peut-on voir les prompts des utilisateurs ?
La réponse est : cela dépend.
Un événement AI website visit permet généralement de retrouver la visite, son horodatage, l’application consultée et certaines informations sur l’utilisateur. Il ne révèle pas, à lui seul, le prompt saisi.
En revanche, certains événements AI interaction peuvent contenir des prompts et des réponses lorsque les mécanismes de journalisation ou de collecte de contenu nécessaires sont activés.
C’est notamment pertinent pour les expériences Microsoft 365 Copilot et pour certaines applications IA tierces couvertes par les politiques et intégrations Purview.
Explorateur d’activités IA
L’activité peut être attribuée à un utilisateur sans que le contenu du prompt soit disponible.
Un prérequis parfois oublié : les navigateurs
Pour découvrir certaines activités IA réalisées dans les navigateurs tiers sous Windows, Microsoft Purview s’appuie notamment sur son extension pour les navigateurs concernés.
Microsoft Edge dispose de capacités natives, tandis que Chrome et Firefox sous Windows peuvent nécessiter l’extension Microsoft Purview. Les modalités diffèrent sur macOS.
C’est un point important : l’absence de données ne signifie pas forcément l’absence d’utilisation de l’IA.
⚠️ Attention à l’évolution de DSPM
Les expériences DSPM classiques ont été remplacées par une nouvelle expérience. Les captures du reporting historique servent à illustrer les catégories de visibilité et ne constituent pas une procédure de navigation garantie dans le nouveau portail.
Les fonctionnalités disponibles dépendent des licences, des politiques, des appareils intégrés et des capacités de collecte activées.
✅ Ce qu’il faut retenir
Defender aide à savoir quelles IA sont utilisées. DSPM complète cette visibilité en examinant les activités et les risques liés aux données, dans les limites des sources surveillées.
4. Comment empêcher les fuites de données vers une IA ?
Nous savons désormais comment identifier les applications IA et retrouver certaines activités sensibles.
Mais découvrir une utilisation à risque ne suffit pas : il faut aussi pouvoir empêcher certaines données de quitter l’environnement professionnel.
Avec Microsoft Purview Endpoint DLP, nous pouvons notamment contrôler deux situations :
📄 Partage de fichiers
Un utilisateur tente de téléverser un document confidentiel vers un service IA.
Endpoint DLP peut auditer ou bloquer cette opération lorsqu’une règle correspond.
📋 Copier-coller
Un collaborateur colle des données sensibles dans le champ de saisie de ChatGPT.
Endpoint DLP peut analyser le texte collé et contrôler l’opération.
Étape 1 — Préparer les domaines IA à contrôler
Commençons dans Microsoft Purview :
Microsoft Purview
Dans cette rubrique, recherchez Groupes de domaines de service sensibles.
Microsoft propose un groupe prédéfini intitulé Sites web d’IA générative, contenant les sites IA actuellement pris en charge par cette fonctionnalité.
Nous pouvons réutiliser ce groupe dans nos politiques DLP plutôt que de gérer manuellement chaque domaine. Il reste important de vérifier que les services ciblés figurent dans la liste prise en charge.
Illustration pédagogique de la configuration des groupes de domaines sensibles.
⚠️ Vérifier le paramètre global Service domains
Microsoft recommande de configurer l’action globale Service domains sur Block pour les scénarios concernés. Ce réglage fonctionne avec les domaines ou groupes ciblés par les règles DLP : il ne signifie pas que tous les sites Internet seront bloqués.
Attention : ce paramètre est global. Examinez les autres politiques Endpoint DLP avant de le modifier dans un environnement de production.
Étape 2 — Créer une politique pour les appareils
Rendez-vous dans :
Microsoft Purview
Dans les emplacements, sélectionnez Appareils (Devices) et limitez le périmètre initial à un groupe pilote.
Choisissez ensuite Créer ou personnaliser des règles DLP avancées.
Pour conserver une configuration facile à comprendre et à maintenir, nous allons distinguer les fichiers des collages de texte.
Étape 3 — Contrôler le téléversement de fichiers
Créons une première règle pour surveiller les documents confidentiels transférés vers les services IA.
| Paramètre | Valeur recommandée pour le pilote |
|---|---|
| Nom | Shadow AI – File Upload – Audit |
| Emplacement | Appareils |
| Condition | Le contenu inclut → Étiquettes de confidentialité |
| Étiquettes | Confidential / Restricted (exemples à adapter) |
| Action | Auditer ou restreindre les activités sur les appareils |
| Activité | Charger vers un domaine de service cloud restreint |
| Domaines | Groupe Sites web d’IA générative |
| Restriction initiale | Auditer uniquement |
Dans la section Actions → Auditer ou restreindre les activités sur les appareils, activez le contrôle des chargements vers les domaines de service restreints.
Utilisez l’option permettant de choisir différentes restrictions pour les groupes de domaines sensibles, puis associez le groupe des sites IA générative.
Le mode Audit permet de mesurer les tentatives de transfert avant d’envisager un blocage.
💡 Attention aux étiquettes par défaut
Si une étiquette Internal est appliquée automatiquement à la majorité des documents, son utilisation dans une règle de blocage peut provoquer de nombreuses restrictions inutiles.
Il est préférable de commencer avec les étiquettes représentant des informations réellement confidentielles, puis d’ajuster selon les résultats.
Étape 4 — Contrôler le collage de données sensibles
Passons maintenant au scénario le plus discret : le copier-coller de texte.
Un utilisateur peut copier une information depuis un document, une application métier ou un outil interne, puis la coller dans ChatGPT.
La protection du collage fonctionne différemment : elle analyse les données du presse-papiers, et non l’étiquette du fichier source.
Créons donc une deuxième règle avec les paramètres suivants :
| Paramètre | Valeur recommandée pour le pilote |
|---|---|
| Nom | Shadow AI – Browser Paste – Audit |
| Emplacement | Appareils |
| Condition | Le contenu inclut → Types d’informations sensibles |
| Exemple de SIT | France IBAN |
| Action | Auditer ou restreindre les activités sur les appareils |
| Activité | Coller dans les navigateurs pris en charge |
| Groupe de domaines | Sites web d’IA générative |
| Restriction initiale | Auditer uniquement |
Le groupe de domaines sensibles doit également être associé à l’action de collage. Ajouter les sites uniquement à la liste globale des domaines de service ne suffit pas.
Simulation pédagogique : emplacement des actions de partage de fichiers et de collage. Les deux scénarios peuvent être configurés dans des règles distinctes.
⚠️ Les limites du contrôle du collage
Le contrôle utilise les types d’informations sensibles compatibles. Les étiquettes de confidentialité, les classifieurs entraînables et la classification avancée ne déclenchent pas cette action.
Les textes inférieurs à 30 caractères ne sont pas évalués par cette fonctionnalité.
La protection dépend également des appareils et navigateurs compatibles, ainsi que de la présence de l’extension Microsoft Purview lorsqu’elle est requise.
Étape 5 — Passer progressivement de l’audit au blocage
Une fois les politiques en place, vérifiez les événements dans l’Explorateur d’activités de Microsoft Purview.
Vous pourrez distinguer les transferts de fichiers et les événements de collage correspondant aux règles.
1. Audit only
Mesurer les usages et identifier les faux positifs.
2. Block with override
Restreindre tout en permettant une justification métier si elle est autorisée.
3. Block
Bloquer les opérations pour lesquelles aucune exception n’est acceptable.
Il est préférable de vérifier la synchronisation des politiques, les navigateurs concernés et les événements observés avant d’étendre le périmètre de protection.
✅ Ce qu’il faut retenir
Avec Endpoint DLP, il est possible de surveiller ou de bloquer deux voies fréquentes de fuite de données vers les services IA : le téléversement de fichiers protégés et le collage de texte sensible.
Deux actions, des conditions différentes, mais un objectif commun : protéger les données sans interdire systématiquement les outils d’intelligence artificielle.
5. Comment protéger les agents IA pendant leur exécution ?
Jusqu’ici, nous avons parlé de découverte des outils et de protection des données.
Mais que se passe-t-il si un agent IA lui-même est confronté à une instruction malveillante ?
Prenons l’exemple d’un développeur utilisant un agent de programmation pour analyser un projet.
L’agent consulte une documentation contenant une instruction dissimulée lui demandant de récupérer des informations confidentielles et de les envoyer vers une adresse externe.
Ce scénario correspond à une prompt injection : un attaquant cherche à détourner le comportement de l’agent à partir d’un contenu qu’il consulte.
C’est l’un des risques que Microsoft Defender AI Agent Runtime Protection cherche à réduire.
Comment fonctionne Runtime Protection ?
Cette technologie, actuellement en préversion, inspecte certains points du fonctionnement des agents IA compatibles pour détecter des instructions malveillantes et des actions à risque.
Microsoft propose notamment deux approches :
Agent-native event inspection
Utilise les interfaces d’événements proposées par certains agents, comme Claude Code ou Codex CLI, pour inspecter les opérations prises en charge.
Network inspection
Inspecte certains échanges réseau compatibles entre les agents et les modèles IA, avec des restrictions techniques.
La couverture varie selon l’agent et les méthodes d’inspection disponibles. Les connexions avec certificate pinning ou HTTP/3 ne sont notamment pas prises en charge par l’inspection réseau.
Activer la protection avec Microsoft Intune
Microsoft propose désormais un profil de protection directement dans Microsoft Intune.
Microsoft Intune
Ce profil permet de configurer l’inspection native des événements des agents sur les appareils Windows compatibles.
L’inspection réseau nécessite une configuration distincte et n’est pas automatiquement activée par ce profil.
Stratégie Runtime Protection dans Intune
Illustration d’un déploiement pilote en mode Audit. L’application réussie d’une stratégie ne démontre pas à elle seule l’efficacité de la détection.
Audit ou Block ?
| Mode | Comportement |
|---|---|
| Disabled | Inspection désactivée |
| Audit | Détection et alerte sans blocage de l’action |
| Block | Blocage des actions malveillantes prises en charge |
Microsoft recommande de commencer en Audit, d’observer les détections pendant une à deux semaines et de n’envisager le blocage qu’après validation.
Des prérequis spécifiques s’appliquent pendant la préversion, notamment concernant les versions et les canaux de mise à jour de Microsoft Defender.
⚠️ Protection à l’exécution ne signifie pas protection absolue
Runtime Protection ne surveille pas nécessairement toutes les opérations de tous les agents IA.
L’inventaire d’un agent, l’application d’une politique Intune et la détection effective d’une attaque sont trois choses différentes.
✅ Ce qu’il faut retenir
La découverte nous dit qu’un agent existe. Runtime Protection cherche à protéger certaines étapes de son fonctionnement. Les deux technologies se complètent, mais ne doivent pas être confondues.
6. Par où commencer pour maîtriser le Shadow AI ?
Nous avons désormais identifié les principales briques Microsoft.
Mais il ne faut pas chercher à tout activer immédiatement.
Je privilégierais une démarche simple et progressive.
01 — Découvrir les usages
Consulter les applications IA découvertes dans Defender for Cloud Apps et les agents locaux remontés par Defender for Endpoint.
02 — Comprendre les risques
Examiner les activités disponibles dans DSPM, les données sensibles, les comptes associés et les outils accessibles aux agents.
03 — Définir les usages autorisés
Établir une liste d’outils approuvés et préciser les règles applicables aux agents locaux, aux connexions MCP et aux données professionnelles.
04 — Protéger progressivement
Déployer les contrôles DLP adaptés, commencer par des stratégies Audit et réserver les nouveaux mécanismes préversion à des pilotes compatibles.
05 — Accompagner les collaborateurs
Expliquer les risques, proposer des alternatives approuvées et réexaminer régulièrement les outils et permissions.
Quel outil répond à quel besoin ?
| Votre question | Outil à examiner |
|---|---|
| Quelles IA web sont utilisées ? | Defender for Cloud Apps |
| Quels agents tournent sur les postes ? | Defender for Endpoint |
| Quelles activités impliquent des données sensibles ? | Purview DSPM |
| Comment limiter les transferts sensibles ? | Purview DLP |
| Comment détecter certaines attaques contre les agents ? | Defender AI Agent Runtime Protection |
💜 Le point essentiel
Le Shadow AI ne se résout pas avec une seule politique ou un seul produit.
La maîtrise vient de la complémentarité entre visibilité, classification, contrôle des données, protection des agents et gouvernance des usages.
Pour aller plus loin : faut-il utiliser KQL ?
Pas obligatoirement.
Et pour nombreux d’entre vous, le KQL ca fait peur !
Les interfaces graphiques Defender et Purview offrent déjà une grande partie de la visibilité nécessaire pour commencer.
Mais si vous souhaitez approfondir l’inventaire local ou préparer un reporting, Advanced Hunting devient intéressant.
La table AgentsInfo permet notamment de retrouver les profils d’agents IA locaux observés.
Cette requête utilise les champs documentés par Microsoft pour récupérer la dernière version connue des profils d’agents, puis exclure les profils supprimés ou désinstallés.
Elle fournit une base d’investigation, mais les résultats doivent être interprétés selon la couverture effective des agents et des appareils.
💡 Mon conseil
Commencez par l’interface graphique. Utilisez KQL lorsque vous avez besoin de consolider les données, de les filtrer ou de mener une investigation plus avancée.
Conclusion : le Shadow AI est-il vraiment incontrôlable ?
Le Shadow AI peut donner l’impression d’être un nouveau casse-tête pour les administrateurs Microsoft 365.
Pourtant, nous venons de voir que plusieurs technologies permettent déjà d’identifier les usages, de mieux comprendre les risques et de protéger les données.
Defender for Cloud Apps découvre les applications cloud. Defender for Endpoint inventorie les agents locaux. Purview DSPM apporte de la visibilité sur les activités et les données. DLP permet de contrôler certains transferts. Et Runtime Protection ouvre une nouvelle voie pour protéger les agents pendant leur fonctionnement.
Aucune de ces solutions ne garantit une maîtrise absolue. Leur efficacité dépend de la couverture, des licences, des politiques et de l’accompagnement des collaborateurs.
Le plus difficile avec le Shadow AI n’est pas toujours de le contrôler. C’est de comprendre par où commencer.
La bonne stratégie n’est donc pas d’interdire systématiquement l’intelligence artificielle, mais de rendre son utilisation visible, encadrée et compatible avec les exigences de sécurité de l’entreprise.
📚 Sources officielles Microsoft
- Microsoft — Disponibilité générale de la découverte des agents IA locaux
- Microsoft Learn — Discover local AI agents
- Microsoft Learn — Manage generative AI apps
- Microsoft Learn — DSPM activity and data considerations
- Microsoft Learn — Configuring DSPM
- Microsoft Learn — Endpoint DLP paste to browsers
- Microsoft Learn — AI Agent Runtime Protection
- Microsoft Learn — Configuration de Runtime Protection
Les capacités décrites correspondent à la documentation Microsoft consultée au moment de la rédaction. Les fonctionnalités en préversion et les prérequis peuvent évoluer.
Les captures d’interface sont anonymisées ; les volumes et identifiants internes ne sont pas publiés.
