(3/3) Donner à chaque agent IA une identité responsable et privée à la fois
Les deux premiers posts de cette série se sont achevés sur le même nœud. Les agents brisent la pile d'identité parce qu'il n'y a plus personne au clavier, et la meilleure recherche sur le problème nomme la partie la plus dure et la laisse ouverte : pour rendre un agent responsable, vous lui attachez une identité réelle, et à l'instant où vous le faites, vous avez construit de la surveillance. Responsabilité ou vie privée. Choisissez.
Je ne crois pas que ce soit une loi de la nature. Je crois que nous tenons le problème à l'envers. Dans ce post, je veux vous donner une idée d'ensemble de la manière dont je le retournerais, et une esquisse — de haut niveau — de l'approche vers laquelle je travaille vraiment depuis quelques jours.
Je veux être honnête d'entrée sur ce que c'est, parce que dans ce milieu la rhétorique monte vite. C'est un concept dont je suis convaincu, pas une chose finie. Certaines de ses pièces touchent à du terrain réglementé — détenir de l'argent au nom d'autrui, ça ne se règle pas d'un revers de main — et je signalerai les limites au fil du texte plutôt qu'à la fin. En matière d'identité, la crédibilité ne s'achète pas avec des promesses creuses.
L'erreur, c'est d'attacher une identité à l'agent tout court
Voici le geste que tout le monde fait, parce que c'est le geste évident. Vous avez un agent. Vous le voulez responsable. Alors vous liez une identité réelle et connue à l'agent — chaque action qu'il prend remonte à un humain nommé. Le trou noir se referme. Et en le refermant, vous créez un lien permanent et interrogeable entre une personne et tout ce que sa flotte d'agents fait, à longueur de journée, sur tous les services. Vous avez résolu la responsabilité en dépensant de la vie privée, et vous l'avez dépensée par agent, pour toujours.
Maintenant, retournez-le. Faites la vérification une seule fois, sur l'humain — et ne laissez circuler que le fait de cette vérification dans chaque agent qu'il déploie, jamais l'identité qui se trouve derrière.
Dans le KYC classique, vous vous identifiez auprès de la partie avec qui vous traitez. Dans la version inversée, un humain fait son KYC une fois auprès d'un émetteur, puis frappe autant d'accréditations d'agent qu'il le souhaite — une par agent — chacune capable de prouver une affirmation et rien de plus : « Je suis opéré par un humain réel, vérifié par KYC, redevable, à un niveau de vérification ≥ G, agissant dans le périmètre S, et je ne suis pas révoqué. » Pas quel humain. Juste qu'il y en a un, qu'il est réel et responsable, et qu'il se porte garant de cet agent. L'agent prouve qu'il a un répondant. Il ne prouve jamais une identité, parce qu'il ne la détient jamais.
Le zero-knowledge, c'est la charnière que le papier désignait
C'est exactement la porte que le papier de l'OpenID a marquée sans la franchir : la divulgation sélective par preuves à divulgation nulle de connaissance et accréditations anonymes, « un chemin possible ». Toute l'approche vit ou meurt selon qu'on rend cela concret.
L'agent présente une courte preuve cryptographique qui ne répond qu'aux prédicats dont une contrepartie a réellement besoin — adossé à un humain : oui ; vérifié au niveau A2 ou supérieur : oui ; autorisé à initier des paiements : oui ; actif et non révoqué : oui — et ne révèle rien d'autre. Pas de nom. Pas de document. Aucun lien entre deux agents que la même personne exploite, de sorte qu'une contrepartie ne peut pas, en douce, recoller une flotte en un profil. La vérification que l'humain a faite une fois est réutilisable par tous ses agents et illisible pour aucun des services auxquels ces agents parlent.
Trois propriétés font tenir l'ensemble, et je les traiterais comme des invariants — les choses qu'on ne s'autorise jamais à casser pour la commodité :
- Le répondant est prouvable ; l'identité ne l'est pas. Un vérificateur peut confirmer qu'un humain réel et redevable se tient derrière l'agent, sans pouvoir apprendre qui c'est.
- Les agents d'un même opérateur sont non corrélables. Les gens avec qui ils traitent ne peuvent relier deux agents issus du même principal.
- Le seul fil qui remonte à la personne vit sous séquestre, ouvrable uniquement par voie légale. Pas dans un jeton, pas sur le réseau, pas dans un journal qu'une fuite pourrait déverser.
Une responsabilité qu'on peut encaisser, pas seulement prouver
Prouver qu'un humain redevable existe est nécessaire et, à soi seul, insuffisant pour du vrai commerce. Je l'ai appris en regardant comment les litiges se règlent vraiment : une contrepartie lésée ne veut pas un nom des mois après un procès transfrontalier. Elle veut récupérer son argent, vite. Une responsabilité qui est prouvable mais pas payable ne débloque rien de gros enjeu.
Le répondant doit donc être financé. À côté de la preuve d'humain-vérifié, un agent peut porter la preuve qu'un recours réel et borné se tient derrière lui — du capital que le principal a déposé, prouvable sous forme de palier (« au moins tant est récupérable ») sans jamais exposer le solde exact ni le compte. C'est la version préfinancée et respectueuse de la vie privée de ce vers quoi le marché tâtonne déjà avec ses jetons de paiement « Know Your Agent » — à ceci près qu'ici l'argent est réel et que l'humain reste à couvert.
Cela transforme la responsabilité en une échelle plutôt qu'en une falaise unique. La plupart des litiges se règlent au premier barreau : une réclamation étayée est payée sur le recours déposé, selon un processus publié, le principal est débité et notifié, et aucune identité n'est révélée à personne. Seuls les véritables cas de dernier ressort — préjudice au-delà des fonds déposés, fraude alléguée, contrainte légale — montent jusqu'à démasquer effectivement l'humain, par voie légale. Une responsabilité financée finit par protéger davantage la personne, pas moins, parce qu'elle règle les cas ordinaires avec de l'argent plutôt qu'avec un nom.
Je serai franc sur les arêtes vives ici, parce que c'est la partie réglementée. La garde de fonds appartenant à autrui suppose un dépositaire agréé et cautionné, des comptes ségrégués, des contrôles anti-blanchiment sur l'origine des fonds, et un traitement honnête de la réversibilité — de l'argent déposé via un instrument de paiement courant peut être repris des mois durant, donc le recours qu'il garantit ne peut pas être tenu pour définitif dès le premier jour. Tout moyen d'embarquer un humain vite et sans friction est, par définition, à faible niveau d'assurance, et doit être noté comme tel plutôt que maquillé en mieux. Rien de tout cela n'est une raison de ne pas le construire. C'est la raison pour laquelle il faut le construire avec soin, le cadre juridique avançant aux côtés du protocole et non à sa traîne.
Ça ne marche que si personne ne possède la racine
Il y a une contrainte du deuxième post que je ne brade pas, parce qu'elle exclut l'argent facile : cela ne doit pas devenir un jardin clos. La version la mieux capitalisée de cette idée, c'est un service centralisé d'identité d'agents que vous louez à un fournisseur unique, et pour une économie d'agents ouverte et inter-organisations, c'est rédhibitoire. Une contrepartie dans une autre entreprise, sur une autre pile, doit pouvoir vérifier la preuve sans téléphoner à l'API privée de l'émetteur et sans avoir à faire confiance à une seule société pour qu'elle ne capte pas de rente, ne censure pas, ou ne se fasse pas pirater.
Cela pousse l'ancre de confiance vers une racine neutre que nul ne possède — un endroit où un vérificateur peut contrôler, par rapport au statut actuel de l'émetteur, qu'une accréditation est réelle et non révoquée, sans aucune visibilité sur qui se trouve derrière. Une racine neutre achète aussi deux choses que le papier de recherche signalait comme non résolues : la révocation rapide et globale — un signal de statut rafraîchi souvent, pour qu'une accréditation tuée cesse de vérifier en quelques secondes, partout — et un coupe-circuit par agent, pour qu'un agent compromis puisse être lâché sans faire tomber le principal ni ses frères et sœurs.
La propriété qui permet à tout cela de passer à l'échelle est presque ennuyeuse, et c'est celle qui compte le plus : un agent n'est qu'un porteur d'accréditation de plus. Il n'y a pas d'enregistrement par agent posé dans un registre central, à énumérer, pirater ou laisser enfler. La couche de confiance ne détient qu'une poignée de racines de statut d'émetteurs, rafraîchies à cadence courte ; les agents — et l'argent derrière eux — vivent à côté, prouvés par rapport à ces racines, jamais enrôlés dedans. C'est ce qui permet à ce design de s'étirer jusqu'à une population d'agents plus grande que la population humaine sans l'explosion d'état qui tue toute approche « enregistrons chaque agent au centre ».
Le fil conducteur
Ôtez la cryptographie et la contrainte est simple, et c'est la même que je tourne autour depuis le premier post : l'agent est autonome, mais la responsabilité ne peut pas l'être. Derrière chaque flotte, il y a un humain réel et redevable, et tout le jeu consiste à prouver ce fait à quiconque en a besoin tout en n'exposant la personne à personne. Vérifiez l'humain une fois. Laissez la responsabilité — financée, révocable et privée — voyager dans tout ce qu'il déploie. Gardez l'unique fil qui remonte à son identité enfermé derrière la voie légale, là où une fuite ne peut l'atteindre et un marketeur ne peut l'acheter.
J'ai cadré toute cette série autour du besoin technique exprès, parce que le besoin est réel, que ma réponse particulière soit la bonne ou non, et je préfère que vous jugiez le problème avant que je vous montre l'outil. Cette partie-là vient ensuite, hors de cette série : je suis en train de construire ceci, pas seulement de l'esquisser, et bientôt je vous montrerai à quoi ça ressemble vraiment.
Si vous vous débattez en ce moment avec l'identité ou la responsabilité des agents au cœur de vos propres systèmes et voulez un deuxième regard de gens qui construisent ça pour gagner leur vie, parlez à un CTO. La carte est difficile. Elle l'est beaucoup moins en bonne compagnie.


