Shadow AI agentique : au tour des agents IA d’échapper au contrôle des entreprises

Le Shadow AI dans les entreprises est au moins aussi vieux que l’apparition des premiers LLM grand public. Autant dire : rien de vraiment nouveau. Depuis, les entreprises découvrent encore sans cesse que leurs collaborateurs utilisent des outils d’intelligence artificielle sans nécessairement en informer l’interlocuteur directement concerné ; DSI, RSSI ou autre. Et jusque-là, le principal risque concernait alors la confidentialité des données, notamment lorsque des informations internes étaient copiées dans des services non autorisés. Mais avec l’émergence de l’IA agentique le problème change (complètement) de nature. Les salariés peuvent désormais déployer des agents capables d’exécuter des tâches et d’interagir directement avec les applications de l’entreprise.

Or ces agents ne nécessitent pas toujours l’installation d’un nouvel outil ; contrairement aux LLM pour lesquels dans de nombreux cas les utilisateurs utilisaient leur compte personnel notamment. Certaines plateformes déjà présentes dans les systèmes d’information permettent déjà aux collaborateurs de créer leurs propres agents. On pense notamment à Microsoft Copilot. Un salarié peut ainsi mettre en place une automatisation susceptible d’accéder à des ressources internes, sans que les équipes de sécurité aient nécessairement connaissance de son existence.

Le phénomène est d’autant plus difficile à appréhender que les agents se multiplient dans des environnements très différents. Les développeurs créent leurs propres agents tandis que les éditeurs intègrent progressivement des fonctions agentiques dans leurs logiciels. Les serveurs MCP, qui permettent de connecter des agents à des outils externes, ouvrent également de nouvelles possibilités d’interaction.

Pour les entreprises, cette évolution complique considérablement la surveillance des usages. Et beaucoup ne savent déjà pas précisément ce qui se passe dans leur environnement. « On a fait signer des chartes IA aux collaborateurs, mais une charte surtout c’est de la bonne foi, ça ne dit rien sur l’utilisation réelle », sourit Sébastien Félio, Responsable France de Velatir, spécialiste de la sécurité et de la gouvernance de l’IA. Le Shadow AI ne se limite donc plus à des collaborateurs qui interrogent des modèles dans leur coin. Il concerne désormais des logiciels capables d’agir au sein du système d’information, parfois sans véritable supervision.

Quand le Shadow AI devient un risque opérationnel

Avec le Shadow AI agentique, les risques pour les entreprises vont bien au-delà de la confidentialité des données. Un agent peut extraire des informations sensibles, tout comme modifier ou supprimer des fichiers. Il peut également déclencher des opérations directement dans les applications métiers, avec des conséquences sur l’activité de l’entreprise. Et évidemment, pas besoin d’une cyberattaque : une erreur d’interprétation de sa mission peut suffire. Une injection de prompt malveillante peut également détourner son comportement. Bref, les exemples sont déjà nombreux. 

Et les premiers incidents sont même déjà là. En mars 2026 chez Meta, les recommandations erronées d’un agent IA (publiées sans validation) ont conduit un salarié à rendre des données sensibles accessibles à des employés non habilités pendant près de deux heures. Plus récemment, il semble qu’un prestataire aurait connecté son agent Claude Code personnel à un réseau sécurisé du Pentagone pendant deux mois, avant sa détection. 

Le plus inquiétant étant qu’un agent IA peut provoquer de tels dégâts sans avoir à contourner le moindre dispositif de sécurité. Il lui suffit parfois d’utiliser les droits dont il dispose car lorsqu’il agit avec le compte d’un collaborateur, il hérite souvent de permissions initialement prévues pour un humain, sans que l’entreprise ait nécessairement encadré cette nouvelle manière de les exploiter. On entend déjà dire que certains agents utilisent des comptes de service ou des jetons d’authentification qui leur donnent accès à des ressources sensibles pendant plusieurs semaines… 

Cette question des permissions est justement au cœur des préoccupations. « Il doit hériter d’une partie de mes droits qui correspond à la mission que je lui ai donnée, mais jamais l’intégralité de mes droits », explique Vincent Steenhoute, solution engineer chez Okta. Une distinction fondamentale, mais qui suppose de pouvoir différencier les actions d’un agent de celles du collaborateur dont il utilise les identifiants.

Le problème prend une autre dimension lorsqu’on considère ce que ces agents sont capables de faire avec leurs privilèges. Un agent chargé de consulter des fiches clients peut aussi, si ses permissions le permettent, extraire l’ensemble d’une base de données. Et rien ne garantit qu’il respectera toujours le périmètre de la mission qui lui a été confiée.

Enfin, il faut aussi compter sur la multiplication des interactions entre agents. Un agent peut en solliciter un autre pour accomplir une partie de sa mission, lequel peut à son tour accéder à d’autres ressources. Une chaîne d’actions se constitue ainsi, parfois à partir d’une simple demande humaine. Et en cas d’incident, retrouver l’origine d’une opération et identifier les permissions utilisées devient alors beaucoup plus compliqué.

Comment surveiller des agents dont on ignore l’existence ?

Avant de pouvoir contrôler le Shadow AI agentique, encore faut-il en dresser l’inventaire. Et c’est là que les choses se compliquent souvent. Repérer un logiciel installé sur un ordinateur ne suffit pas : certains agents sont créés directement sur une plateforme cloud, sans nouvel exécutable sur le poste. Il faut donc retrouver leur créateur, les ressources auxquelles ils se connectent et les droits qui leur ont été accordés.

Première piste : interroger les plateformes où naissent ces agents. Okta décrit des connecteurs qui explorent les environnements Microsoft et Azure pour identifier les agents créés par les utilisateurs. Ils récupèrent également les informations sur leurs responsables et leurs accès. Le résultat peut prendre la forme d’un graphe : on y verra par exemple qu’un agent est connecté à une application métier et s’il dispose de droits de lecture ou de suppression.

Mais cette méthode ne couvre pas les agents installés localement. Sur les postes, des outils peuvent repérer l’exécutable d’un assistant comme Codex, puis examiner ses connexions. Communique-t-il avec une API ou un serveur MCP ? Les proxys réseau permettent quant à eux de repérer certains échanges avec des agents non déclarés. La cartographie suppose donc de croiser les inventaires des plateformes cloud avec les observations faites sur les postes et le réseau.

Reste une difficulté moins visible : la durée de vie de ces programmes. « Parfois, les agents sont créés pour quelques secondes, le temps d’exécuter une simple tâche. La question est désormais de savoir comment administrer l’identité donnée à un tel agent éphémère », observe et anticipe Vincent Steenhoute de chez Okta. Un inventaire ponctuel peut ainsi manquer un agent apparu puis disparu entre deux contrôles ; d’où la nécessité de renouveler les découvertes et de conserver des traces permettant de reconstituer les actions réalisées.

Enfin, l’inventaire ne vaut que s’il permet de hiérarchiser les risques : un agent limité à la lecture n’a pas le même impact potentiel qu’un autre autorisé à effacer des données. Encore faut-il que les systèmes surveillés rendent ces permissions visibles.

Reprendre le contrôle sans freiner l’adoption de l’IA

Une fois les agents identifiés, reste à décider ce qu’ils ont réellement le droit de faire. Tout interdire n’est d’ailleurs pas forcément la solution. L’enjeu premier sera plutôt d’attribuer une identité propre, associée à un responsable humain, puis à limiter leurs permissions au strict nécessaire. Un agent chargé de consulter une base clients n’a aucune raison de pouvoir en supprimer les enregistrements ! Et lorsqu’une opération sort du cadre prévu, une validation humaine peut être exigée avant son exécution.

Mais encore faut-il pouvoir faire respecter ces règles et à ce nouveau jeu, plusieurs mécanismes commencent à se dessiner. Les passerelles MCP peuvent servir de points de contrôle entre les agents et les applications auxquelles ils accèdent. Sur les postes de travail, certains dispositifs permettent déjà de bloquer une action non autorisée avant son exécution. Les outils de prévention des fuites de données peuvent également analyser les informations transmises aux services d’IA, jusqu’aux fichiers joints. Mais ces protections ne couvrent pas nécessairement toutes les actions réalisées par un agent.

Velatir déploie quant à lui sa solution directement sur les navigateurs et les postes de travail pour identifier les usages IA. Sa plateforme peut bloquer l’accès à certains services et filtrer les prompts ou pièces jointes contenant des données sensibles, avec des règles différentes selon les équipes. Une difficulté à venir concerne notamment les agents développés directement dans les entreprises. « On a un SDK qui nous permet de nous connecter aux agents créés par le client », explique Sébastien Félio de Velatir. Ce kit de développement permet d’intégrer ces agents aux dispositifs de supervision. L’éditeur prévoit également de déployer une passerelle MCP à partir de fin novembre, afin d’encadrer leurs connexions aux services externes.

Ces différentes approches montrent que la réponse au Shadow AI agentique se construit encore. Les entreprises disposent déjà de plusieurs moyens de contrôle, mais leur efficacité dépend de leur capacité à les faire fonctionner ensemble. Une difficulté supplémentaire dans des SI où les agents peuvent désormais apparaître sans passer par les circuits habituels de validation.

——-

Sources 

: 

• Incident chez Meta : https://www.theinformation.com/articles/inside-meta-rogue-ai-agent-triggers-security-alert
• Incident au Pentagone : https://www.wired.com/story/a-defense-contractor-gave-their-personal-ai-agent-access-to-a-secure-pentagon-system/

——-

FAQ

1. Un agent IA peut-il échapper à la DSI tout en utilisant un logiciel autorisé ?

Oui. Des plateformes comme Microsoft Copilot permettent de créer des agents directement dans un environnement déjà utilisé par l’entreprise. Leur présence dans un logiciel approuvé ne signifie pas que chaque agent a été identifié ou validé par les équipes de sécurité.

2. Un agent IA peut-il disposer de plus de droits que nécessaire sans pirater de compte ?

Oui s’il utilise les identifiants d’un collaborateur, il peut exploiter toutes les permissions associées, même celles inutiles à sa mission. Des comptes de service peuvent également lui donner accès à des ressources sensibles.

3. Pourquoi certains agents IA sont-ils particulièrement difficiles à détecter ?

Parce qu’ils peuvent être créés dans le cloud, sans installation locale, et ne fonctionner que quelques secondes. Un inventaire ponctuel ne suffit donc pas. La détection nécessite de croiser les informations des plateformes avec les traces d’activité conservées.

4. Une passerelle MCP suffit-elle à sécuriser les agents IA d’une entreprise ?

Non, elle permet d’encadrer les connexions qui passent par elle mais ne couvre pas nécessairement tous les usages. La surveillance des postes et le contrôle des permissions restent complémentaires, notamment pour les agents qui utilisent d’autres mécanismes de connexion.