Identité des agents IA : définition et gestion des identités non humaines

Que recouvre l’identité des agents IA ?

L’identité d’un agent répond à trois questions : qui agit, au nom de qui, avec quels droits. Votre système d’information gère déjà des identités non humaines : comptes de service, clés d’API, jetons d’accès, certificats. Selon l’OWASP, elles n’ont souvent aucun lien direct avec une personne, et les protections pensées pour les salariés ne s’y appliquent pas.

L’agent IA ajoute une difficulté : il choisit ses actions. Un compte de service répète le même traitement ; un agent décide selon ce qu’il lit, contenu piégé compris. Le MCP prévoit deux cas : l’application d’IA agit au nom d’un utilisateur, ou en son propre nom (spécification du 28 juillet 2026).

En février 2026, le NCCoE, centre de cybersécurité du NIST américain, a consulté le public sur l’identité des agents. Il a reçu plus de 600 réponses. Selon sa synthèse de septembre 2026, presque tous les répondants veulent pour les agents des identités non humaines « distinctes et vérifiables ».

Identité de l’agent ou compte de l’utilisateur : quelle différence ?

Un agent qui utilise votre compte se fait passer pour vous ; un agent doté de sa propre identité agit pour vous, sous son nom. La norme OAuth 2.0 Token Exchange (RFC 8693, janvier 2020) distingue ces deux cas. Dans l’emprunt d’identité (impersonation), l’agent reçoit les droits de la personne dans un périmètre défini, et rien ne le distingue d’elle. Dans la délégation, il garde sa propre identité et agit pour le compte de la personne ; le jeton le désigne comme acteur.

Selon l’OWASP, un agent sans identité propre et gouvernée crée un « attribution gap », un défaut d’attribution (Top 10 des applications agentiques, décembre 2025). Le moindre privilège devient alors impossible à appliquer.

Ne confondez pas non plus l’identité et les guardrails : l’identité dit qui agit et pour qui ; les guardrails bornent ce que l’agent fait de ses droits.

Que change l’identité des agents IA pour votre décision ?

• Chaque agent figure dans un inventaire, avec un propriétaire. Un agent sans propriétaire survit au projet qui l’a créé. L’OWASP place en tête des risques des identités non humaines la désactivation mal faite des identités devenues inutiles (NHI1, classement 2025). Le projet OWASP MCP Top 10, encore en bêta, signale aussi des serveurs MCP installés hors gouvernance, souvent avec des identifiants par défaut (MCP09). Ces agents relèvent du shadow AI. Votre gouvernance de l’IA les recense, chacun avec son propriétaire et ses accès.

• Les droits suivent la tâche, pas la personne. Un agent relié à votre compte atteint tout ce que vous atteignez. En mai 2025, la société de sécurité Invariant Labs l’a montré sur GitHub. Un ticket piégé dans un dépôt public a poussé un agent à y recopier des données des dépôts privés de son utilisateur. La société recommande de limiter l’agent aux dépôts utiles, par exemple un seul par session. Le développeur Simon Willison nomme « triade létale » la réunion de trois accès : données privées, contenus non fiables, communication vers l’extérieur (juin 2025). N’accordez jamais les trois à une même identité. Un outil piégé exploite les mêmes droits : c’est le tool poisoning.

• Les accès expirent vite. Une clé de longue durée qui fuit donne à l’attaquant un accès « sans contrainte de temps », selon l’OWASP (NHI7). L’OWASP recommande des identités propres à chaque agent et des jetons de courte durée, limités à une tâche (ASI03). Les répondants du NCCoE défendent aussi des identifiants très éphémères.

• Les droits s’accumulent : revoyez-les. Dans le MCP, une application qui demande un droit nouveau redemande aussi ceux qu’elle détient déjà, comme le recommande la spécification. Le projet OWASP MCP Top 10 décrit cette dérive : des permissions temporaires ou floues qui s’étendent avec le temps (MCP02). Fixez pour chaque agent une date de revue des droits et une date de fin.

• Le journal distingue l’humain de l’agent. Sans cette distinction, une enquête attribue au salarié l’action de son agent. Exigez des journaux qui portent les deux noms : l’agent qui agit et la personne pour qui il agit. Quand un agent agit pour un utilisateur, Microsoft Entra Agent ID, par exemple, inscrit l’utilisateur comme sujet du jeton et l’agent comme acteur. Chaque agent peut y recevoir un « sponsor » : la personne ou le groupe qui répond de lui. Nous citons cette offre comme exemple, sans la recommander.

Exemple illustratif

Ce cas est fictif. Une ETI de négoce confie à un agent la relance des fournisseurs en retard. Au départ, l’agent utilise le compte de la responsable achats : il atteint aussi les paiements, et le journal ne montre qu’elle. La DSI lui crée une identité propre, limitée à la lecture des commandes et aux courriels vers les fournisseurs référencés. Ses jetons expirent après une heure. Le journal indique « agent relances, pour le compte de la responsable achats ». Propriétaire de l’agent, la responsable revoit ses droits chaque trimestre et le désactivera en fin de projet.