Copilot voit tout ce que l’utilisateur voit

La plupart des entreprises françaises ne vont pas découvrir l’IA d’entreprise sur une stack maison en modèles open source. Elles vont la découvrir via Microsoft : Copilot dans Microsoft 365, Security Copilot dans le SOC, Azure OpenAI pour les développeurs, Copilot Studio et Azure AI Foundry pour fabriquer leurs propres agents. C’est le tuyau par défaut. C’est donc là que la question « comment sécuriser l’IA » va se poser pour de vrai, dans des organisations qui n’ont ni red team IA ni doctrine maison.

Le constat rejoint le titre : Copilot répond en s’appuyant sur tout ce que l’utilisateur a le droit de voir. Plutôt que de créer une faille, il révèle à la vitesse de la conversation la mauvaise gouvernance de permissions et de données que personne n’allait plus regarder. Sécuriser l’IA chez Microsoft, c’est donc trois réflexes, dans cet ordre : qui voit quoi, qui agit avec quels droits, qui valide et trace les sorties.

Comment j’ai trié cette veille

Je tiens une veille cyber quotidienne depuis ma reconversion. Pour cet article, j’ai repris deux mois et demi de digests, de mars à début juin 2026, et je les ai relus sous un seul angle : l’IA Microsoft, Copilot et Azure OpenAI, sans glisser vers la sécurité M365 en général. Ce cadrage est volontaire. La tentation, quand on relit de la veille, c’est de tout relier à tout ; je me suis forcé à écarter ce qui ne touchait pas directement la donnée que l’IA lit, l’identité avec laquelle elle agit, ou la trace qu’elle laisse. Les incidents et chiffres qui suivent viennent de ces sources, cités au fil du texte. Je m’attache à l’architecture défensive plus qu’aux anecdotes d’incidents, et je signale quand un chiffre me paraît à recouper.

Premier réflexe : la donnée que Copilot indexe

Le principe de Copilot pour Microsoft 365 est ce qui le rend puissant et ce qui le rend dangereux : il puise dans SharePoint, OneDrive, Teams et les e-mails, dans la limite de ce que l’utilisateur a le droit de consulter. S’il existe un site SharePoint partagé « à toute l’organisation » par paresse, un dossier RH oublié dans un espace trop ouvert, un export de paie rangé là où il ne devrait pas, Copilot ne va pas le pirater. Il va le retrouver et le résumer à la première question qui s’en approche. Le terme qui circule pour ça, c’est l’oversharing. Copilot transforme une dette de gouvernance invisible, parce que personne n’allait fouiller à la main, en moteur de recherche redoutablement efficace sur les données mal cloisonnées.

Ma veille a relevé mi-mai un signal qui ne vient pas d’un concurrent mais de Microsoft : des chercheurs de l’éditeur recommandaient de ne pas confier de documents sensibles à un assistant IA grand public, Copilot inclus, en pointant les risques d’extraction par injection de prompt, de rétention opaque et de réutilisation pour l’entraînement. Quand le fournisseur met ce bémol par écrit, ça mérite d’être entendu. Dans le même registre, une note de fin mars rappelait que GitHub Copilot pouvait utiliser les données d’usage pour entraîner ses modèles, et mi-mai l’intégration d’assistants tiers directement dans Word, Excel, PowerPoint et Outlook posait la même question, en plus large : qu’est-ce qui sort du périmètre M365 quand un assistant lit le classeur ouvert ?

Il y a aussi l’entrée, pas seulement la sortie. Plusieurs cas de la période montrent qu’on peut empoisonner ce que l’assistant lit pour le détourner. Fin mai, Microsoft alertait sur des URL recommandées par des chatbots IA, détournées par empoisonnement du corpus, qui menaient au téléchargement de mineurs de cryptomonnaie. Plus tôt, plusieurs sources décrivaient de la fausse documentation technique publiée pour que Copilot ou Cursor recommandent des paquets malveillants. On ne pirate pas l’assistant, on contamine sa source pour qu’il devienne un canal de recommandation hostile. C’est l’injection de prompt indirecte appliquée à l’assistant de Microsoft.

La réponse se joue moins dans un réglage Copilot que dans la gouvernance de la donnée, et elle a un nom dans l’écosystème : Purview. Étiquettes de sensibilité, classification, prévention de fuite, et surtout cadrage de ce que Copilot a le droit d’indexer. Restreindre ce que voit un modèle, c’est la même logique que le row-level security dans Power BI : on ne montre à chaque acteur que les lignes auxquelles il a droit. La différence, c’est l’échelle de l’erreur. Une étiquette de confidentialité mal posée ne fuit plus une ligne dans un rapport que personne ne lit, elle fuit un résumé synthétique de tout le corpus mal classé, à la demande. Avec Copilot, la gouvernance de la donnée cesse d’être un chantier de fond reportable pour devenir une condition de sécurité immédiate.

Deuxième réflexe : Copilot et les agents sont des acteurs non-humains privilégiés

Tant qu’on parle de Copilot qui répond à une question, le risque reste de la lecture. Dès qu’on passe aux agents, Copilot qui agit, qui envoie un mail, met à jour un enregistrement, déclenche un workflow, on entre dans l’exécution. Et là, l’assistant n’est plus un moteur de recherche, c’est une identité qui fait des choses avec des droits.

C’est le réflexe que je trouve le plus mal pris dans les déploiements que ma veille décrit. On raisonne Copilot comme un outil, alors qu’il faut le raisonner comme un acteur non-humain privilégié. Une étude Omdia de fin mai, menée auprès de RSSI, posait d’ailleurs une distinction utile : l’identité d’un agent IA n’est pas une identité de service classique. Un compte de service est déterministe, il fait toujours la même chose, on peut lui figer un périmètre. Un agent est non-déterministe, son comportement dépend du contexte et peut être détourné par une instruction glissée dans les données qu’il traite. Ça en fait une catégorie d’identité à part, qui demande ses propres contrôles : périmètre minimal, accès contextuels, jetons éphémères, et un journal de ce que l’agent a réellement fait.

Microsoft a pris le sujet par le bon bout fin mai, en annonçant des contrôles de sécurité directement dans la fabrication des agents, côté Azure AI Foundry et Copilot Studio, adossés à Defender for Cloud. L’idée juste, c’est de mettre la sécurité dans le pipeline de construction de l’agent plutôt qu’en revue après déploiement. Quand un métier va bricoler son agent dans Copilot Studio, la question n’est pas « est-ce qu’il marche », c’est « avec quelle identité il s’authentifie, sur quelles données, avec quels droits d’écriture, et qui a validé ce périmètre ». Le risque concret, je le résumerais ainsi : un agent Copilot Studio mal cadré, c’est un stagiaire à qui on aurait donné le badge d’un directeur et aucune supervision.

Je garde volontairement de côté les grandes campagnes d’attaque d’identité M365 de la période, parce qu’elles ne sont pas spécifiques à l’IA. Une seule mérite une mention ici, parce qu’elle vise précisément la manière dont un agent obtient ses droits : le phishing par code d’appareil et par consentement OAuth, qui fait autoriser une application ou capter un jeton sans jamais voler de mot de passe. C’est exactement par ce flux qu’un agent ou un connecteur se voit accorder des accès, et c’est pour ça qu’il faut gouverner les consentements applicatifs et préférer une authentification résistante au phishing. Le reste, le vol de session, le mouvement latéral, relève de la sécurité M365 générale, pas du sujet IA, et je l’ai écarté pour ne pas diluer le propos.

Troisième réflexe : superviser les sorties, et la défense IA de Microsoft

Une fois la donnée cadrée et l’agent identifié, reste la question que toute ma posture met en avant : qui valide, et comment on rejoue une décision. Un agent IA qui agit sans traçabilité, c’est un audit impossible et une responsabilité dans le vide.

Côté supervision, l’écosystème Microsoft a les briques : les journaux d’Entra et de Microsoft 365 pour savoir ce qu’un compte ou un agent a fait, Sentinel pour corréler et alerter sur l’anormal, Defender qui a gagné sur la période l’isolement automatique d’un appareil compromis pour casser le mouvement latéral. La logique défensive qui vaut pour les attaques modernes vaut aussi pour les agents : on ne détecte pas un comportement malveillant légitime en apparence avec une liste noire, on le détecte par l’analyse comportementale, en repérant qu’un acteur fait quelque chose d’inhabituel.

Microsoft est aussi devenu un acteur de la défense par l’IA, et la période l’a montré. Un système interne multi-agents, « MDASH » dans ma veille, aurait identifié une partie des failles corrigées lors d’un Patch Tuesday, en exploitant l’accès aux codebases internes de Windows, Azure et Office. L’éditeur a publié des outils open source pour la sécurité des agents : un framework de red teaming agentique basé sur Pytest, pour tester jailbreak, injection de prompt et exfiltration, et un outil d’observabilité pour tracer les décisions d’un agent. C’est du « shift-left » appliqué à l’IA, et c’est la bonne direction.

Je garde quand même un réflexe critique, parce que la posture security-first interdit de confondre « Microsoft propose de la sécurité IA » et « Microsoft est sécurisé par défaut ». D’abord parce que la même période a vu des correctifs fragiles côté Microsoft, des régressions, des zero-days dans Defender lui-même, des indisponibilités de la MFA, autant de rappels qu’aucun socle n’est increvable. Ensuite parce que les chiffres marketing autour de l’IA chasseuse de failles méritent du recul : un article de la période tempérait sérieusement une annonce de « milliers de zero-days » découverts par IA, en montrant qu’elle reposait sur un nombre bien plus modeste de revues manuelles extrapolées. La posture d’analyste tient justement là : regarder la méthode derrière le chiffre plutôt que relayer le communiqué. L’AI washing existe aussi en sécurité.

La question souveraine : où passe la donnée Copilot

Impossible de cadrer un déploiement Copilot ou Azure OpenAI sans poser la question de la résidence. Où vont les prompts, les documents, les conversations ? Le débat français sur le Health Data Hub, qui a quitté Azure pour un hébergeur qualifié SecNumCloud, relève moins du caprice politique que de l’architecture et du droit : le CLOUD Act et FISA d’un côté, le RGPD de l’autre. La formule « l’accès des autorités américaines ne peut être exclu » n’a rien de neutre dès qu’on branche l’IA sur des données réglementées.

Ça ne veut pas dire bannir Azure OpenAI ou Copilot. Ça veut dire savoir poser la question du périmètre de confiance avant de connecter l’IA à des données sensibles, et accepter que pour certains cas la bonne réponse soit une alternative européenne ou un déploiement maîtrisé, pas par militantisme mais par analyse. C’est un terrain où la conformité française, RGPD, IA Act, NIS2, et l’architecture technique se rejoignent. C’est exactement le genre de dialogue entre besoin métier et contrainte réglementaire qu’il faut savoir mener ici.

Ce que j’en retiens

Sécuriser l’IA chez Microsoft revient moins à configurer Copilot qu’à faire un exercice de triade CIA sur deux objets qu’on connaît déjà, la donnée et l’identité, plus un troisième qu’on néglige souvent, la traçabilité. La confidentialité, c’est Purview et le périmètre de ce que Copilot a le droit de voir. L’intégrité et la disponibilité, c’est le cadrage de l’identité de l’agent et de ses droits d’action. La traçabilité, c’est Sentinel et les journaux qu’on apprend à lire pour pouvoir rejouer une décision. Copilot, dans ce tableau, n’est pas un produit à part. C’est un acteur non-humain privilégié, à gouverner comme tel.

La question que je me pose désormais devant n’importe quel cas d’usage Copilot ou Azure OpenAI tient en trois bouts : qui voit quoi, où passe la donnée, qui valide les sorties. Si je ne sais pas répondre aux trois, le déploiement n’est pas prêt, quel que soit l’enthousiasme autour de l’outil. Ce triptyque a un mérite que je revendique : il transforme une douzaine d’années passées à gouverner la donnée en compétence directement utile pour la vague qui arrive.

La veille à suivre

Je ne prétends pas que ce triptyque couvre tout, et il y a un angle où je dois encore creuser : la sécurité des agents fabriqués dans Copilot Studio, là où un métier va monter son propre agent sans cadre. Je continue aussi à suivre ce que Microsoft pousse côté Defender for Cloud et Azure AI Foundry sur le cadrage des agents à la construction, parce que c’est là que se joue la prochaine bascule. La suite concrète, pour moi, c’est de monter un petit tenant de test et de regarder de mes yeux ce que Copilot remonte quand les permissions sont mal réglées, plutôt que de le lire dans une veille.

Article tiré de ma veille quotidienne (mars à juin 2026). Les incidents et chiffres viennent de mes sources de veille ; à recouper sur les publications primaires avant toute réutilisation.