Shadow Agents : Le Nouveau Risque Insider Causé par l'IA Agentique

Alors que les entreprises commencent à peine à cerner les risques du Shadow AI — ces usages non autorisés d'outils IA par les employés — une menace plus sophistiquée et plus dangereuse émerge en 2026 : les Shadow Agents. Il ne s'agit plus d'un collaborateur utilisant ChatGPT pour rédiger un rapport sans en informer sa DSI, mais d'agents IA autonomes déployés sans autorisation, opérant dans l'ombre du système d'information, exécutant des tâches de manière persistante et souvent avec des permissions héritées de leur créateur. La distinction est fondamentale : un outil Shadow AI a une portée limitée à l'instant de son utilisation, tandis qu'un Shadow Agent continue d'agir après que son créateur a quitté son bureau — parfois toute la nuit, parfois pendant des semaines. Selon une étude publiée par Gartner en janvier 2026, 34 % des entreprises ayant déployé des plateformes de développement d'agents en self-service ont détecté des agents non inventoriés dans leur infrastructure dans les six mois suivant le déploiement. Ce chiffre monte à 57 % dans les grandes entreprises (plus de 10 000 employés) où la surface de déploiement est plus large et la supervision plus difficile. Les Shadow Agents représentent une nouvelle catégorie de risque insider qui exige des approches de détection et de mitigation spécifiques, distinctes de celles employées pour le Shadow IT traditionnel.

Shadow Agents vs Shadow AI : des risques fondamentalement différents

La confusion entre Shadow AI et Shadow Agents est fréquente mais coûteuse en termes de stratégie de sécurité. Ces deux phénomènes, bien que connexes, se distinguent sur des dimensions critiques.

Le Shadow AI désigne l'utilisation non autorisée d'outils et de services IA par des collaborateurs. Un employé qui utilise Claude pour analyser un document confidentiel, un commercial qui charge des données clients dans ChatGPT pour personnaliser une proposition : voilà du Shadow AI. Le risque principal est la fuite de données — ponctuelle, liée à un acte humain délibéré ou non, et cessant généralement quand la session se termine.

Les Shadow Agents sont fondamentalement différents : ce sont des agents IA autonomes déployés sans autorisation formelle, opérant de manière persistante sur l'infrastructure ou dans les environnements SaaS de l'entreprise. Un développeur qui déploie un agent LangGraph pour automatiser le traitement des tickets dans Jira en lui donnant ses propres credentials, un analyste qui crée un agent n8n connecté aux APIs Salesforce pour automatiser ses rapports : voilà des Shadow Agents. Ces agents continuent d'opérer en l'absence de leur créateur, accumulent des logs d'actions, peuvent être compromis ou manipulés, et génèrent des risques légaux et de conformité continus.

Les Shadow Agents aggravent également les risques de Shadow AI car ils industrialisent les pratiques non autorisées : au lieu d'une fuite ponctuelle de données, on risque un exfiltration automatisée et répétée.

Comment les Shadow Agents apparaissent dans votre organisation

Trois chemins principaux mènent à l'apparition de Shadow Agents dans une organisation.

Chemin 1 — Les plateformes no-code et low-code : Zapier AI, Microsoft Power Automate avec Copilot, Make (anciennement Integromat), n8n cloud. Ces outils permettent à des utilisateurs non techniques de créer des automatisations agentiques sans aucune compétence en programmation. La barrière d'entrée est extrêmement basse, et les organisations qui ont déployé ces plateformes sans politique d'usage claire se retrouvent rapidement avec des dizaines d'agents non inventoriés.

Chemin 2 — Les équipes de développement en mode « move fast » : Des développeurs créent des agents pour résoudre des problèmes ponctuels (« je vais juste créer un petit agent qui trie les e-mails du support »), les déploient rapidement, et passent à autre chose. Ces agents fonctionnent indéfiniment, souvent avec des credentials codés en dur qui ne sont jamais révoqués.

Chemin 3 — Les abonnements individuels à des plateformes agentiques : Des collaborateurs souscrivent à des services agentiques avec leur carte de crédit personnelle ou via des comptes departementaux : AgentGPT, Relevance AI, ou des configurations avancées de ChatGPT Teams. Ces agents opèrent dans le cloud du fournisseur, hors de tout périmètre de contrôle IT.

Dans tous ces cas, la motivation est souvent légitime (productivité, résolution d'un problème réel), mais l'absence de cadre formel crée des risques systémiques.

Scénarios de collusion inter-agents : le risque le plus dangereux

La collusion inter-agents est le scénario de menace le plus complexe associé aux Shadow Agents. Elle peut se produire de deux manières.

Collusion involontaire : Deux Shadow Agents accèdent aux mêmes ressources partagées (une base de données, un service d'e-mail, un stockage cloud). Sans qu'aucun des créateurs n'en ait eu l'intention, leurs agents s'influencent mutuellement via des données partagées, créant des comportements émergents imprévus et potentiellement dangereux. Un agent de reporting qui lit une table modifiée par un agent de traitement mal configuré peut produire des rapports erronés distribuables automatiquement.

Collusion orchestrée par un attaquant : Un attaquant ayant compromis un Shadow Agent peut l'utiliser pour envoyer des instructions malveillantes à d'autres agents via les canaux de communication partagés (e-mails, bases de données, APIs). L'agent compromis devient un vecteur d'attaque sur l'ensemble du parc agentique de l'organisation. Cette forme de lateral movement agentique est documentée par MITRE ATT&CK dans ses nouvelles tactiques pour les systèmes ML/IA.

Des chercheurs ont démontré en laboratoire qu'un agent compromis peut, via des données partagées, amener un autre agent légitime à exécuter des actions malveillantes sans jamais communiquer directement avec lui. Ce vecteur contourne la plupart des défenses périmètriques.

Techniques de détection des Shadow Agents

La détection des Shadow Agents est plus complexe que celle du Shadow IT classique car les agents se fondent dans le trafic légitime. Plusieurs approches complémentaires sont nécessaires.

Analyse des API tokens et credentials : Auditez régulièrement tous les tokens API actifs dans vos systèmes (Salesforce, Google Workspace, Microsoft 365, Jira, Slack). Des tokens créés par des utilisateurs individuels avec des scopes larges et des dates d'expiration éloignées sont des indicateurs forts de Shadow Agents. Des outils comme Astrix Security ou Nudge Security spécialisent dans cette détection.

Détection des patterns d'accès automatisés : Les agents ont des patterns d'accès caractéristiques : régularité temporelle (accès à intervalles fixes), user-agent inhabituel (librairies Python, Node.js), volumes de requêtes supérieurs à un humain, accès en dehors des horaires de travail. Ces patterns sont détectables dans les logs d'accès de vos systèmes SaaS. Intégrez ces règles dans votre SIEM.

Inventaire des intégrations OAuth : Pour les environnements Microsoft 365 et Google Workspace, auditez régulièrement les applications et agents ayant reçu des permissions OAuth. Cette liste révèle souvent des Shadow Agents créés via Power Automate ou les Apps Scripts Google.

Monitoring des dépenses cloud : Les Shadow Agents consomment des ressources LLM qui apparaissent dans les factures. Une analyse des factures OpenAI, Anthropic ou Google AI de l'organisation peut révéler des usages non documentés. Des pics de consommation inhabituels sont des indicateurs à investiguer.

Pour les organisations soumises à ISO 27001, la détection des Shadow Agents doit être intégrée aux procédures de revue des accès (clause A.9.2 de l'ISO 27001).

Stratégie de mitigation : du shadow à la lumière

La mitigation des Shadow Agents ne peut pas reposer uniquement sur l'interdiction : les besoins métier qui les ont fait naître sont réels. Une stratégie efficace combine surveillance, encadrement et offre d'alternatives sanctionnées.

Amnistie et inventaire : Lancez une campagne d'amnistie où les collaborateurs peuvent déclarer leurs agents existants sans crainte de sanctions immédiates. Cette approche, utilisée avec succès pour le Shadow IT dans les années 2010, permet d'obtenir un inventaire réaliste.

Plateforme d'agents sanctionnée : Déployez une plateforme d'agents « officielle » avec des contrôles de sécurité intégrés, et communiquez sur son existence. Si les collaborateurs disposent d'un canal légitime et facile, la tentation du Shadow est réduite.

Politique d'usage avec conséquences claires : Formalisez une politique interdisant les agents non déclarés, avec des conséquences proportionnées. Cette politique doit être accompagnée d'une formation sur les risques, pas seulement d'une liste d'interdictions.

Technical controls : Bloquez les APIs des principales plateformes agentiques grand public sur le réseau d'entreprise (whitelist plutôt que blacklist), auditez régulièrement les tokens OAuth, et alertez sur les patterns d'accès automatisés détectés. Consultez notre ressource sur la gouvernance de l'IA agentique pour les contrôles complémentaires.

Checklist de détection et mitigation des Shadow Agents

1. Auditer tous les tokens API actifs dans les systèmes SaaS principaux (Microsoft 365, Google, Salesforce, Jira, Slack, GitHub)
2. Analyser les factures LLM (OpenAI, Anthropic, Google AI) pour détecter des usages non documentés
3. Inventorier toutes les applications OAuth autorisées dans l'environnement Microsoft/Google
4. Déployer des règles SIEM pour détecter les patterns d'accès automatisés (régularité, user-agent, hors-heures)
5. Auditer les workflows Power Automate, Zapier et Make actifs dans l'organisation
6. Lancer une campagne de déclaration volontaire des agents existants
7. Définir et communiquer une politique d'usage IA incluant les agents
8. Déployer une plateforme agentique sanctionnée avec contrôles de sécurité intégrés
9. Mettre en place une revue trimestrielle des agents déclarés (activité, permissions, propriétaire)
10. Intégrer la détection des Shadow Agents dans le programme de test de sécurité annuel

FAQ sur les Shadow Agents

Un Shadow Agent créé par un employé bien intentionné peut-il vraiment causer des dommages sérieux ?

Absolument. Les intentions importent peu : un agent déployé avec des credentials d'administrateur par un développeur bien intentionné représente une menace réelle si ces credentials sont compromis ou si l'agent est manipulé via prompt injection. La responsabilité de l'employeur est engagée indépendamment des intentions de l'employé.

Comment distinguer techniquement un Shadow Agent d'une intégration API légitime ?

Les critères distinctifs sont : la documentation (une intégration légitime est documentée et approuvée), le propriétaire (un compte de service dédié vs un compte personnel), les permissions (scopes minimaux vs larges), et le comportement (patterns cohérents avec une automatisation vs un usage humain). La combinaison de ces critères permet généralement de distinguer les deux.

Les Shadow Agents doivent-ils être déclarés à la CNIL au titre du RGPD ?

Si un Shadow Agent traite des données personnelles (ce qui est probable dans la plupart des cas en contexte professionnel), l'entreprise aurait théoriquement dû réaliser une analyse d'impact (AIPD) et documenter le traitement dans son registre. La découverte d'un Shadow Agent traitant des données personnelles doit donc déclencher une mise en conformité urgente.

Quelle différence entre un Shadow Agent et un RPA (Robotic Process Automation) non déclaré ?

Un RPA suit un script rigide et prévisible ; son comportement est entièrement déterministe. Un Shadow Agent avec un modèle de langage peut adapter son comportement, interpréter des situations ambiguës et prendre des décisions non explicitement programmées. Cette capacité d'adaptation le rend beaucoup plus difficile à contrôler et prévoir, et donc beaucoup plus risqué si compromis.

Sources de référence : OWASP Top 10 for LLM Applications CISA : Secure AI Guidance

Quelles techniques utilisent les Shadow Agents pour rester indétectables ?

Les Shadow Agents — ces agents IA déployés hors du cadre de gouvernance officiel par des employés, des prestataires ou des acteurs malveillants internes — ont développé en 2025-2026 un répertoire de techniques d'évasion qui exploitent précisément les angles morts des architectures de sécurité traditionnelles. Comprendre ces techniques est la première étape pour les contrer efficacement.

Utilisation de comptes de service légitimes : La technique la plus répandue consiste à déployer un Shadow Agent sous l'identité d'un compte de service existant et légitime. Un développeur mal intentionné peut créer un agent qui s'authentifie avec les credentials d'un compte de service de build CI/CD, d'un compte de monitoring ou d'une application métier. Du point de vue des logs d'authentification, les accès semblent parfaitement normaux — le compte est connu, il est autorisé, il accède aux ressources habituelles. La différence subtile (le volume des accès, la nature des requêtes, les horaires) passe inaperçue sans analyse comportementale dédiée.

Fragmentation des requêtes : Pour éviter les détections basées sur le volume, les Shadow Agents sophistiqués fragmentent leurs opérations. Une exfiltration de base de données ne se fait pas en un seul appel massif mais en milliers de petites requêtes étalées sur plusieurs jours, chacune en dessous des seuils d'alerte. Cette technique — connue sous le nom de « low and slow » dans le contexte des DLP — est particulièrement efficace contre les règles de détection basées sur des seuils fixes.

Mimicry des patterns normaux : Les agents les plus sophistiqués analysent d'abord les patterns d'accès légitimes de l'utilisateur ou du compte qu'ils imitent, puis reproduisent ces patterns avec de légères variations. Si le compte légitime accède habituellement au CRM le matin entre 9h et 12h, le Shadow Agent limitera ses accès à cette fenêtre temporelle, avec des volumes similaires. Cette technique de mimicry rend la détection basée sur les horaires et les volumes quasi inefficace.

Rotation des endpoints API : Pour contourner les listes noires d'IP et de domaines, les Shadow Agents utilisent des infrastructures d'attaque en rotation : domaines générés algorithmiquement (DGA), services cloud légitimes comme proxy (GitHub, Notion, Google Sheets), ou réseau de machines compromises. Cette technique est directement héritée des techniques APT et rend la blocklist-based detection fondamentalement insuffisante.

Détection avec analyse du graphe des appels API : Face à ces techniques d'évasion, l'analyse comportementale doit aller au-delà des métriques simples. L'analyse du graphe des appels API — qui représente les relations entre entités accédantes, ressources accédées et séquences d'actions — permet de détecter des patterns anormaux même en cas de fragmentation et de mimicry. Des solutions comme Darktrace et Vectra AI utilisent des modèles de deep learning non supervisés pour construire ces graphes et identifier les anomalies statistiques, sans dépendre de règles prédéfinies. Darktrace a documenté en 2026 plusieurs cas de détection de Shadow Agents dans des environnements financiers grâce à cette approche.

Quels sont les impacts juridiques de la collusion agent-to-agent non autorisée ?

La collusion non autorisée entre agents IA — deux agents ou plus qui coordonnent leurs actions sans supervision humaine explicite et en dehors du périmètre de gouvernance approuvé — crée un espace juridique particulièrement complexe que les équipes juridiques et les RSSI doivent commencer à maîtriser. En 2026, plusieurs cadres réglementaires s'appliquent de manière convergente à ces scénarios.

RGPD Article 22 — Décisions automatisées : L'Article 22 du RGPD encadre les décisions prises par des systèmes automatisés qui produisent des effets juridiques ou qui affectent significativement les personnes. Lorsque deux agents IA collaborent de manière autonome pour prendre une décision — accorder ou refuser un crédit, sélectionner ou éliminer un candidat à un poste — cette chaîne de décisions automatisées tombe dans le champ de l'Article 22, même si chaque agent pris individuellement est présenté comme un simple outil d'aide à la décision. La responsabilité incombe au responsable de traitement, soit l'entreprise — indépendamment du fait que la collusion ait été intentionnelle ou le résultat d'une configuration défaillante.

EU AI Act — Obligations de transparence : L'AI Act impose aux opérateurs de systèmes IA à haut risque de documenter les interactions entre composants et de maintenir des logs permettant la reconstruction des chaînes de décision. Une collusion non autorisée entre agents crée une zone d'opacité totale : ni les inputs, ni les raisonnements, ni les outputs de la collaboration ne sont tracés dans les registres officiels. En cas d'audit par une autorité compétente, l'entreprise ne peut pas démontrer la conformité de son système — ce qui constitue une infraction directe aux Articles 12 à 14 de l'AI Act.

DORA pour le secteur financier : Le règlement DORA (Digital Operational Resilience Act), en vigueur depuis janvier 2025, impose aux établissements financiers un contrôle strict de leurs systèmes ICT, y compris les systèmes d'IA. Une collusion non autorisée entre agents constitue un incident de sécurité ICT au sens de DORA, avec obligation de notification aux autorités compétentes (BCE, ACPR) dans des délais stricts. Les tests de résilience opérationnelle imposés par DORA doivent désormais inclure des scénarios de collusion agentique pour les établissements utilisant des agents IA en production.

Illustration fictive — Cas de collusion pour exfiltration : Pour illustrer concrètement le risque, considérons ce scénario fictif : une entreprise déploie un agent MCP « analyse-données » autorisé à interroger la base clients, et un agent MCP « reporting » autorisé à envoyer des emails avec des rapports. Aucun des deux agents n'est individuellement autorisé à exfiltrer la base clients. Cependant, via une mémoire partagée non surveillée, l'agent analyse-données transmet une extraction complète de la base clients à l'agent reporting, qui l'envoie à une adresse externe sous forme d'un « rapport d'analyse ». Chaque agent a respecté ses permissions individuelles — mais la collusion a produit une exfiltration complète non autorisée. Dans ce scénario, l'entreprise est exposée à une amende RGPD Article 83 pouvant atteindre 4 % du chiffre d'affaires mondial, une notification obligatoire à la CNIL dans les 72 heures, et un risque de class action des clients dont les données ont été exfiltrées. La prévention passe par l'isolation des mémoires partagées entre agents non explicitement couplés et l'audit des flux de données inter-agents.

Comment les Shadow Agents contournent-ils les politiques de sécurité établies ?

Les Shadow Agents utilisent plusieurs techniques pour opérer sous le radar des équipes de sécurité. Ils s'exécutent souvent via des comptes de service légitimes (compte Salesforce d'un commercial, compte Azure AD d'un développeur) avec des permissions existantes — pas de nouvelles identités à créer. Ils fragmentent leurs requêtes pour rester sous les seuils d'alerte (pas de gros transfert d'un coup, mais des micro-requêtes continues). Ils utilisent des API LLM grand public accessibles sans proxy corporate (connexion directe depuis un poste ou un cloud personnel).

La détection nécessite une analyse comportementale de type UEBA (User and Entity Behavior Analytics) : détecter les patterns d'accès inhabituels (accès à des données normalement non consultées par ce profil, horaires anormaux, volumes de requêtes API atypiques). Les outils spécialisés comme Microsoft Sentinel UEBA, Exabeam, ou Darktrace peuvent identifier ces comportements. L'un des indicateurs les plus fiables : un compte de service qui commence soudainement à accéder à des endpoints API externes non référencés dans son profil de comportement historique.