3 octobre 2026

Identités non humaines et agents IA : comment les gouverner

Introduction

Pendant vingt ans, la gouvernance des identités s’est construite autour d’une personne : un salarié arrive, change de poste, part. Les identités non humaines (NHI) n’entrent dans aucune de ces cases. Comptes de service, clés d’API, identités cloud et maintenant agents IA n’ont ni contrat, ni manager, ni date de départ. Et ils sont devenus majoritaires : CyberArk en comptait 45 pour un humain en 2022, puis 82 pour un humain en 2025.

Les incidents publics montrent où cela mène :

Okta, octobre 2023. Les identifiants d’un compte de service du système de support avaient été enregistrés dans le profil Google personnel d’un salarié. L’attaquant a volé des fichiers contenant des jetons de session ; 134 clients ont été touchés.
Uber, septembre 2022. Après avoir compromis le compte d’un prestataire, l’attaquant dit avoir trouvé des identifiants administrateur écrits en dur dans un script, donnant accès au coffre-fort de comptes à privilèges. Ce détail vient de l’attaquant ; Uber ne l’a pas confirmé.
Moltbook, février 2026. Une base de données mal configurée de ce réseau social pour agents IA exposait 1,5 million de jetons d’authentification d’agents, selon les chercheurs de Wiz.
Secrets publiés par erreur. GitGuardian a détecté 10 millions d’occurrences de secrets dans les commits publics de GitHub en 2022.

Cet article explique pourquoi ces identités échappent à la gouvernance classique, quelles règles appliquer, et pourquoi les agents IA obligent à poser une question nouvelle : non plus seulement « qui agit ? », mais « au nom de quelle intention ? ». Il complète le guide IGA en traitant la face non humaine de la gouvernance.

Qu’est-ce qu’une identité non humaine ?

Une identité non humaine est toute identité qui s’authentifie et obtient des accès sans être une personne. Toutes ne se gèrent pas de la même façon : leur cycle de vie, leurs responsables et leurs droits diffèrent profondément. Je les classe en trois familles.

Famille	Exemples	Comment la gérer
Historiques	Comptes intégrés (admin, root, invité), comptes de service locaux (base de données, serveur d’applications), comptes techniques entre applications, robots RPA	Industrialisable avec les outils existants : IGA, PAM, CMDB
Modernes	Identités des services cloud (rôles AWS, identités managées Azure, comptes de service GCP), clés d’API et jetons, comptes de service Kubernetes, pipelines CI/CD, certificats et clés SSH, objets connectés	Outils spécialisés : gestion des secrets, découverte cloud, identités de charge de travail à courte durée de vie
Agentiques	Comptes des modèles d’IA qui appellent des services, agents autonomes ou semi-autonomes agissant au nom d’un humain ou d’un système	Sujet encore immature ; standards en cours d’écriture

Pour les identités modernes, le standard SPIFFE, projet diplômé de la CNCF, remplace les secrets statiques par des identités cryptographiques à courte durée de vie, renouvelées automatiquement. C’est la direction à suivre : un secret qui n’existe pas ne peut pas fuiter.

Pourquoi elles échappent à la gouvernance classique

Un outil IGA sait gérer une personne parce qu’une source RH lui dit qui arrive, qui change et qui part. Rien de tel n’existe pour une NHI. Six difficultés reviennent dans presque toutes les organisations.

Le volume. Avec plusieurs dizaines de NHI par humain, une revue manuelle est impossible.
Un cycle de vie opaque. Pas de processus cohérent pour créer, faire tourner ou supprimer. Les identités orphelines s’accumulent sans bruit.
Personne n’est responsable. Les NHI se situent entre le développement, l’exploitation et la sécurité, et des utilisateurs en créent parfois sans le savoir, en connectant une application SaaS.
Aucune source de vérité. Les registres sont éclatés entre le cloud, les serveurs internes et les applications SaaS. Un inventaire unifié est un projet en soi.
Des secrets dispersés. Identifiants dans le code, les fichiers de configuration, les pipelines, les partages réseau, sans contrôle central.
Des droits excessifs. Les NHI accumulent des privilèges rarement ajustés et encore plus rarement revus. En 2022, CyberArk estimait que 68 % des NHI avaient accès à des données ou ressources sensibles.

Le point commun : la gouvernance des humains repose sur un événement déclencheur, l’arrivée ou le départ, structuré par le cycle de vie JML. Les NHI n’en ont pas. Il faut donc en créer.

Les règles de gouvernance des NHI

Six règles suffisent à reprendre la main. Elles viennent toutes de l’IGA classique, adaptées à des identités sans RH.

Un responsable humain pour chaque NHI. C’est le remplacement du manager : la personne qui répond de son usage, valide ses droits et décide de sa suppression. Une NHI sans responsable est orpheline par définition.
Un inventaire unique. Découverte régulière dans les annuaires, le cloud, les outils DevOps et le SaaS, rapprochée dans un seul référentiel avec son responsable et sa finalité.
Une date de fin dès la création. Faute de départ RH, chaque NHI reçoit une échéance, prolongée seulement sur décision de son responsable. C’est l’événement déclencheur qui manquait.
Des droits minimaux, si possible temporaires. Juste ce qu’il faut pour la tâche, et des accès à la demande plutôt que permanents quand la plateforme le permet. Voir les modèles d’autorisation RBAC, ABAC, PBAC.
Pas de secret statique quand c’est évitable. Identités managées du cloud, identités de charge de travail à courte durée de vie, coffre-fort de secrets avec rotation automatique pour le reste.
Une revue périodique par le responsable. La même logique qu’une campagne de recertification, centrée sur trois questions : cette NHI sert-elle encore, ses droits sont-ils justes, son responsable est-il toujours le bon ?

Avant d’acheter un outil, vérifiez ce que votre IGA et votre PAM couvrent déjà. Beaucoup d’organisations découvrent que les identités historiques peuvent y entrer, et que le vrai manque se situe sur les identités cloud et DevOps.

Agents IA : gouverner l’autorité déléguée, pas seulement l’identité

Ma conviction : savoir qui est l’agent compte moins que savoir quelle autorité porte le jeton qu’il présente. L’identité de l’agent reste utile pour l’audit, la responsabilité et l’analyse de risque. Mais quand un agent agit au nom d’un utilisateur, c’est l’autorité déléguée qui doit guider la décision d’autorisation.

Prenons Léa, cheffe de projet, qui demande à son agent : « Récupère les retours sur le projet X dans mes e-mails, le dossier du projet et les messageries, et dis-moi ce qu’il faut changer. »

Première étape, déjà accessible : croiser les droits de l’utilisateur avec les périmètres délégués. Si Léa ne peut pas faire une action elle-même, son agent ne doit pas pouvoir la faire à sa place. Les mécanismes existent : l’échange de jetons OAuth (RFC 8693) distingue la délégation, où l’agent garde sa propre identité en agissant pour Léa, de l’usurpation. Le protocole MCP s’appuie sur OAuth 2.1, mais son volet autorisation reste optionnel.

Le vrai manque : borner par l’intention. On sait limiter un jeton dans le temps, par destinataire et par périmètre. On ne sait pas encore le limiter à ce que la tâche demande. Si Léa demande un résumé de ses e-mails non lus, pourquoi le jeton permettrait-il de lire toute sa boîte, entretien annuel compris ? Les travaux de normalisation avancent, notamment à l’IETF (draft-ietf-wimse-aims), mais rien n’est stabilisé.

La question de sécurité des agents se déplace donc : moins « quel agent appelle ? » que « pourquoi cette action est-elle autorisée, maintenant ? ».

Par où commencer

Inutile de tout traiter d’un coup. Quatre étapes, dans cet ordre :

Cadrer les cas d’usage. Quels comptes de service existent, qui s’en plaint, quelles exigences : découverte, coffre-fort, rotation, audit, gouvernance.
Mesurer ce que couvre déjà votre outillage. IGA, PAM, gestionnaire de secrets : qu’est-ce qui est réellement géré aujourd’hui, et qu’est-ce qui ne l’est pas ?
Traiter d’abord les identités historiques. Elles entrent dans les outils existants : responsable, date de fin, revue. C’est le gain le plus rapide. Le provisioning peut y être adapté, à condition de documenter explicitement les sources d’autorité propres à ces identités.
Bâtir une trajectoire pour les identités cloud et agentiques. Comparer les scénarios (compléter l’existant ou ajouter une brique dédiée), avec un coût de construction et d’exploitation, sur plusieurs années.

FAQ

Qu’est-ce qu’une NHI ?

Une identité non humaine : compte de service, compte technique, clé d’API, certificat, identité cloud ou agent IA. Elle s’authentifie et obtient des accès sans être une personne.

Combien y a-t-il de NHI par rapport aux humains ?

Les estimations varient selon les études. CyberArk en comptait 45 pour un humain en 2022 et 82 pour un humain en 2025.

Un outil IGA peut-il gérer les NHI ?

En partie. Les comptes de service et comptes techniques classiques peuvent y être rattachés à un responsable et revus. Les identités cloud, DevOps et agentiques demandent souvent des outils complémentaires : gestion des secrets, découverte cloud, identités à courte durée de vie.

Un agent IA doit-il avoir sa propre identité ?

C’est utile pour l’audit et la traçabilité. Mais quand il agit pour un utilisateur, la décision d’autorisation doit d’abord reposer sur les droits de cet utilisateur et sur l’intention de sa demande.

Quels standards encadrent l’authentification des agents IA ?

Aucun n’est encore stabilisé. L’échange de jetons OAuth (RFC 8693) permet déjà la délégation, et le protocole MCP s’appuie sur OAuth 2.1. Des travaux sont en cours à l’IETF.

Sources

Pages consultées le 3 octobre 2026.