Identité de l'agent : pourquoi votre agent IA doit être un principal à part entière
Cet article fait partie de la série Les défis d’authentification et d’autorisation de l’IA agentique.
Imaginez la façon la plus rapide, pour la plupart des équipes, de faire parler un agent à un backend : lui donner les mêmes client credentials que l’application web dans laquelle il vit, ou — pire — le laisser réutiliser l’access token dont dispose l’utilisateur courant. Ça fonctionne en démo. Cela signifie aussi que, du point de vue du resource server, « l’agent » n’existe pas en tant que tel. Il n’y a que l’application, ou que l’utilisateur, faisant des choses un peu plus étranges que d’habitude.
C’est la faille d’identité, et c’est la première qu’il vaut la peine de combler, car toutes les autres failles de cette série supposent qu’on a déjà répondu à une question : qu’est-ce qui, exactement, agit ?
Les deux réponses faciles, et ce que chacune fait perdre
Traiter l’agent comme l’utilisateur. L’agent hérite de la session ou de l’access token de l’humain et agit avec toute son autorité. C’est le chemin de moindre résistance, et c’est aussi la façon dont on perd entièrement le scoping en moindre privilège. L’utilisateur qui peut consulter ses propres factures n’a pas nécessairement voulu dire « et laisser aussi un processus en arrière-plan interroger toutes les factures du compte, indéfiniment ». Un agent opérant avec le token brut d’un utilisateur peut généralement faire tout ce que l’utilisateur pourrait faire via l’interface — une surface bien plus large que la tâche précise qu’on lui a demandé d’accomplir. Cela effondre aussi l’attribution : quand un journal d’audit affiche l’identifiant de l’utilisateur associé à une action, on ne peut plus savoir si l’humain a cliqué sur un bouton ou si un agent a décidé, de son propre raisonnement, de mener cette action en son nom.
Traiter l’agent comme un client machine générique. L’agent reçoit son propre enregistrement client_credentials, comme n’importe quel autre service backend. Cela préserve une certaine séparation avec l’utilisateur, mais efface généralement une autre distinction : un seul credential statique par type d’agent, partagé entre toutes les instances et toutes les sessions utilisateur que cet agent sert. Si l’instance d’agent A (servant l’utilisateur 1) et l’instance B (servant l’utilisateur 2) partagent le même client ID et le même secret, on ne peut pas révoquer l’une sans révoquer l’autre, on ne peut pas les distinguer dans les claims d’un token, et « quel agent a fait ça » se résout uniquement à « un agent de ce type », pas à une instance précise en train de traiter une tâche précise.
Aucune des deux réponses n’est fausse à proprement parler — elles sont simplement toutes deux insuffisamment précises pour ce dont les systèmes agentiques ont réellement besoin : un principal distinct de l’utilisateur qu’il sert et distinct de chaque autre instance de son propre type.
Ce qu’exige réellement une identité d’agent à part entière
Quatre propriétés séparent, en pratique, une véritable identité d’agent d’une identité empruntée :
Un identifiant unique et stable par unité de déploiement pertinente. Pas nécessairement par appel d’API individuel, mais par instance d’agent, par tenant, ou par toute granularité à laquelle vous voudrez réellement révoquer ou auditer plus tard. Si vous ne pouvez pas répondre à « quel déploiement d’agent précis a fait ça » sans croiser trois autres systèmes, l’identifiant est trop grossier.
Un cycle de vie de credential indépendant. Les credentials de l’agent doivent pouvoir être émis, tournés (rotation) et révoqués sans toucher au compte de l’utilisateur humain ni aux credentials d’un autre agent. Cela semble évident et est pourtant systématiquement négligé, car il est plus simple d’amorcer un nouvel agent en clonant la configuration d’un compte de service existant que de concevoir un flux d’enregistrement pour un type de principal véritablement nouveau.
Un scope contraint indépendamment des propres permissions de l’utilisateur. Un agent agissant pour un utilisateur devrait typiquement détenir l’intersection de ce que l’utilisateur est autorisé à faire et de ce que la tâche précise exige — pas simplement « tout ce que l’utilisateur peut faire ». Cela signifie que la frontière de permission de l’agent doit pouvoir s’exprimer et s’appliquer séparément de celle de l’utilisateur, même quand l’agent agit nominalement en son nom.
Une visibilité dans chaque token et chaque journal en aval. Quel que soit le système qui reçoit finalement une requête, il doit pouvoir voir, dans le token ou dans la requête elle-même, qu’un agent est celui qui la présente — et idéalement lequel, et pour le compte de qui. C’est moins une question d’UX qu’une question forensique : six mois plus tard, quand quelqu’un demandera « pourquoi cela s’est-il produit », la réponse doit pouvoir être reconstruite à partir de ce qui a réellement été enregistré, pas de la mémoire institutionnelle de la façon dont le système était censé fonctionner.
Là où les protocoles aident déjà, et là où ce n’est pas encore le cas
Rien de tout cela n’exige un nouveau protocole conçu de zéro. Le grant client credentials d’OAuth 2.0 est un socle parfaitement raisonnable pour un agent qui agit de façon autonome, sans aucun contexte utilisateur — jobs en arrière-plan, agents de maintenance planifiée, tout ce qui n’a pas besoin de prouver qu’il agit pour le compte de quelqu’un. La faille apparaît précisément dans le cas délégué : un agent agissant pour un utilisateur, où le token doit porter deux identités simultanément — celle de l’agent, et celle de l’utilisateur — plutôt que de les fusionner en une seule.
C’est précisément à cela que sert le claim act, défini dans le cadre du Token Exchange d’OAuth 2.0 (RFC 8693) : un token peut porter à la fois un claim sub identifiant de qui l’autorité est exercée et un claim act identifiant qui présente réellement le token et agit, avec la possibilité d’imbriquer des claims act lorsqu’il y a plus d’un saut de délégation dans la chaîne. Cette structure correspond exactement à la forme du problème — elle est simplement sous-utilisée, car beaucoup d’implémentations se rabattent encore sur les deux réponses faciles ci-dessus plutôt que de modéliser l’agent comme son propre acteur dès le départ. Nous détaillerons la mécanique du token exchange lui-même dans le prochain article ; le point ici est plus restreint : le modèle de données pour « qui est l’utilisateur, et qui agit réellement » existe déjà dans les standards. La faille d’identité est surtout une faille de conception, pas une faille de protocole.
Recommandations pratiques
Quelques patterns qu’il vaut la peine d’adopter tôt, avant qu’une flotte d’agents ne devienne assez grande pour que le rattrapage devienne douloureux :
Enregistrez les agents comme leur propre classe de principal, pas comme une variante d’une classe existante. Si votre fournisseur d’identité ou votre système interne distingue « utilisateurs » et « applications », un agent qui agit pour le compte d’utilisateurs sans être lui-même un utilisateur mérite d’être considéré comme une troisième catégorie, même si la mécanique de credential sous-jacente réutilise des patterns machine-to-machine existants.
Séparez le type de l’agent de son instance. Il est raisonnable d’avoir un template ou un blueprint pour « l’agent de tri des tickets de support » qui définit son scope de base — mais ce qui s’authentifie réellement auprès de vos systèmes, se fait révoquer et apparaît dans un journal d’audit devrait être un déploiement précis et individuellement identifiable de ce template, pas le template lui-même.
Concevez la granularité de révocation dès le premier jour. Demandez-vous, avant la mise en production du premier agent : si cette instance précise se met à se comporter de façon inattendue, peut-elle être coupée sans affecter un autre agent, un utilisateur, ou une autre instance du même type d’agent ? Si la réponse exige de faire tourner un secret partagé, la granularité est mauvaise.
Rendez l’agent visible dans les claims, pas seulement dans des journaux que vous seuls contrôlez. Si un resource server en aval, une API partenaire, ou un rapport de conformité a besoin de distinguer « l’utilisateur a fait ça » de « l’agent a fait ça pour le compte de l’utilisateur », cette distinction doit vivre dans le token lui-même — pas dans un journal annexe que seule votre équipe peut lire.
Rien de tout cela n’est exotique. C’est la même discipline qu’on applique depuis toujours aux comptes de service — identité distincte, permission scopée, cycle de vie indépendant — étendue à un principal qui a la particularité de raisonner sur la prochaine action à entreprendre plutôt que d’exécuter un script figé. Bien traiter cette partie est ce qui rend résoluble chaque article suivant de cette série ; la traiter mal, et la délégation, le consentement et la gouvernance héritent tous de la même ambiguïté sur qui, exactement, a fait quoi.
Prochain article de la série : Bien déléguer : le Token Exchange et le pattern On-Behalf-Of, qui explique comment une identité d’agent, une fois établie, prouve concrètement qu’elle agit pour un utilisateur précis avec un scope précis.