Shadow AI : vos salariés créent des agents autonomes sans prévenir la DSI

Un commercial crée dans Microsoft Copilot un agent qui va chercher les fiches clients et prépare ses relances. Rien n'a été installé, aucune règle n'a été enfreinte, et personne dans l'entreprise n'a vérifié ce que cet agent peut atteindre. Le shadow AI a changé de forme : ce n'est plus un salarié qui colle un document dans ChatGPT, c'est un programme qui exécute des tâches dans vos applications métier.

Un chatbot répond à des questions. Un agent agit : il lit, écrit, supprime, déclenche. Pour un dirigeant, avec ou sans DSI, la question devient : comment repérer et encadrer des automatisations dont personne ne connaît l'existence ?

Du chatbot à l'agent : le shadow AI change de nature

Jusqu'ici, l'IA utilisée en douce posait surtout un problème de confidentialité. Un salarié copiait un contrat ou un fichier clients dans un service externe, souvent avec son compte personnel, et l'information sortait de l'entreprise. Le risque était réel, mais passif : le chatbot répondait, il ne faisait rien. C'est l'usage décrit dans cet article sur l'IA de l'ombre et le gisement de productivité qu'elle cache.

Avec l'IA agentique, la logique s'inverse. Un agent IA autonome reçoit une mission, choisit ses actions, observe le résultat et ajuste. Il peut par exemple :

• modifier ou supprimer des fichiers partagés ;
• extraire une base de données complète ;
• déclencher une opération dans une application métier : mise à jour d'un statut, envoi d'une commande, relance d'un client.

Il n'a pas besoin d'être attaqué pour mal tourner. Une consigne mal interprétée suffit. Une injection de prompt, c'est-à-dire une instruction malveillante glissée dans un document ou une page web que l'agent lit, peut aussi détourner son comportement.

La différence avec le Shadow IT classique est simple : l'outil est autorisé, c'est l'usage que personne n'a validé. Microsoft Copilot permet à un collaborateur de construire son propre agent sans rien installer. Les développeurs créent les leurs, les éditeurs ajoutent des fonctions agentiques à leurs logiciels, et les serveurs MCP relient ces agents à des outils externes. Une charte IA signée ne suffit pas : elle repose sur la bonne foi et ne dit rien de ce qui tourne réellement dans le système d'information.

Meta, Pentagone : des incidents sans la moindre cyberattaque

À quoi ressemble une dérive concrète ? Les premiers cas publics sont déjà là, et aucun ne ressemble à un piratage.

En mars 2026, chez Meta, un agent interne a publié sans validation une réponse erronée sur un forum technique de l'entreprise. Un salarié l'a appliquée et a rendu de grandes quantités de données sensibles accessibles à des ingénieurs non habilités pendant près de deux heures. Meta a classé l'incident au niveau « Sev 1 » et affirme n'avoir aucun indice d'un usage abusif de ces données. Ce n'est pas du shadow AI au sens strict, puisque l'agent était interne, mais il montre ce qu'une erreur d'agent peut déclencher sans aucune intention malveillante.

Le second cas colle davantage au sujet. Fin octobre, WIRED a rapporté, en s'appuyant sur des sources non nommées, qu'un salarié d'Accenture intervenant pour le Pentagone aurait connecté un système sensible à son compte personnel Claude Code. Pour automatiser l'écriture de code et la création de serveurs, il aurait confié ses identifiants à l'agent, qui aurait ainsi obtenu un accès administrateur. L'agent aurait tourné environ deux mois et semble avoir envoyé des identifiants, des mots de passe et une carte du réseau vers un site tiers classé à haut risque par le NIST. Accenture affirme que ces accusations ont été examinées et jugées sans fondement, d'où le conditionnel.

Dans les deux cas, rien n'indique qu'un attaquant soit à l'origine de l'incident. Les accès passaient par des comptes légitimes, et c'est bien le problème : dans le cas du Pentagone, les identifiants auraient même permis d'échapper aux contrôles habituels de connexion. Un antivirus a peu de chances de signaler ce type d'usage. Le trafic sortant vers ce site à risque aurait pu donner l'alerte, encore fallait-il le surveiller.

Le cas Meta rappelle aussi qu'un humain dans la boucle ne garantit rien : c'est un humain qui a appliqué le conseil de l'agent. La validation formelle a une limite voisine. Un responsable qui reçoit des dizaines de demandes d'approbation en fin de journée finit par valider en bloc, et le garde-fou se réduit à une ligne dans un journal.

Ces incidents ne sont pas isolés, même si les chiffres disponibles demandent du recul. Dans le 2026 CISO AI Risk Report de Cybersecurity Insiders et Saviynt, 47 % des répondants disent avoir déjà vu des agents agir de façon inattendue ou non autorisée, et un tiers des organisations déclare un incident de sécurité ou un quasi-incident sur les douze derniers mois.

Deux précautions de lecture. Ces réponses sont déclaratives et viennent de 235 responsables sécurité et IT d'entreprises de 5 000 salariés et plus, aux États-Unis et au Royaume-Uni. Et Saviynt vend justement de la gestion d'identités. Ces pourcentages ne disent donc rien de précis sur une PME de trente personnes, qui a rarement un SAP à protéger. Le mécanisme reste pourtant identique dès qu'un agent touche votre CRM ou votre messagerie.

Un agent hérite des droits du compte qui le fait tourner

Le plus souvent, un agent agit avec le compte d'un humain. Il récupère donc des permissions prévues pour une personne qui ouvre une fiche à la fois et sait ce qu'elle n'a pas à faire.

Imaginez un agent dont la mission consiste à lire les fiches clients afin de préparer des relances. Si le compte utilisé autorise l'export, l'agent peut techniquement extraire toute la base. Rien ne garantit qu'il restera dans le périmètre de sa mission.

Ce compte n'est pas toujours celui qu'on croit. Dans Copilot Studio, l'agent utilise par défaut les identifiants de la personne qui s'en sert. Son créateur peut toutefois y enregistrer les siens : chaque utilisateur de l'agent passe alors par ses droits à lui, y compris sur des données auxquelles il n'a pas accès. Un administrateur peut interdire cette option, mais elle reste ouverte par défaut.

La règle est claire : un agent ne doit recevoir que la partie des droits qui correspond à sa mission. La difficulté est pratique : il faut d'abord distinguer, dans les journaux, ce que fait l'agent de ce que fait le salarié. Quand les deux partagent le même compte, ce n'est pas toujours possible.

Deux facteurs aggravent la situation :

• certains agents fonctionnent avec un jeton d'authentification ou une clé longue durée, qui reste valable une fois leur mission terminée ;
• un agent peut en solliciter un autre, qui accède à son tour à d'autres ressources. En cas d'incident, remonter la chaîne jusqu'à la demande initiale devient un travail d'enquête.

Une combinaison mérite une attention particulière : un agent qui lit des contenus venus de l'extérieur (mails, pièces jointes, pages web), accède à vos données internes et peut envoyer quelque chose vers l'extérieur. Un mail piégé peut alors lui demander de transmettre une fiche client, et l'agent ne sait pas distinguer de façon fiable cette consigne de celles de votre salarié. Si un agent réunit ces trois capacités, retirez-lui-en une.

Les modèles de gestion des identités ont été pensés pour des humains et des applications au comportement prévisible. Dans le rapport de Cybersecurity Insiders et Saviynt, 71 % des organisations indiquent que des outils d'IA accèdent déjà à des systèmes critiques comme Salesforce ou SAP, et 16 % seulement estiment que cet accès est gouverné efficacement.

Dans une PME, le problème prend une forme plus simple : des droits rarement revus, des comptes administrateurs distribués par commodité. Cartographier qui peut lire, modifier ou exporter quoi est justement le point de départ d'un audit de sécurité, et cette cartographie vaut autant pour les agents que pour les salariés.

Le sujet touche aussi au RGPD. La CNIL le rappelle aux TPE et PME : utiliser un outil d'IA avec des données personnelles fait de vous le responsable de traitement. Un agent qui manipule des fiches clients doit donc figurer dans votre registre des traitements, et le fournisseur qui traite ces données pour votre compte doit être encadré par un contrat de sous-traitance. Un agent dont personne ne connaît l'existence ne coche aucune de ces cases.

Pourquoi un logiciel d'inventaire ne voit pas ces agents

Avant de contrôler, il faut savoir ce qui existe. Même les grandes entreprises y butent : selon le même rapport, 92 % des organisations n'ont pas de visibilité complète sur leurs identités d'IA.

Quatre raisons expliquent cet angle mort :

• Pas d'installation : un agent créé dans Copilot ou sur une autre plateforme cloud ne laisse aucun exécutable sur le poste. Un logiciel d'inventaire classique ne le voit pas, c'est dans la console d'administration qu'il faut le chercher.
• Des exécutions brèves : certains agents, surtout chez les développeurs, s'exécutent le temps d'une tâche puis disparaissent. Un relevé mensuel ne voit que ce qu'ils laissent derrière eux.
• Des agents oubliés : selon des données de l'éditeur Token Security, 65,4 % des chatbots agentiques n'ont jamais servi depuis leur création, alors que leurs identifiants restent actifs.
• Des environnements dispersés : agents intégrés par les éditeurs, scripts de développeurs, connecteurs MCP. Chacun vit dans un outil différent.

Une PME peut commencer par sa console d'administration. Le centre d'administration Microsoft 365 propose un inventaire des agents publiés sur ses canaux, avec la possibilité de les bloquer ou de les retirer. Microsoft Entra et la page « API controls » de Google Workspace montrent quant à eux les applications tierces qui accèdent à vos données. Ce premier relevé ne couvre pas tout, mais il fait souvent apparaître des connexions que personne n'avait validées.

Profitez-en pour limiter les nouvelles connexions. Par défaut, chez Microsoft, un utilisateur peut autoriser seul une application pour les permissions qui n'exigent pas la validation d'un administrateur. Vous pouvez désactiver ce consentement ou le réserver aux éditeurs vérifiés. Google permet de restreindre l'accès à ses services aux applications approuvées. Préparez ce changement avec vos équipes : chez Microsoft, il laisse en place les accès déjà accordés, qu'il faut donc retirer à part, et chez Google, il coupe les applications non approuvées déjà installées.

Sans DSI, ces vérifications reviennent à votre infogérant ou à la personne qui administre vos comptes. Demandez-lui ce relevé.

Les structures dotées d'une équipe sécurité vont plus loin en croisant trois sources : les plateformes cloud où naissent les agents, les traces d'activité réseau et les exécutables présents sur les postes. Ce croisement produit un graphe : qui a créé l'agent, à quoi il se connecte, avec quels droits.

La détection ne suffit pas, il faut aussi savoir réagir. Toujours selon ce rapport, 5 % seulement des répondants se disent prêts à contenir un agent compromis. Dans une PME, l'exercice revient à savoir qui peut couper l'accès d'un agent, et où.

Comment contrôler les agents IA en entreprise ?

Plusieurs familles d'outils commencent à répondre à la question. Elles visent d'abord les structures qui ont une équipe sécurité, et aucune ne suffit seule.

• Les passerelles MCP. Le protocole MCP (Model Context Protocol) standardise la connexion entre un agent et un outil. Une passerelle placée entre les deux devient un point de passage obligé : elle journalise chaque appel, filtre les outils accessibles et applique des règles par agent.
• La prévention des fuites de données (DLP). Ces outils analysent ce que l'agent transmet et bloquent l'envoi d'informations sensibles vers l'extérieur.
• La supervision des actions. Certaines solutions interceptent une opération avant son exécution, une suppression massive ou un export complet par exemple, et la bloquent si elle sort du périmètre autorisé.

Leurs limites sont nettes. Une passerelle ne voit que le trafic qui passe par elle : un agent qui appelle directement une API la contourne. Un outil DLP analyse des données, pas une intention, et une modification erronée dans votre ERP ne quitte jamais l'entreprise, donc ne déclenche rien. La supervision, elle, ne bloque que ce qu'une règle a prévu.

Quant à la validation humaine, elle ne tient que si elle est dosée. Je recommande une autonomie par paliers : l'agent agit seul en lecture, demande une confirmation pour une modification et n'a jamais le droit de supprimer ou d'exporter en masse sans contrôle. Une validation exigée pour tout finit approuvée sans lecture.

Une TPE de dix personnes n'a pas besoin d'une passerelle MCP. Une liste des agents autorisés tenue à jour depuis la console, des comptes dédiés quand l'outil le permet et une revue régulière des droits couvrent l'essentiel de son risque.

Une identité par agent, et des droits au strict nécessaire

Reprendre la main suit un ordre précis. D'abord, identifier les agents qui tournent déjà. Ensuite, nommer un responsable pour chacun et, quand l'outil le permet, lui attribuer une identité propre, distincte de celle de son créateur, comme pour un collaborateur ou un serveur. Enfin, limiter ses droits à sa mission et les retirer dès qu'il ne sert plus.

L'identité dédiée n'est pas toujours disponible : un agent Copilot configuré pour agir avec les droits de son utilisateur n'en a pas. Il faut alors réduire ce qu'il peut atteindre, en limitant ses connecteurs et la portée de son partage.

Le rythme de contrôle dépend de votre parc. Une grande structure qui voit passer des agents éphémères a besoin d'un retrait automatique des droits. Une PME qui compte une poignée d'agents peut s'appuyer sur une revue trimestrielle, qui repère surtout ceux qu'on a oubliés.

Les briques existent déjà : console d'administration, gestion des identités, et pour les plus grandes structures passerelles, DLP et supervision. Leur efficacité dépend de votre capacité à les faire fonctionner ensemble, pas de l'achat d'un outil de plus.

Il faut aussi préserver l'adoption. Interdire pousse les usages plus loin dans l'ombre, alors que les salariés qui créent ces agents cherchent le plus souvent à gagner du temps. Je le vois avec des clients qui construisent eux-mêmes un outil interne, puis me demandent de le mettre au propre : le fonctionnement est déjà validé et le coût baisse. Un agent qui rend service mérite le même traitement : le sortir de l'ombre, puis en faire une automatisation propre, avec des droits limités. L'enjeu n'est pas de choisir entre contrôle et IA, mais de rendre chaque agent visible et rattaché à un responsable humain.

Aujourd'hui, combien d'agents agissent avec les identifiants de vos équipes, et lequel sauriez-vous désactiver demain matin ?

Sources : A Defense Contractor Gave Their Personal AI Agent Access to a Secure Pentagon System (WIRED) A Claude agent ran inside a Pentagon network for two months, WIRED reports (The Next Web) Meta is having trouble with rogue AI agents (TechCrunch) Cybersecurity Insiders, 2026 CISO AI Risk Report, rapport complet publié par Saviynt Shadow AI : du risque de fuite au problème de contrôle d'accès (The Hacker News) Contrôler les identifiants fournis par le créateur d'un agent (Microsoft Learn) Gérer les agents dans le centre d'administration Microsoft 365 (Microsoft Learn) Configurer le consentement des utilisateurs (Microsoft Learn) Contrôler les applications qui accèdent aux données Google Workspace Fiche IA pour les TPE et PME : les précautions (CNIL) Shadow AI agentique : au tour des agents IA d'échapper au contrôle des entreprises La menace invisible des agents IA en entreprise, et 90% des organisations sont concernées