L'Estonie a l'intention de délivrer des identités numériques officielles, des « AI ID codes », aux agents IA. Le cabinet du Premier ministre Kristen Michal explique que l'objectif est de permettre à l'IA d'« agir au nom de personnes, d'entreprises ou d'organisations dans des limites clairement définies et d'une manière à la fois vérifiable et auditable ». Si le projet aboutit, l'Estonie devient le premier pays à donner aux agents IA une identité reconnue par l'État. C'est une avancée réellement utile, et c'est aussi la partie facile. La partie difficile, c'est tout ce que cette identité est censée porter.

Je construis avec des agents qui détiennent de vraies credentials, donc ma réaction est moins « est-ce dystopique » et davantage « qu'est-ce que cette identité doit vraiment lier ». Un identifiant seul n'est qu'un nombre. Ce qui lui donne du sens, c'est ce qu'on y attache : l'autorité, une chaîne de délégation et la responsabilité. Si vous vous trompez sur ces points, vous n'avez livré qu'une clé primaire à l'air très officiel.

Ce que l'Estonie a réellement annoncé

Le plan consiste à attribuer à chaque agent un identifiant dont le but est double : l'identification, et la limitation du périmètre de ce que l'agent est autorisé à faire. Le cadrage du cabinet de Michal est le bon : « il doit être clair qui agit au nom de qui, avec quels droits, et qui en est finalement responsable ». Philipp Pointner, responsable de l'identité numérique chez Jumio, y voit un précédent pour « la manière dont nous devons auditer ce que les agents peuvent faire au nom d'un individu », et insiste sur le fait que les systèmes d'identité doivent désormais distinguer l'identité humaine de l'autorité de l'agent.

Cette distinction est l'enjeu central. Une identité humaine répond à « qui êtes-vous ». Une identité d'agent doit répondre à une question plus difficile : « qui vous a autorisé, à faire quoi, et pour combien de temps ».

Pourquoi ce n'est pas qu'une question de bureaucratie

Si vous avez déjà connecté un LLM à des outils, vous savez déjà que l'état de l'art actuel repose sur des credentials empruntées. L'agent s'exécute en tant que service account, ou pire, avec le token OAuth d'un humain et une clé API à longue durée de vie copiée dans une variable d'environnement. L'IAM centré sur l'humain a été conçu autour d'une personne qui se connecte de temps en temps, clique sur un écran de consentement et agit à vitesse humaine. Un agent ne se connecte jamais, son accès lui a été remis par quelqu'un d'autre, et il agit des milliers de fois par minute.

Alors quand un agent fait quelque chose de mal, les logs disent qu'un service account l'a fait, ou qu'un humain l'a fait, parce que c'est son token qui figurait sur la requête. L'action est réelle et la responsabilité est une fiction. L'intuition de l'Estonie, donner à l'agent sa propre identité pour que ses actions lui soient attribuables à lui et remontables jusqu'à celui qui l'a autorisé, comble exactement la faille qu'il faut combler. L'intuition est juste. C'est la mise en œuvre qui devient coûteuse.

Les trois choses qu'une identité d'agent doit porter

1. Une autorité délimitée, pas seulement un nom

Une identité qui prouve « ceci est l'agent X » et rien de plus n'est qu'une étiquette. La valeur réside dans les permissions qui y sont liées : quels systèmes, quelles opérations, quelles données, sous quelles conditions, avec quelles limites de dépense ou de débit. C'est la partie que le communiqué de presse survole avec « des limites clairement définies » et celle qui prend des années à bien faire, parce qu'un périmètre trop large recrée le problème d'origine et un périmètre trop étroit rend l'agent inutile. Nous disposons déjà de primitives pour cela, les scopes OAuth, l'identité de charge de travail, les capability tokens, mais une couche d'identité nationale doit s'interfacer avec elles, et non se poser au-dessus comme une quatrième source de vérité concurrente.

2. Une chaîne de délégation que l'on peut réellement suivre

« Qui agit au nom de qui » n'est pas un seul saut. Une personne autorise un agent, l'agent appelle un outil, l'outil engendre un sous-agent, le sous-agent interroge une API tierce. Chaque étape restreint, ou devrait restreindre, l'autorité. Si l'identité ne capture pas la chaîne, vous obtenez le classique confused-deputy problem à la vitesse de la machine : un composant disposant d'un accès légitime est dupé pour l'utiliser au profit de quelqu'un d'autre, et le log d'audit montre un appel propre et autorisé. Une identité d'agent ne vaut que par sa capacité à enregistrer et à contraindre cette chaîne, et pas seulement l'acteur final.

3. Une responsabilité qui retombe sur un humain

Voici la partie que la technologie ne peut pas résoudre. Vous pouvez donner à un agent une identité, un portefeuille et un périmètre, mais lorsqu'il vide un compte ou signe un mauvais contrat, la responsabilité ne s'arrête pas à l'agent. Elle remonte vers une personne ou une organisation. L'identité est le mécanisme qui rend cette remontée possible, ce qui est une bonne chose, mais elle ne décide pas qui est responsable : le mandant qui a délégué, le développeur qui a construit l'agent, ou le fournisseur qui a livré le modèle. L'Estonie fait preuve de responsabilité en forçant cette question à émerger tôt. Personne n'a encore de réponse nette.

L'identité est nécessaire, pas suffisante

Une formule récente du BCG, citée dans la couverture médiatique, touche au problème de fond : « Les valeurs ne sont pas des règles. Ce sont des croyances et des principes formés par des milliers de décisions humaines, façonnés par le contexte, l'exception et le précédent. » Un AI ID code peut encoder des règles. Il ne peut pas encoder le jugement. Un agent doté d'une identité parfaite, parfaitement délimitée, parfaitement auditée, peut malgré tout entreprendre une action techniquement autorisée et manifestement mauvaise. L'identité vous donne l'attribution et la révocation. Elle ne vous donne pas un bon comportement. Ce sont des problèmes différents, et les confondre, c'est ainsi que l'on finit par faire plus confiance à un agent que sa conception ne le justifie, simplement parce qu'il porte un joli badge.

Ce que cela signifie si vous construisez avec des agents

Vous n'avez pas besoin d'attendre un registre gouvernemental pour appliquer ce raisonnement. Le plan estonien n'est que la version à l'échelle nationale de choix que vous devriez déjà faire :

  • Donnez à chaque agent sa propre identité. Pas un service account partagé, pas le token d'un humain. Un principal par agent, pour que ses actions lui soient attribuables à lui seul.
  • Délimitez selon la tâche, puis faites expirer. Des credentials à courte durée de vie et au périmètre étroit l'emportent à chaque fois sur les clés à longue durée de vie. Un agent qui n'a besoin que de lire ne devrait jamais détenir un token capable d'écrire.
  • Journalisez la chaîne de délégation, pas seulement l'appel. Enregistrez qui a autorisé l'agent et dans quel périmètre, pour que « qui agit au nom de qui » soit une requête, et non une fouille forensique.
  • Rendez la révocation instantanée. La première chose que vous voulez quand un agent dérape, c'est un interrupteur qui fonctionne en quelques secondes, pas une rotation de clé qui prend une journée.
  • Maintenez délibérément un humain responsable. Décidez, avant le déploiement, qui assume les actions de l'agent. Ne laissez pas l'organigramme le découvrir pendant un incident.

L'Estonie a raison de penser que des agents opérant à la vitesse de la machine ont besoin d'une responsabilité intégrée, et raison de penser que l'identité en est le point de départ. Gardez seulement l'ordre des difficultés à l'esprit. Délivrer l'identité, c'est l'annonce. Lier l'autorité, tracer la délégation et décider qui répond pour l'agent, c'est le travail, et c'est le même travail que vous soyez une petite équipe qui connecte un modèle utilisant des outils ou un pays qui délivre des identifiants à toute l'économie des agents.

À lire ensuite

Pour le versant infrastructure et plateforme de l'exécution sûre des agents, les notes de terrain cloud sont sur ercan.cloud. Pour du conseil sur l'IA, l'identité et le travail de plateforme, ou simplement pour dire bonjour, commencez par ercanermis.com.