Copilot et agents IA : appliquer le Zero Trust quand l’IA agit

Dans notre article consacré aux post:zero-trust-ai-foundations, nous avons présenté trois principes essentiels : vérifier explicitement, limiter les autorisations et réduire les conséquences d’un incident.

Ces principes prennent une dimension supplémentaire lorsqu’une intelligence artificielle ne se contente plus de rechercher ou de résumer des informations. Un agent peut accéder à des ressources, utiliser des connecteurs et exécuter des actions dans l’environnement de l’entreprise.

La question n’est donc plus seulement de savoir ce que l’intelligence artificielle peut consulter.

Avec quelle identité l’agent agit-il, quelles données peut-il utiliser et jusqu’où peut-il aller sans intervention humaine ?

De l’assistant qui répond à l’agent qui agit

Microsoft 365 Copilot travaille principalement aux côtés de l’utilisateur. Il peut retrouver une information, résumer une réunion, analyser un document ou préparer un message.

La personne conserve généralement la maîtrise de l’étape suivante. Copilot propose un résultat, mais l’utilisateur décide de le modifier, de l’envoyer ou de l’écarter.

Un agent peut aller plus loin. Selon sa conception et les autorisations qui lui sont accordées, il peut :

• recevoir un objectif ;
• rechercher des informations dans plusieurs sources ;
• utiliser un connecteur ou une API ;
• créer ou modifier une information ;
• déclencher un processus ;
• envoyer une réponse ;
• mettre à jour une application métier.

Microsoft décrit un agent comme une application capable de comprendre son environnement, de prendre des décisions et d’agir à l’aide des outils qui lui sont accessibles. Certains agents sont directement sollicités par un utilisateur. D’autres peuvent exécuter une partie de leur mission de manière autonome.

La documentation Microsoft sur les identités des agents (s’ouvre dans un nouvel onglet) détaille cette évolution et les nouveaux besoins d’identification, d’autorisation et de gouvernance qui en découlent.

Plus l’agent peut agir, plus les conséquences d’une permission excessive, d’une erreur ou d’un contenu malveillant peuvent être importantes.

Un cas concret : automatiser des demandes clients

Imaginons une entreprise qui souhaite créer un agent pour assister son service client.

L’agent doit :

1. consulter une boîte aux lettres partagée ;
2. comprendre la demande reçue ;
3. rechercher une réponse dans SharePoint ;
4. préparer un message ;
5. proposer le document approprié ;
6. envoyer la réponse ;
7. mettre à jour le dossier client dans une application métier.

Ce processus semble simple. Pourtant, chacune de ses étapes soulève une question de sécurité.

La boîte aux lettres peut contenir des informations confidentielles. Le document trouvé dans SharePoint peut ne pas être destiné au client. Un message entrant peut contenir une instruction cherchant à influencer l’agent. La mise à jour de l’application métier peut également modifier une information importante.

Appliquer le Zero Trust consiste ici à contrôler quatre éléments :

• l’identité utilisée par l’agent ;
• les données auxquelles il peut accéder ;
• les outils et connecteurs qu’il peut appeler ;
• les actions qu’il peut exécuter.

Donner une identité propre à chaque agent

Un agent ne devrait pas rester un composant technique anonyme. Il ne devrait pas non plus partager un compte avec un collaborateur, un administrateur ou plusieurs autres automatisations.

Microsoft Entra Agent ID permet de représenter les agents dans Microsoft Entra ID avec des identités spécialisées. Chaque agent peut ainsi être distingué des utilisateurs humains et des applications traditionnelles.

Une identité d’agent possède un identifiant unique. Elle peut être associée à un modèle réutilisable, appelé agent identity blueprint, qui définit un type d’agent et permet d’appliquer des politiques cohérentes à plusieurs instances.

Elle peut également être associée à un sponsor humain chargé de rendre compte de la finalité de l’agent.

La documentation Microsoft Entra Agent ID (s’ouvre dans un nouvel onglet) présente les composants de ces identités et leur fonctionnement.

Cette identification permet de répondre à des questions essentielles :

• Quel agent a accédé à cette ressource ?
• Quelles permissions lui ont été attribuées ?
• Qui est responsable de son utilisation ?
• Quel utilisateur ou processus a déclenché l’action ?
• Comment suspendre cet agent sans affecter les autres ?
• Ses accès correspondent-ils toujours à un besoin réel ?

Dans notre exemple, l’agent du service client doit disposer de sa propre identité. Il ne doit pas réutiliser le compte d’un collaborateur.

Deux responsabilités doivent être distinguées :

• le sponsor métier, responsable du besoin auquel répond l’agent ;
• le propriétaire technique, responsable de sa configuration, de sa sécurité et de son exploitation.

Si le sponsor quitte l’entreprise ou si le processus disparaît, l’organisation doit pouvoir réattribuer la responsabilité ou désactiver l’agent.

Une identité distincte ne supprime pas tous les risques. Elle constitue néanmoins le point de départ nécessaire pour appliquer le moindre privilège, conserver une trace des activités et retirer proprement les accès.

Limiter les données accessibles

Un agent ne doit pas accéder à toutes les informations disponibles simplement parce qu’un accès large facilite son développement.

L’agent de notre exemple a besoin :

• de la boîte aux lettres du service client ;
• d’un ensemble précis de documents approuvés ;
• de certains champs dans l’application métier.

Il n’a probablement pas besoin de consulter les dossiers des ressources humaines, les contrats fournisseurs ou l’ensemble des sites SharePoint de l’entreprise.

Cette limitation suppose que l’organisation sache où se trouvent ses informations sensibles, comment elles sont classifiées et qui peut actuellement y accéder.

Classifier les informations avec Microsoft Purview

Microsoft Purview Information Protection permet d’utiliser des étiquettes de confidentialité pour distinguer différents niveaux d’information, par exemple :

• public ;
• interne ;
• confidentiel ;
• strictement confidentiel.

Une étiquette peut être accompagnée de mesures de protection comme le chiffrement ou des restrictions d’utilisation.

L’entreprise peut ainsi définir qu’un document classé « strictement confidentiel » ne doit jamais être joint automatiquement à une réponse externe.

Microsoft 365 Copilot respecte les permissions existantes. Lorsque les informations sont protégées par des étiquettes de confidentialité et du chiffrement, des droits supplémentaires peuvent être nécessaires pour que le contenu soit utilisé dans une réponse.

La documentation Microsoft Purview sur la protection des applications d’IA générative (s’ouvre dans un nouvel onglet) présente ces mécanismes ainsi que les prérequis à examiner.

Prévenir les pertes de données

Les stratégies Microsoft Purview Data Loss Prevention, ou DLP, permettent d’identifier certaines informations sensibles et de contrôler les actions correspondantes.

Selon les licences et les emplacements concernés, une stratégie DLP peut :

• détecter une donnée sensible ;
• avertir l’utilisateur ;
• demander une justification ;
• bloquer une opération ;
• enregistrer l’événement pour investigation.

Dans notre scénario, le contrôle ne doit pas porter uniquement sur le document trouvé dans SharePoint. Il doit aussi examiner le message préparé, la pièce jointe, le destinataire et le canal utilisé.

Identifier le partage excessif et les usages à risque

Microsoft Purview Data Security Posture Management offre une visibilité sur les risques liés aux données et aux usages de l’IA.

Il peut notamment aider à identifier :

• des données sensibles trop largement accessibles ;
• des interactions avec des applications d’IA ;
• des contenus sensibles utilisés dans des requêtes ou des réponses ;
• des recommandations permettant de réduire l’exposition.

Microsoft Purview peut également fournir des événements d’audit sur les interactions avec Copilot et les applications d’IA prises en charge. Les invites, les réponses et les références aux fichiers consultés peuvent alimenter des activités d’audit et, selon les licences disponibles, des processus d’investigation ou de conformité.

Aucun outil ne peut cependant remplacer une gouvernance inexistante. Si les permissions sont trop larges et si personne ne connaît la sensibilité des documents, l’organisation doit commencer par reprendre le contrôle de ses données.

Encadrer les connecteurs et les actions

Les agents créés dans Microsoft Copilot Studio peuvent utiliser des sources de connaissances, des connecteurs, des requêtes HTTP, des déclencheurs et différents outils.

Toutes ces capacités ne doivent pas être accessibles de la même manière.

Les stratégies de données du Centre d’administration Power Platform permettent notamment de contrôler :

• l’authentification des créateurs et des utilisateurs ;
• les sources de connaissances ;
• les actions et connecteurs ;
• les requêtes HTTP ;
• les canaux de publication ;
• les déclencheurs ;
• certaines capacités autonomes.

La documentation Microsoft sur la sécurité et la gouvernance de Copilot Studio (s’ouvre dans un nouvel onglet) présente également des fonctions comme l’analyse de sécurité avant publication, la visibilité sur les dépendances des connecteurs, les journaux d’audit et le routage des créateurs vers des environnements contrôlés.

Une approche pratique consiste à séparer trois environnements :

1. un environnement d’expérimentation avec des données non sensibles ;
2. un environnement de validation avec des contrôles renforcés ;
3. un environnement de production limité aux sources et connecteurs approuvés.

Cette séparation réduit le risque qu’un prototype créé rapidement devienne un processus de production sans véritable revue de sécurité.

Décider ce que l’agent peut faire seul

Toutes les actions ne présentent pas le même niveau de risque.

Actions pouvant être automatisées

L’agent peut, par exemple :

• classer une demande ;
• identifier son sujet ;
• rechercher une documentation approuvée ;
• préparer un brouillon ;
• proposer le document à joindre.

Ces actions génèrent un résultat intermédiaire, sans produire immédiatement un effet externe.

Actions nécessitant une validation

Une confirmation humaine peut être prévue avant de :

• joindre un document confidentiel ;
• envoyer un message à l’extérieur ;
• modifier une donnée importante ;
• changer le statut d’une demande ;
• prendre un engagement au nom de l’entreprise.

Cette validation doit apporter un véritable contrôle. Elle ne doit pas se transformer en une fenêtre systématiquement acceptée sans vérification.

Actions qui doivent rester interdites

Certaines opérations peuvent être exclues du périmètre initial :

• modifier des permissions ;
• supprimer définitivement des données ;
• utiliser un connecteur non approuvé ;
• contacter un destinataire non vérifié ;
• exécuter une transaction ;
• consulter une source non validée.

Le but n’est pas de supprimer toute autonomie. Il est d’adapter le niveau d’autonomie aux conséquences possibles de l’action.

Protéger l’agent contre les contenus qu’il traite

Un agent ne reçoit pas seulement les instructions saisies par son utilisateur. Il peut aussi lire des e-mails, des documents, des pages web ou des données provenant d’applications externes.

Un contenu peut renfermer une instruction destinée à influencer le comportement de l’IA. Ce risque est appelé injection indirecte d’instructions.

Dans notre scénario, un message adressé au service client pourrait tenter d’inciter l’agent à ignorer son objectif initial, à rechercher une information sans rapport avec la demande ou à utiliser un outil inutile.

Aucune protection isolée ne suffit. L’entreprise doit combiner :

• l’analyse des contenus entrants ;
• des permissions limitées ;
• des sources de connaissances approuvées ;
• des connecteurs contrôlés ;
• une validation humaine pour les actions sensibles ;
• une journalisation exploitable ;
• la capacité de suspendre rapidement l’agent.

Le principe reste celui du Zero Trust : un contenu doit être considéré comme potentiellement non fiable, même lorsqu’il entre dans un processus apparemment ordinaire.

Choisir un niveau de protection adapté

La solution la plus avancée n’est pas automatiquement la plus pertinente. L’organisation doit partir de ses risques, de ses obligations et de sa capacité à exploiter les outils.

Microsoft 365 Business Premium pour les fondations

Pour une PME allant jusqu’à 300 utilisateurs, Microsoft 365 Business Premium fournit notamment :

• Microsoft Entra ID Plan 1 pour les identités et l’accès conditionnel ;
• Microsoft Intune Plan 1 pour la gestion et la conformité des appareils ;
• Microsoft Defender for Business pour protéger les terminaux ;
• Microsoft Defender for Office 365 Plan 1 pour les e-mails et les fichiers ;
• des capacités Microsoft Purview de protection de l’information et de DLP.

La documentation Microsoft sur les capacités de Business Premium (s’ouvre dans un nouvel onglet) présente ce socle et les extensions disponibles.

Ces fonctions permettent de renforcer l’authentification, conditionner les accès, gérer les appareils, protéger les postes et commencer à classifier les informations.

Une licence ne configure cependant rien automatiquement. Les politiques d’accès conditionnel, la conformité des appareils, les protections Defender et les stratégies DLP doivent être définies, testées et maintenues.

Microsoft Defender Suite pour mieux détecter et enquêter

Microsoft Defender Suite for Business Premium étend le socle avec :

• Microsoft Entra ID Plan 2 ;
• Microsoft Defender for Endpoint Plan 2 ;
• Microsoft Defender for Identity ;
• Microsoft Defender for Office 365 Plan 2 ;
• Microsoft Defender for Cloud Apps ;
• Microsoft Defender XDR.

Cette évolution devient pertinente lorsque l’entreprise souhaite détecter des usages d’IA non approuvés, corréler des signaux venant des identités, des postes et des e-mails, puis approfondir ses investigations.

Microsoft Defender for Cloud Apps peut notamment contribuer à identifier des applications cloud non autorisées. Microsoft Defender XDR permet de regrouper plusieurs signaux dans un incident cohérent.

L’entreprise doit toutefois définir qui examinera les alertes et comment les réponses seront engagées. Accumuler des alertes sans processus de traitement ne renforce pas réellement la sécurité.

Microsoft Purview Suite pour les données et la conformité

Microsoft Purview Suite devient pertinente lorsque les besoins dépassent la classification et la DLP de base.

Elle peut renforcer :

• la classification des données ;
• la prévention des pertes sur plusieurs canaux ;
• la gestion des risques internes ;
• l’audit ;
• l’eDiscovery ;
• la conformité des communications ;
• la conservation des interactions avec l’IA ;
• la visibilité sur les risques liés aux données et aux agents.

Ce niveau est particulièrement utile lorsque Copilot ou les agents utilisent de nombreuses sources internes, lorsque des obligations réglementaires s’appliquent ou lorsque l’organisation traite régulièrement des informations personnelles, financières ou contractuelles.

La progression n’est pas nécessairement Business Premium, puis Defender, puis Purview. Une entreprise peut avoir un besoin avancé en matière de données sans disposer d’un centre opérationnel de sécurité étendu.

Le choix doit suivre le risque réel.

Gouverner les agents à l’échelle avec Microsoft Agent 365

Lorsque plusieurs équipes créent des agents sur différentes plateformes, un inventaire central devient nécessaire.

Microsoft Agent 365 fournit un plan de contrôle centralisé pour découvrir, gérer, gouverner et sécuriser les agents Microsoft et tiers.

La description officielle de Microsoft Agent 365 (s’ouvre dans un nouvel onglet) distingue deux niveaux.

Certaines fonctions de base sont disponibles avec plusieurs plans Microsoft 365 :

• inventaire des agents ;
• publication et approbation ;
• blocage ou suppression ;
• affectation aux utilisateurs et groupes ;
• réattribution du propriétaire ;
• automatisation de certaines actions de cycle de vie.

Les fonctions avancées nécessitent Microsoft Agent 365 ou Microsoft 365 E7. Elles comprennent notamment :

• l’observabilité et le suivi détaillé des activités ;
• les modèles de politiques centralisées ;
• le contrôle des outils accessibles ;
• les packages d’accès pour limiter les permissions ;
• les politiques de cycle de vie pilotées par les sponsors ;
• l’extension de l’accès conditionnel aux agents ;
• l’audit et l’eDiscovery des interactions ;
• la DLP appliquée aux contenus consultés ou partagés ;
• la détection des activités suspectes ;
• l’intégration avec Microsoft Defender, Purview, Entra et Intune.

Microsoft 365 E7 regroupe Microsoft 365 E5, Microsoft 365 Copilot, Microsoft Entra Suite et Microsoft Agent 365. Ce positionnement peut correspondre aux organisations qui souhaitent déployer Copilot et de nombreux agents à l’échelle.

Ce n’est pas une destination obligatoire. Pour de nombreuses PME, Business Premium complété par des capacités ciblées reste plus proportionné.

Préparer la fin de vie de l’agent

Un agent correctement sécurisé lors de son lancement peut devenir risqué avec le temps.

Son propriétaire peut changer. Une nouvelle source peut être ajoutée. Ses permissions peuvent s’élargir. Son cas d’usage peut disparaître sans que l’agent soit désactivé.

La gouvernance doit couvrir tout son cycle de vie :

1. définir le besoin et les responsabilités ;
2. créer une identité distincte ;
3. limiter les permissions ;
4. valider les données et les outils ;
5. tester le comportement ;
6. surveiller les activités ;
7. réviser régulièrement les accès ;
8. désactiver l’agent et retirer ses permissions lorsque le besoin disparaît.

Un agent sans sponsor, sans propriétaire ou sans utilisation vérifiée doit être traité comme tout autre accès devenu injustifié.

Quatorze questions avant de déployer un agent

1. Quel problème métier l’agent doit-il résoudre ?
2. Qui est son sponsor métier ?
3. Qui en assure l’administration technique ?
4. Possède-t-il sa propre identité ?
5. Quelles données peut-il consulter ?
6. Les informations sensibles sont-elles identifiées ?
7. Quels connecteurs et outils peut-il utiliser ?
8. Quelles actions peut-il exécuter seul ?
9. Quelles actions nécessitent une validation humaine ?
10. Comment ses activités seront-elles journalisées ?
11. Qui examinera les alertes ?
12. Comment suspendre rapidement l’agent ?
13. À quelle fréquence ses permissions seront-elles révisées ?
14. Comment ses accès seront-ils retirés à la fin du projet ?

Si plusieurs réponses restent imprécises, le projet ne doit pas nécessairement être abandonné. Son périmètre peut être réduit : moins de données, moins de connecteurs, moins d’actions ou davantage de validation humaine.

Une service:microsoft-365-security-assessment menée par MC3 Cloud peut aider à examiner les identités, les permissions, les appareils, les partages et les protections déjà en place avant d’étendre l’usage de Copilot ou des agents.

Approfondir le sujet lors des événements de décembre

MC3 Cloud organise les ZeroTrust Days Copilot 2026 dans deux territoires :

• le 9 décembre 2026 à La Réunion, à l’Amphithéâtre SFR au Port ;
• le 10 décembre 2026 à Maurice, au Hennessy Park Hotel à Cybercity Trianon.

Seyfallah Tagrerout, Microsoft MVP Security et Microsoft Regional Director, interviendra sur les risques liés à l’IA générative, la protection des données sensibles, les identités des agents, leurs permissions et le rôle de Microsoft Entra ID. Des démonstrations permettront de relier ces principes à des situations concrètes.

• S’inscrire à l’édition de La Réunion (s’ouvre dans un nouvel onglet)
• S’inscrire à l’édition de Maurice (s’ouvre dans un nouvel onglet)

Le 22 décembre 2026, MC3 Cloud organisera également une table ronde stratégique au Labourdonnais Waterfront Hotel à Maurice, avec une participation à distance via Microsoft Teams.

Patrick Beeharry, Vice President of Strategy & Operations for the Microsoft Security Division, partagera la vision de Microsoft sur la sécurité, l’IA, la gouvernance des données et les priorités à anticiper.

Cette session non technique s’adresse aux dirigeants, CIO, CISO et décideurs IT. Elle permettra de prolonger la réflexion au-delà des contrôles techniques : gouvernance, responsabilités, investissements et préparation de l’entreprise à une adoption plus large de l’IA.

Les places seront limitées afin de privilégier les échanges. Pour participer, contactez votre interlocuteur commercial MC3 Cloud.

Dans le prochain article : transformer les contrôles en décisions d’entreprise

Donner une identité aux agents, limiter leurs permissions et protéger les données fournit une base technique.

Ces contrôles ne répondent cependant pas seuls aux questions stratégiques :

• Quels usages l’entreprise souhaite-t-elle autoriser ?
• Quel niveau de risque accepte-t-elle ?
• Quelles décisions doivent rester humaines ?
• Qui assume la responsabilité d’un agent ?
• Quels investissements sont réellement nécessaires ?
• À quelles conditions un pilote peut-il être généralisé ?

Le troisième article de cette série examinera comment transformer le Zero Trust en une stratégie d’entreprise permettant d’adopter l’IA sans opposer innovation et sécurité.