La gouvernance des identités non humaines s’impose comme le nouveau front de l’IAM : comptes techniques, workloads, clés d’API, bots et agents automatisés dépassent désormais largement les utilisateurs humains dans de nombreux systèmes d’information.

Une explosion d’identités difficiles à recenser

Les identités non humaines (NHI) regroupent comptes de service, secrets applicatifs, certificats, clés d’API, bots RPA, agents d’IA, objets connectés et workloads cloud, tous associés à des droits d’accès bien réels. Avec la généralisation des architectures cloud natives, des micro-services et surtout l’arrivée des agents IA autonomes, qui peuvent eux-mêmes engendrer de nouvelles NHI, elles excèdent désormais largement les identités humaines : sur les environnements cloud natifs, le ratio mesuré atteint 144 pour 1, contre 92 pour 1 un an plus tôt. Peu visibles des équipes applicatives, IAM et sécurité, elles forment une « masse sombre » où droits surdimensionnés et persistants ouvrent un terrain idéal aux attaquants.

Des risques systémiques sous-estimés

Les identités machines disposent fréquemment de privilèges élevés par praticité, à l’opposé du moindre privilège (« avec tous les droits, je suis sûr que cela fonctionne »), sans revue régulière ni propriétaire identifié. Comptes techniques laissés actifs après une migration, tokens d’API à durée de vie excessive, mots de passe de service codés en dur : autant de portes d’entrée discrètes mais critiques. Le paradoxe est net au regard du Zero Trust, les contrôles se resserrant sur les humains pendant que les machines conservent une confiance implicite.

Un token OAuth compromis, une clé API exposée dans un dépôt Git ou un service principal surprivilégié permettent de contourner les mécanismes appliqués aux utilisateurs : leur exploitation est devenue une étape centrale des compromissions cloud récentes. S’y ajoute une échéance peu anticipée : la durée de vie maximale des certificats TLS, ramenée à 200 jours depuis mars 2026, tombera à 100 jours en mars 2027, rendant toute gestion manuelle intenable.

Les agents IA déplacent la nature du problème

L’arrivée des agents autonomes ajoute une catégorie d’identités et remet en cause, dans le même mouvement, les cadres construits pour les gouverner. La supervision comportementale suppose un comportement attendu stable, qu’un agent non déterministe ne présente pas ; l’inventaire par découverte périodique suppose un parc plus lent que le cycle de scan, alors qu’un agent peut instancier ses propres identifiants à l’exécution. Surtout, dans la majorité des déploiements observés, l’agent n’agit pas sous une identité propre mais par délégation de celle d’un collaborateur : la frontière entre identités humaines et non humaines, sur laquelle repose l’essentiel des dispositifs IAM actuels, s’estompe. L’écart entre usage et maîtrise est documenté : en 2026, plus de neuf organisations sur dix utilisent des agents IA, une sur dix seulement dispose d’une stratégie aboutie pour les gérer.

Les nouvelles approches ne considèrent plus les NHI comme de simples variantes des comptes utilisateurs. Elles combinent découverte continue, attribution d’un propriétaire, gestion du cycle de vie, moindre privilège, hygiène des secrets, traçabilité probante et capacité d’interruption. Les deux derniers leviers sont les moins outillés, et ceux qui résistent le moins bien aux agents.

La traçabilité, condition de l’imputabilité

Quand un agent déclenche un virement, modifie un droit d’accès ou publie un correctif en production, le journal applicatif montre une action autorisée par un jeton valide, sans indiquer qui l’a voulue, sous quelle autorité, ni qui en répond. Trois niveaux doivent être consignés : l’identité technique (credential), l’identité d’exécution, l’agent ou le workload qui agit, et l’identité d’origine, la personne ou le processus qui a mandaté l’action. Un journal qui ne consigne que la première n’a aucune valeur d’imputabilité. Consigner ne suffit d’ailleurs pas : un log modifiable et non scellé ne constitue pas une preuve. Horodatage qualifié, chaînage cryptographique, écriture unique et exploitabilité réelle au moment de l’incident forment le socle minimal, que le règlement européen sur l’IA, NIS2 et DORA imposent chacun dans leur périmètre, sans distinguer l’auteur humain de l’auteur machine.

L’arrêt d’urgence (kill switch), à concevoir avant l’incident

Désactiver un compte utilisateur fait tomber les sessions. Révoquer le credential d’un agent n’arrête rien de ce qui est déjà engagé : les jetons porteurs émis restent valides jusqu’à expiration si les ressources consommatrices ne vérifient pas leur révocation à chaque appel, et les sous-processus auxquels l’agent a délégué ses droits continuent d’agir après sa désactivation. La capacité d’arrêt dépend donc de la durée de vie des jetons et de la connaissance de la chaîne de délégation. Un mécanisme exploitable est gradué, de la suspension des nouveaux appels au gel des écritures puis à la révocation complète, chaque niveau associé à un impact métier documenté. Il doit être déclenchable par la supervision sans validation hiérarchique, et testé périodiquement : un dispositif jamais exercé n’est pas un dispositif disponible.

Un enjeu stratégique

La montée en puissance de l’IA, de la RPA et du multi-cloud ne fera qu’accélérer cette prolifération. Les organisations qui tardent à intégrer ces identités dans leur gouvernance IAM bâtissent leur cybersécurité sur un socle truffé de comptes critiques échappant au radar.

L’enjeu n’est plus simplement de gérer des identités, ni même de sécuriser l’ensemble des entités capables d’agir au sein du système d’information, qu’elles soient humaines ou artificielles. Il est de pouvoir interrompre au plus tôt un comportement déviant et d’établir, à tout moment et de manière opposable, qui a fait quoi, sous quelle autorité, et qui en répond.

Par Souleymane Kabbaj chez Squad, Practice Leader Identité & Zéro Trust