Le Shadow IT est un défi de sécurité persistant depuis plus d’une décennie. Les employés utilisent des outils non autorisés, l’IT les découvre des mois plus tard, et la sécurité s’active pour évaluer l’exposition. Le schéma est familier. Ce qui est nouveau, c’est la nature du risque.
Les agents Shadow AI ne sont pas de simples applications SaaS non autorisées. Ce sont des systèmes autonomes opérant sous les identifiants des employés, avec accès aux données d’entreprise, capables d’actions irréversibles, et ils prolifèrent à un rythme qui rend le Shadow IT traditionnel gérable en comparaison.
À quoi ressemblent les agents Shadow AI aujourd’hui
Les agents Shadow AI les plus courants dans les environnements d’entreprise en 2026 ne sont pas des outils de recherche exotiques. Ce sont des produits grand public ayant ajouté des capacités autonomes.
Cursor et Windsurf, des IDE propulsés par IA, font plus que compléter automatiquement du code. Ils peuvent lire des bases de code entières, générer et exécuter du code, créer des fichiers, modifier la configuration et interagir avec les systèmes de contrôle de version. Lorsqu’un développeur utilise le « mode agent » de Cursor, il déploie un système autonome avec accès en lecture/écriture à son environnement de développement, authentifié en son nom.
GPT Actions (dans ChatGPT Enterprise et intégrations tierces) permettent aux utilisateurs de créer des agents IA appelant des API externes. Les employés construisent des agents GPT qui accèdent aux systèmes CRM, extraient des bases de données internes via des connecteurs personnalisés, et renvoient les résultats, tout cela configuré dans une interface utilisateur grand public sans intervention IT.
AutoGPT, CrewAI et frameworks agents similaires sont déployés par des employés techniquement avancés souhaitant automatiser des workflows. Ils tournent sur des ordinateurs portables d’employés ou des comptes cloud personnels, authentifiés avec des clés API d’entreprise extraites de leur environnement de travail.
Microsoft Copilot Studio permet aux utilisateurs non techniques de créer des agents IA avec des connecteurs vers les données M365. Un responsable RH peut construire un agent qui lit les données des employés depuis SharePoint, les synthétise et envoie des résumés à des systèmes externes, sans approbation IT ni revue de sécurité.
Pourquoi c’est différent du Shadow SaaS
Les outils Shadow SaaS lisent généralement les données de manière passive. Un outil de gestion de projet utilisé sans approbation IT détient des copies de données de projet dans un emplacement non autorisé, un problème de résidence des données, potentiellement un problème de conformité, mais généralement pas un problème d’action.
Les agents Shadow AI prennent des actions. Ils suppriment des enregistrements, envoient des emails, créent des invitations de calendrier, poussent du code vers des dépôts, modifient des entrées de base de données et appellent des API externes. Le rayon d’impact d’un agent Shadow AI mal configuré ou compromis est des ordres de grandeur plus grand que celui d’un outil Shadow SaaS.
Ils opèrent aussi aux limites du comportement utilisateur normal. Un employé faisant manuellement des actions inhabituelles sur les données déclenche l’analyse comportementale. Un agent opérant sous les identifiants d’un employé à vitesse machine est plus difficile à distinguer d’une activité normale, du moins jusqu’à ce que le dommage soit fait.
Le problème d’exposition des identifiants
Les agents Shadow AI ont besoin d’identifiants pour fonctionner. Les utilisateurs acquièrent ces identifiants en suivant généralement le chemin de moindre résistance : ils utilisent leurs propres identifiants (ce qui signifie que toutes les actions de l’agent sont attribuées à l’utilisateur humain), créent des clés API depuis des portails développeurs (souvent avec des permissions plus larges que nécessaire), ou extraient des identifiants depuis des variables d’environnement ou fichiers de configuration dans leur environnement de développement.
Cela crée un problème de prolifération d’identifiants presque invisible pour les solutions PAM traditionnelles. Ces identifiants ne sont pas des comptes de service créés via des processus IT, ce sont des tokens créés par les utilisateurs qui résident dans des fichiers de configuration d’agents sur les appareils des employés, dans des dépôts GitHub personnels ou dans les paramètres de plateformes IA grand public.
Lorsqu’un de ces agents est compromis, via un paquet malveillant dans son écosystème d’outils, une attaque par injection de prompt ou une simple mauvaise configuration, l’attaquant hérite des accès de son créateur.
Stratégies de découverte : comment trouver ce que vous ne savez pas qu’il existe
Découvrir les agents Shadow AI nécessite une approche multi-couches, car aucune source de données unique ne les capture tous.
Analyse du trafic réseau
Les frameworks agents IA génèrent des motifs réseau distinctifs : appels à haute fréquence vers des points d’API LLM (api.openai.com, api.anthropic.com, etc.), invocations d’outils vers des serveurs MCP, et flux OAuth vers des services internes ou externes. La visibilité au niveau réseau capturant les domaines de destination et les volumes d’appels fera remonter la plupart des frameworks agents déployés.
Audit des tokens OAuth et clés API
Interrogez votre fournisseur d’identité pour les tokens OAuth émis à des applications non listées dans votre catalogue logiciel approuvé. Passez en revue les clés API émises via les portails développeurs pour détecter des motifs d’accès incohérents avec l’usage attendu. Les frameworks agents demandent fréquemment des étendues OAuth larges (« lire tous les emails », « lire tous les calendriers ») qui se distinguent des étendues demandées par les applications approuvées.
Enquêtes auprès des employés et divulgation structurée
Le chemin le plus rapide pour découvrir est de demander. Un processus structuré de divulgation des outils IA, présenté comme « aidez-nous à comprendre ce que vous utilisez pour mieux vous soutenir, pas pour vous pénaliser », fait rapidement remonter la majorité des usages Shadow AI. La plupart des employés utilisant des agents Shadow AI ne cherchent pas à contourner la sécurité ; ils cherchent à être productifs.
Intelligence d’usage SaaS
Les outils de gestion SaaS et CASB qui surveillent l’usage des applications cloud montreront les enregistrements de plateformes IA, les installations d’extensions de navigateur et le trafic web vers les domaines d’outils IA. Recoupez ces données avec votre liste d’outils approuvés pour identifier les écarts.
Que faire quand vous les trouvez
La réponse aux agents Shadow AI doit être graduée, pas uniformément punitive. Une interdiction totale pousse l’usage dans l’ombre sans réduire le risque. Un chemin structuré du Shadow vers le sanctionné est plus efficace.
Pour les agents sans accès aux données sensibles : reconnaissez, documentez et fournissez des conseils. Ils posent un risque limité et leur sanction rapide supprime la désignation Shadow IT.
Pour les agents ayant accès à des données sensibles ou des capacités d’action : exigez une divulgation immédiate, une revue de sécurité, puis soit une approbation formelle, soit une transition vers une alternative approuvée. La revue de sécurité doit couvrir les permissions des outils, l’accès aux données, la gestion des identifiants et la journalisation.
Pour les agents disposant de credentials non gérés sur les systèmes de production : considérer cela comme un incident de sécurité. Faites tourner les credentials, examinez les journaux d'accès pour détecter toute activité anormale et exigez une intégration formelle avant de réactiver.
La fenêtre pour anticiper les agents IA fantômes est étroite. Les organisations qui mettent en place dès maintenant des programmes de découverte et de gouvernance auront beaucoup plus de facilité à gérer ce risque que celles qui attendent le premier incident pour agir.
