Identités non humaines

Identité IA

Une identité IA est l'identité gouvernée d'un agent, d'un modèle ou d'un assistant d'intelligence artificielle, qui permet de savoir qui agit, au nom de qui, sur quelle ressource et avec quelles limites.

Synonyme
identité d'agent IA

Définition

Une identité IA est la représentation d'identité attribuée à un agent IA, à un assistant piloté par un modèle ou à un composant logiciel autonome, afin que ses actions puissent être attribuées, contraintes, tracées et gouvernées. Elle ne se limite pas à un enregistrement dans un annuaire : un agent agit, appelle des outils, lit des données et déclenche des effets réels. La question utile n'est donc pas seulement « cet agent existe-t-il ? », mais « cette action précise, dans ce contexte précis, est-elle autorisée ? ».

Pourquoi c'est important

Un agent IA enchaîne des actions à une vitesse et à un volume sans équivalent humain. Sans identité gouvernée, ses accès deviennent impossibles à attribuer, ses droits s'accumulent et un incident ne peut plus être reconstitué. L'identité IA est ce qui rend l'autonomie acceptable en entreprise.

Au-delà de l'inventaire : gouverner l'identité IA au runtime

Recenser les agents est une première étape, nécessaire mais insuffisante. Un agent IA ne se comporte pas comme une application figée : il compose des actions, appelle des outils, agit parfois au nom d'un utilisateur et parfois pour son propre compte. Deux exécutions du même agent peuvent viser des ressources très différentes.

La gouvernance utile se joue donc au moment de l'action. Elle consiste à décider, requête par requête, si l'action demandée est autorisée compte tenu de l'agent, de l'utilisateur délégué, de la ressource visée, de sa sensibilité et du contexte d'exécution. Ce contrôle s'appuie sur des politiques externalisées, évaluées par un point de décision (PDP) et appliquées par un point d'application (PEP) placé devant l'API ou l'outil.

Les modèles d'autorisation adaptés sont ceux qui savent tenir compte d'attributs et de contexte : ABAC, PBAC et politiques hybrides. Le ReBAC reste pertinent lorsque la décision dépend réellement d'un graphe de relations, par exemple un partage de document, mais il ne suffit pas à lui seul à encadrer un agent dont le périmètre change à chaque requête.

Le parcours d'une action d'agent IA
  1. Identité IA

    Agent enregistré, propriétaire connu, cycle de vie défini

  2. Authentification

    Preuve d'identité de l'agent, secrets maîtrisés

  3. Politique d'autorisation

    Règles ABAC, PBAC ou hybrides, écrites hors du code

  4. PDP

    Décision prise à l'instant de l'action, avec le contexte

  5. Allow / Deny

    Autorisation, refus ou obligation associée

  6. PEP — API, outil, ressource

    La ressource n'est atteinte qu'après la décision

  7. Observation du comportement

    Traces exploitables, dérives détectables

Un agent IA ne se gouverne pas seulement au moment de sa création : la décision utile se prend au moment de l'action.

Agentic IAM

L'Agentic IAM désigne l'application des principes IAM aux agents autonomes : leur donner une identité propre, une authentification vérifiable, des politiques d'autorisation évaluées au moment de l'action et une observation continue de leur comportement. C'est l'extension logique de la gestion des identités non humaines à des composants qui prennent des initiatives.

Les trois propriétés d'une identité IA gouvernée

L'attribution : chaque action de l'agent peut être rattachée à un propriétaire humain ou applicatif responsable. Un agent qui s'exécute sous un compte de service partagé et anonyme rompt cette propriété, car un incident ne peut plus être attribué à son responsable.

Un cycle de vie borné : l'identité et ses secrets sont limités dans le temps. Les jetons expirent, les accès sont revus et l'agent est retiré lorsqu'il n'a plus de raison d'exister, au lieu d'accumuler des permissions permanentes.

Une traçabilité opposable : un journal d'audit fiable et horodaté permet de reconstituer après coup qui a fait quoi, sur quelle ressource et dans quel contexte. Ces trois propriétés sont des exigences de conception portées par l'identité elle-même ; elles complètent les couches de contrôle décrites plus haut.

Les quatre couches de gouvernance d'une identité IA

Une identité IA maîtrisée repose sur quatre couches complémentaires : aucune ne remplace les autres.

  1. 01
    Gouvernance des identités (IGA)

    Enregistrer l'agent, lui attribuer un propriétaire, définir son cycle de vie, revoir ses droits et le retirer quand il n'a plus de raison d'exister.

  2. 02
    Gestion des accès

    Authentifier l'agent avec des secrets maîtrisés et distinguer clairement ce qu'il fait pour lui-même de ce qu'il fait au nom d'un utilisateur délégué.

  3. 03
    Autorisation fine

    Évaluer chaque action avec le contexte : la politique est portée par un PDP et appliquée par un PEP devant l'API ou l'outil appelé.

  4. 04
    Sécurité au runtime

    Observer le comportement réel de l'agent, tracer les actions de bout en bout et détecter les dérives de volume, de périmètre ou d'usage.

Le point de vue d'Ariovis

Un agent IA n'est pas un utilisateur un peu rapide : c'est une identité qui agit en continu. Nous considérons qu'un agent ne devrait jamais dépendre d'un compte de service partagé, ni porter ses règles d'accès dans son propre code. Il lui faut une identité propre, des politiques externalisées évaluées au moment de l'action, et une observation de son comportement réel. C'est cette combinaison, et pas l'inventaire seul, qui rend l'autonomie gouvernable.

Les pièges courants

  • Laisser des agents IA fonctionner sous des comptes de service génériques, sans propriétaire ni attribution individuelle.
  • S'arrêter à l'inventaire des agents et considérer que la gouvernance est faite, alors que rien ne contrôle l'action au moment où elle est demandée.
  • Coder les règles d'accès dans les prompts ou dans le code de l'agent, ce qui rend les décisions invisibles, non auditables et impossibles à faire évoluer.
  • Traiter l'autorisation d'un agent comme celle d'une application classique, alors que son périmètre d'action varie d'une requête à l'autre.

Ces notions prennent tout leur sens dans un projet réel.

Le premier échange permet de comprendre votre contexte, vos systèmes et la prochaine décision utile.