Fin janvier 2026, le réseau social Moltbook, conçu pour permettre à des agents IA de publier et d’interagir de façon autonome, revendiquait entre 1,4 et 1,5 million de comptes actifs, avant de révéler une base de données mal configurée exposant adresses e-mail, tokens de connexion et clés API de l’ensemble des agents inscrits. L’incident, lié à l’assistant autonome OpenClaw, illustre un problème que la plupart des entreprises n’ont pas encore mesuré : leurs agents IA, connecteurs et intégrations s’appuient sur des identités (clés API, comptes de service, tokens OAuth) gérées avec beaucoup moins de rigueur que les comptes humains à privilèges.
Un problème d’échelle, pas seulement de rigueur
Selon une analyse du Forum économique mondial, Les identités non humaines (NHI), telles que les comptes de service, les clés API et les jetons d’authentification, se multiplient rapidement dans les environnements d’entreprise, créant de nouveaux défis de visibilité, de gouvernance et de cybersécurité pour les organisations.
Le rapport Semperis 2026, conduit auprès de professionnels IT et sécurité dans huit pays dont la France, quantifie l’ampleur du mouvement : près de 29 % des organisations utilisent déjà des agents autonomes pour des tâches à privilèges comme la réinitialisation de mots de passe ou l’octroi d’accès VPN, et 65% comptent franchir ce pas d’ici l’année prochaine. Ce chiffre dépasse largement la part des organisations qui se déclarent prêtes à gérer les conséquences d’un incident lié à ces mêmes agents.
Pourquoi l’IAM traditionnel ne suffit pas
L’IAM (Identity Access Management) classique a été conçu pour des humains et des applications statiques, avec des cycles de revue d’accès mensuels ou trimestriels. Un agent IA change de tâche dynamiquement, peut invoquer plusieurs outils en une seule session, et agit parfois à vitesse machine sans intervention humaine entre la requête et l’exécution. Ce décalage de rythme explique la faille la plus documentée : de nombreux agents utilisent encore des identifiants humains partagés, des clés API génériques ou des comptes de service mutualisés, faute de modèle d’identité pensé spécifiquement pour eux.
Selon une étude Delinea, 80 % des entreprises déclarent ne pas toujours être en mesure de comprendre pourquoi une identité non humaine a exécuté une action à privilèges, un déficit de traçabilité qui devient une exposition réglementaire directe dès lors qu’un incident implique des données personnelles ou des systèmes critiques. La même étude relève que 90 % des organisations subissent une pression interne pour assouplir leurs contrôles d’identité afin d’accélérer les projets IA, aux dépens de la gouvernance.
Les principes d’une gestion adaptée aux identités IA
- Une identité propre par agent : jamais d’identifiants humains partagés ni de compte de service générique mutualisé entre plusieurs agents, pour permettre l’attribution précise de chaque action.
- Scope minimal et permissions explicites : chaque clé API ou token n’accède qu’aux ressources nécessaires à la tâche de l’agent, jamais à un périmètre large « au cas où ».
- Rotation automatique : des clés à durée de vie limitée plutôt que des identifiants statiques valables indéfiniment, via des coffres-forts à secrets (Vault, AWS Secrets Manager…) plutôt que des clés en dur dans le code ou les fichiers de configuration.
- Révocation immédiate et centralisée : un inventaire à jour de tous les agents et connecteurs actifs permet de couper l’accès en quelques minutes en cas de compromission ou de départ d’un collaborateur responsable d’un agent.
- Traçabilité de la délégation : pour chaque action d’un agent, pouvoir répondre à la question « au nom de qui agit-il, et qui en répond ? », ce qui suppose une journalisation systématique liée à l’identité de l’agent, pas seulement à celle de l’utilisateur initial.
Les erreurs les plus fréquentes
Les incidents Moltbook et OpenClaw, documentés en détail début 2026, combinent deux catégories de défaillances qu’il est utile de distinguer. D’un côté, des erreurs classiques de développement (clés API codées en dur dans un dépôt Git public, proxy mal configuré, base de données exposée sans authentification) qui n’ont rien de spécifique à l’IA et relèvent de l’hygiène de sécurité applicative de base. De l’autre, des risques réellement nouveaux liés à l’autonomie : délégation d’accès mal cadrée, agents capables d’agir sur plusieurs systèmes simultanément si une seule clé est compromise, et exposition à l’injection de prompt qui peut détourner un agent légitime de son objectif initial. Le référentiel OWASP dédié aux applications agentiques classe d’ailleurs l’abus d’identité et de privilèges parmi ses risques les plus critiques pour 2026, aux côtés du détournement d’objectif et de l’utilisation abusive des outils.
Une exposition déjà exploitée
Le rapport SpyCloud 2026 sur l’exposition des identités documente une dimension criminelle concrète : 18,1 millions de clés API et tokens exposés, auxquels s’ajoutent 6,2 millions d’identifiants et cookies d’authentification spécifiques à des outils IA, observés en circulation sur des sources issues des réseaux cybercriminels. Lorsque des identifiants d’agent sont compromis, l’impact dépasse largement celui d’un compte humain classique : un agent dispose souvent d’un accès transversal à plusieurs systèmes qu’aucun utilisateur individuel ne recevrait normalement, ce qui démultiplie le rayon d’exposition d’une seule fuite.
→ Voir notre article dédié au DLP et à l’IA pour la protection des données en amont, et notre article sur la gouvernance de l’IA en entreprise pour l’articulation complète avec les autres contrôles.
Questions fréquentes
Un agent IA doit-il avoir son propre compte, distinct de celui du collaborateur qui l’a configuré ?
Oui, systématiquement. Un agent utilisant les identifiants humains de son créateur rend impossible toute attribution précise des actions et toute révocation ciblée sans couper aussi l’accès du collaborateur.
Faut-il un outil spécifique pour gérer les identités des agents IA ?
Pas nécessairement un outil entièrement nouveau : les coffres-forts à secrets et solutions de gestion des accès à privilèges existants peuvent être étendus, à condition d’adapter les politiques de rotation et de scope au rythme d’usage réel des agents, plus rapide que celui des comptes humains.
Comment prioriser si toutes les identités machine ne peuvent pas être auditées d’un coup ?
Commencer par les agents ayant accès à des systèmes de production ou à des données sensibles, et par ceux disposant de privilèges les plus larges, le niveau d’accès prime sur le volume d’usage pour établir la priorité d’audit.
Sécuriser les identités de vos agents et connecteurs IA
Pour évaluer vos risques ou structurer une gouvernance adaptée à vos projets IA : contactez-nous