Les entreprises ne doivent plus seulement rechercher les chatbots utilisés sans autorisation : elles doivent aussi découvrir les agents IA capables d’accéder à des données et d’exécuter des actions. Ces « shadow agents » peuvent être créés dans des plateformes SaaS, des outils d’automatisation, des environnements de développement ou du code interne, sans passer par la sécurité.
Pourquoi les agents IA créent un nouvel angle mort
Un outil SaaS classique attend généralement qu’un utilisateur se connecte. Un agent IA peut, lui, fonctionner en continu, appeler des API, lire des courriels, modifier des fichiers, lancer des workflows et conserver des identifiants. Son niveau d’autonomie transforme une adoption non encadrée en risque opérationnel.
Des collaborateurs peuvent construire ces agents dans Microsoft Copilot Studio, Salesforce Agentforce, ServiceNow, n8n, Workato, Zapier ou des plateformes cloud. Les développeurs peuvent également les exécuter depuis un IDE, un terminal, un conteneur ou une fonction sans serveur. La visibilité dépend donc de l’endroit où l’agent vit et de la manière dont il s’authentifie.
Qu’est-ce que la découverte des agents IA ?
La découverte consiste à identifier et cataloguer les agents présents dans l’organisation, qu’ils aient été approuvés ou non. Un inventaire utile ne se limite pas à un nom : il doit relier chaque agent à son propriétaire, ses identités techniques, ses outils, ses permissions, ses données et son environnement d’exécution.
- Quels agents sont actifs ou simplement configurés ?
- Qui les a créés et qui reste responsable de leur fonctionnement ?
- À quelles applications, bases de données et boîtes de messagerie ont-ils accès ?
- Utilisent-ils des clés API, comptes de service ou autorisations OAuth excessives ?
- Certains agents continuent-ils de fonctionner après le départ de leur créateur ?
Six méthodes de détection et leurs limites
| Méthode | Ce qu’elle voit bien | Angle mort principal |
| Analyse réseau | Connexions vers des services IA | Ne distingue pas toujours humain et agent |
| Extension de navigateur | Outils web et plateformes sans API | Ignore serveurs, mobiles et postes non gérés |
| Agent endpoint | IDE, CLI et logiciels locaux | Ne voit pas les agents SaaS ou cloud |
| Analyse du code et CI/CD | Frameworks, SDK et logique d’agent | Décrit l’intention, pas le comportement réel |
| Inventaire cloud et SaaS | Agents déclarés et configurations | Dépend des API exposées par chaque plateforme |
| Analyse des identités | OAuth, clés API et comptes de service | Une identité ne révèle pas toujours l’agent qui l’utilise |
Le réseau offre un signal, pas un inventaire complet
Les solutions réseau, SASE ou SSE peuvent détecter des communications vers des fournisseurs de modèles. Elles sont utiles pour repérer un service inconnu ou un volume anormal. Toutefois, le trafic chiffré révèle rarement le propriétaire, les permissions ou la finalité exacte. Un appel vers une API peut provenir d’un développeur, d’une application ou d’un agent autonome.
Navigateur et endpoint couvrent deux mondes différents
Une extension de navigateur détecte les employés qui créent ou utilisent des agents dans des interfaces web. Elle peut être précieuse lorsque la plateforme ne propose aucune API d’administration. En revanche, elle ne voit pas les traitements autonomes exécutés sur un serveur.
La télémétrie endpoint complète cette visibilité en détectant les outils de bureau, extensions d’IDE, frameworks locaux et modèles exécutés sur les postes gérés. Elle demeure aveugle aux appareils personnels, aux environnements cloud et aux agents intégrés directement dans des applications SaaS.
Code, cloud et identités techniques
L’analyse des dépôts et pipelines peut trouver les références à LangGraph, CrewAI, AutoGen ou aux SDK de fournisseurs de modèles. Elle aide à constituer une nomenclature IA et à repérer des secrets codés en dur. Mais le code ne prouve pas qu’un agent est déployé, ni que ses droits en production correspondent à la conception.
Les API des plateformes cloud et SaaS offrent souvent les métadonnées les plus riches sur les agents enregistrés : créateur, statut, outils et connexions. L’analyse des autorisations OAuth, clés API, comptes de service et connexions MCP permet ensuite de repérer les identités non humaines qui rendent leurs actions possibles.
Construire une stratégie de découverte par couches
Aucune méthode ne fournit une couverture totale. Une organisation doit combiner plusieurs points de vue en fonction de son architecture. Une entreprise très dépendante de Microsoft 365 ou Salesforce commencera par les API et configurations SaaS. Une équipe de développement ajoutera l’analyse de code, des endpoints et du cloud. Un environnement distribué renforcera la télémétrie réseau et l’identité.
- Définir ce qui est considéré comme un agent et distinguer l’automatisation classique.
- Prioriser les agents ayant accès aux données sensibles ou capables d’actions irréversibles.
- Associer chaque agent à un propriétaire humain et à une date de révision.
- Inventorier les permissions, secrets, outils connectés et flux de données.
- Appliquer le moindre privilège et prévoir la rotation des identifiants.
- Révoquer les agents orphelins et intégrer leur contrôle au processus de départ des employés.
- Surveiller les changements de configuration et les comportements d’exécution.
Découvrir avant de gouverner
Une politique IA ne protège que les systèmes connus. Sans inventaire continu, les équipes de sécurité ne peuvent ni évaluer l’exposition aux injections de prompt, ni contrôler les transferts de données, ni vérifier les autorisations. La découverte doit donc alimenter un processus de gouvernance : approbation, classification des risques, suivi, remédiation et retrait.
L’objectif n’est pas de bloquer toute expérimentation. Il consiste à rendre les usages visibles et à concentrer les contrôles sur les agents combinant forte autonomie, données sensibles et privilèges étendus. C’est cette approche fondée sur le risque qui permet d’encadrer l’innovation sans transformer chaque initiative en angle mort.
