Identités non humaines (NHI : Non Human Identity) et comptes d’agents d’IA : le nouvel angle mort de vos systèmes IAM

Les organisations ont beaucoup investi dans la gestion des identités humaines : collaborateurs, prestataires, partenaires.

Mais une zone grise grandit silencieusement : les identités non humaines (NHI) et les comptes d’agents d’IA.

API, micro‑services, bots, scripts, connecteurs SaaS, agents d’IA autonomes…

Tous ces “acteurs” techniques disposent d’identifiants, de droits, parfois de privilèges élevés.

Et pourtant, ils échappent souvent aux standards de gouvernance appliqués aux utilisateurs humains.

Dans un contexte où les cybercriminels détournent déjà les LLM pour industrialiser leurs attaques, ignorer ces identités non humaines devient un risque majeur.

1. Ce que recouvrent vraiment les identités non humaines (NHI)

Sous le terme NHI (pour Non Human Identity), on trouve notamment :

- **Comptes techniques** (services Windows/Linux, comptes d’exécution de jobs, ETL, etc.)

- **Identités d’applications** (OAuth clients, app registrations, service principals…)

- **Clés API et tokens** utilisés par des services internes ou des partenaires

- **Bots et assistants virtuels** (chatbots, RPA, scripts automatisés)

- **Agents d’IA** (LLM orchestrés, agents autonomes, copilotes métiers)

Ces identités :

- Ne signent pas de charte informatique

- Ne suivent pas un cycle RH classique (onboarding / mobilité / offboarding)

- Sont souvent **créées en urgence** par des projets, puis **jamais révisées**

- Peuvent disposer de **droits très larges** “pour que ça marche”

Résultat : un terrain de jeu idéal pour un attaquant qui compromet un système, un pipeline DevOps ou un agent d’IA mal maîtrisé.

2. Pourquoi les systèmes IAM classiques ne suffisent plus

Les IAM et IGA ont été pensés d’abord pour les humains.

Appliqués tels quels aux NHI et aux agents d’IA, ils montrent vite leurs limites :

1. Manque de visibilité

- Peu d’inventaire centralisé des comptes techniques et identités d’applications

- Multiplication des secrets dans les outils CI/CD, scripts, fichiers de config

2. Modélisation inadaptée

- Rôles et profils pensés pour des métiers humains, pas pour des flux techniques

- Difficulté à exprimer le “besoin d’agir” d’un agent d’IA sur un périmètre précis

3. Gouvernance faible

- Rares campagnes de recertification sur les comptes non humains

- Absence de sponsor métier clairement identifié pour ces identités

4. Traçabilité partielle

- Journaux qui ne distinguent pas toujours clairement :

“un humain a agi via un agent d’IA” vs “l’agent d’IA a agi de lui‑même”

Dans un environnement où l’IA de défense doit analyser les comportements, **cette confusion complique la détection des signaux faibles**.

3. Les risques spécifiques liés aux comptes d’agents d’IA

Les agents d’IA ajoutent une couche de complexité :

- Ils agrègent des droits : lecture de mails, accès à des dépôts de code, consultation de référentiels sensibles, etc.

- Ils peuvent enchaîner des actions (planifier, modifier, supprimer, déclencher des workflows) à grande vitesse.

- Ils sont parfois connectés à des LLM externes, avec des flux de données sortants difficiles à maîtriser.

Trois scénarios de risque typiques :

1. Escalade silencieuse de privilèges

Un agent d’IA reçoit progressivement plus de droits “pour être utile”.

Personne ne revoit son périmètre global. En cas de compromission, l’attaquant dispose d’un “super‑opérateur” automatisé.

2. Détournement de l’agent

Via une vulnérabilité applicative, un prompt injection ou un compte technique exposé, l’attaquant prend le contrôle de l’agent et l’utilise pour :

- exfiltrer des données,

- modifier des configurations,

- désactiver des contrôles.

3. Confusion d’attribution

Les journaux montrent “l’agent X a fait Y”, mais :

- Était‑ce une action légitime ?

- Initiée par quel humain ?

- Sur la base de quelles données ou instructions ?

Sans gouvernance claire, il devient très difficile de reconstituer la chaîne de responsabilité, ce qui pose aussi un problème de conformité (NIS2, DORA, ISO 27001).

4. Les fondamentaux d’une gouvernance IAM adaptée aux NHI et aux agents d’IA

Pour reprendre le contrôle, plusieurs principes structurants peuvent être mis en place.

4.1. Inventorier et classifier les identités non humaines

- Construire un inventaire centralisé des comptes techniques, identités d’applications, clés API, tokens, agents d’IA.

Associer à chaque identité :

- un propriétaire (métier ou IT),

- un usage documenté (pour quoi ? dans quel flux ?),

- un niveau de criticité (impact en cas de compromission).

4.2. Appliquer le principe du moindre privilège… vraiment

- Limiter les droits de chaque NHI et agent d’IA au **strict nécessaire**.

- Segmenter les rôles : un agent d’IA n’a pas besoin d’être “administrateur global” pour être utile.

- Préférer des droits temporaires ou contextuels (just‑in‑time) pour les actions sensibles.

4.3. Intégrer les NHI dans les processus IGA

- Inclure les identités non humaines dans les campagnes de recertification périodiques.

- Exiger une validation explicite des droits par le sponsor métier ou technique.

- Mettre en place des revues spécifiques pour les agents d’IA les plus puissants.

4.4. Renforcer la traçabilité et l’observabilité

- Distinguer clairement dans les logs :

- actions d’un humain,

- actions d’un agent d’IA,

- actions d’un agent d’IA déclenchées par un humain identifié.

- Mettre en place des **alertes comportementales** :

- volumes anormaux,

- accès inhabituels,

- séquences d’actions atypiques.

5. Comment l’IA de défense peut aider à maîtriser ces identités

Une IA de défense, pensée pour la gouvernance, peut jouer un rôle clé :

- Cartographier automatiquement les NHI et agents d’IA à partir des journaux, des configurations IAM et des flux techniques.

- Détecter les incohérences : droits trop larges, absence de propriétaire, absence de recertification.

- Identifier les signaux faibles :

- agent d’IA qui commence à accéder à de nouveaux périmètres,

- compte technique utilisé à des horaires ou depuis des environnements inhabituels.

- Aider le COMEX et la gouvernance à prioriser :

- quels agents d’IA revoir en priorité,

- quels flux techniques sécuriser,

- quelles politiques IAM adapter.

L’enjeu n’est pas seulement technique :

c’est un sujet de gouvernance des risques numériques, au croisement de la conformité, de la résilience et de la responsabilité.

6. Questions à poser dès maintenant à vos équipes

Pour ouvrir le dialogue avec vos équipes cyber, IAM et métiers, quelques questions simples mais structurantes :

1. Avons‑nous une vue consolidée de nos identités non humaines et de nos agents d’IA ?

2. Qui est responsable de chaque agent d’IA en production ?

3. Comment sont définis et revus leurs droits d’accès ?

4. Sommes‑nous capables d’expliquer à un régulateur ce qu’un agent d’IA peut faire, sur quelles données, et sous quelle supervision humaine ?

5. Comment notre IA de défense contribue‑t‑elle à surveiller ces identités et à détecter les dérives ?

Si ces réponses ne sont pas claires, c’est probablement le bon moment pour revoir votre gouvernance IAM à l’ère des NHI et des agents d’IA.

Conclusion

Les identités non humaines et les comptes d’agents d’IA ne sont plus un détail technique :

ce sont des **acteurs à part entière** de votre système d’information.

Les ignorer, c’est laisser un angle mort majeur dans votre stratégie de défense, au moment même où les cybercriminels apprennent à exploiter les LLM et les chaînes d’outils d’IA.

À l’inverse, les intégrer dans une gouvernance IAM robuste, appuyée par une **IA de défense** capable de lire ces signaux faibles, devient un levier stratégique pour votre résilience.