(2/3) La meilleure carte dont nous disposons du problème de l'identité agentique
Dans le premier post de cette série, j'ai exposé pourquoi l'IA agentique fait éclater la pile d'identité : chaque système que nous avons bâti tient pour acquis qu'il y a un humain au clavier, et les agents emportent ce postulat dès le premier jour. J'avais promis la carte la plus claire que je puisse trouver de ce terrain. La voici.
L'essentiel de ce qui s'écrit aujourd'hui sur « l'identité de l'IA », c'est un éditeur qui vous explique pourquoi la réponse est, justement, ce qu'il vend. Ce papier est tout le contraire, et c'est exactement pour cela que je lui fais confiance. Identity Management for Agentic AI a été préparé pour l'OpenID Foundation, édité sous la direction de Tobin South, rédigé tout au long de 2025 avec l'AI Identity Management Community Group et la Loyal Agents Initiative de Stanford, et relu par une longue liste d'ingénieurs en identité. C'est l'étude d'un organisme de normalisation, pas un argumentaire commercial. Il vous dit ce qui marche déjà, ce qui émerge, et — c'est la partie rare — ce que personne n'a encore résolu. Je l'ai parcouru en profondeur. Voici ce qui m'en est resté.
La pile actuelle fonctionne — à l'intérieur d'une entreprise, pour un agent qui attend
Le papier se divise nettement en deux : les solutions immédiates pour les agents que nous livrons aujourd'hui, et les problèmes prospectifs pour ceux que nous nous apprêtons à livrer. Le verdict honnête sur la première moitié tient en une phrase, et je cadrerais tout le domaine autour d'elle :
« Les agents et les schémas d'authentification et d'autorisation d'aujourd'hui peuvent convenir aux agents synchrones utilisant plusieurs outils à l'intérieur d'un domaine de confiance unique, mais pas aux contextes asynchrones ou multi-domaines. »
Relisez-la deux fois. À l'intérieur d'une entreprise, pour un agent qui agit pendant que vous attendez, les fondations tiennent. OAuth 2.1 avec PKCE sécurise le flux. Vous externalisez la décision vers un fournisseur d'identité ou un point de décision de politique au lieu de la coder en dur — la séparation entre Policy Enforcement Point et Policy Decision Point que le NIST a écrite il y a une décennie. Vous gérez le cycle de vie de l'agent avec la même mécanique que celle de vos employés : SSO pour la connexion, et SCIM pour le provisionnement et, surtout, le déprovisionnement. Le papier pointe des travaux expérimentaux visant à doter SCIM d'un type de ressource AgenticIdentity de plein droit, pour qu'un agent devienne une entité gérée, avec des propriétaires et des appartenances de groupe, plutôt qu'une clé d'API orpheline. Rien de tout cela n'est exotique. Une équipe plateforme compétente peut le construire dès maintenant.
Deux conditions soutiennent pourtant tout ce tableau : synchrone, et domaine de confiance unique. Brisez l'une ou l'autre et vous voilà dans la seconde moitié du papier, là où les problèmes résolus s'épuisent.
Nommer les problèmes futurs avec précision
Nommez un problème avec précision et vous êtes à mi-chemin de le résoudre — et ce papier, comme mon propre travail, refuse de balayer d'un revers de main les parties difficiles. Il les énumère, avec la franchise de gens qui ont vraiment essayé de construire tout cela.
Commençons donc par la question la plus élémentaire : qu'est-ce que l'identité d'un agent, au juste ? Le papier expose quatre modèles architecturaux : le compte de service enrichi (une identité de workload augmentée de métadonnées agent_model, agent_version — le schéma d'entreprise le plus probable à court terme) ; la sous-identité d'utilisateur déléguée (une identité dérivée de la session de l'utilisateur et liée à elle, le vrai flux on-behalf-of) ; la confiance fédérée (un tissu interopérable entre domaines, bâti sur quelque chose comme OpenID Federation) ; et l'identité souveraine et portable (chaque agent détenant ses propres clés et un identifiant unique au monde, via des schémas comme les DIDs). Des propositions telles qu'OpenID Connect for Agents tentent de normaliser les claims d'identité qui se trouvent en dessous. Nous ne pouvons pas encore couronner un gagnant — il faut connaître le terrain avant de pouvoir s'en frayer une sortie.
La délégation, pas l'usurpation, est l'épine dorsale
Si je devais comprimer l'argument du papier en un seul geste, ce serait celui-ci : cessez de laisser les agents usurper l'identité des utilisateurs, commencez à leur faire porter une autorité déléguée. Aujourd'hui, un agent agit avec vos identifiants et le journal d'audit ne sait pas vous distinguer l'un de l'autre — le trou noir que je décrivais la dernière fois. Le correctif est un vrai flux on-behalf-of où le jeton d'accès porte deux identités distinctes : l'utilisateur qui a délégué (dans le claim sub) et l'agent qui agit (dans le claim act). Un lien net et auditable dès le premier pas.
La puissance, et la difficulté, surgissent avec la délégation récursive — un agent confiant une sous-tâche, et une part de son autorité, à un autre. Comme une poupée russe, dit le papier, et c'est un avertissement. Un serveur de ressources au bout d'une chaîne de cinq sauts doit vérifier cryptographiquement l'intégralité du chemin qui remonte jusqu'à l'humain d'origine, pas seulement le dernier agent qui l'a appelé. Cela exige une atténuation de la portée : restreindre la permission de façon prouvable à chaque étape. Le papier est rafraîchissant de concret sur les options — OAuth 2.0 Token Exchange pour les montages centralisés en étoile, et les capability tokens comme Biscuits et Macaroons pour les montages décentralisés, où un détenteur peut frapper une version plus restreinte d'un jeton hors ligne, l'autorité étant inscrite dans l'identifiant lui-même sous un modèle de capacités d'objet. C'est la partie que la plupart des systèmes d'agents en production ratent en 2026. Ils font tourner chaque agent à un seul niveau d'autorisation, avec tous les outils, et appellent « frontière » un prompt système.
Et le problème qui plane au-dessus de tout cela : la révocation, que les auteurs qualifient sans détour de « problème critique, et largement non résolu ». Les jetons atténués hors ligne l'aggravent — révoquez le parent et il n'existe aucun moyen propre d'atteindre les enfants déjà délégués en aval. Les réponses émergentes sont honnêtes mais partielles : le Shared Signals Framework pour propager les événements de révocation en quasi-temps réel, et le geste pragmatique consistant à borner un identifiant par un nombre d'exécutions, pour qu'une révocation tardive plafonne malgré tout les dégâts.
La gouvernance doit passer du clic au code
Dans mon premier post de cette série, j'ai soutenu que la supervision humaine dans la boucle s'effondre à l'échelle en fatigue de consentement. La réponse du papier est celle que je donnerais, et elle est structurelle. On ne corrige pas la fatigue de consentement en demandant aux gens de prêter plus attention. On sort la gouvernance du clic et on la met dans le code.
Trois schémas qu'il expose, par sophistication croissante. Policy-as-code : un administrateur définit une fois l'enveloppe opérationnelle de l'agent — plafonds budgétaires, niveaux de données, vélocité d'appels — et le système l'applique de façon programmatique. Autorisation par intention : l'utilisateur approuve une intention de haut niveau en langage naturel (« réserve mes déplacements pour la conférence »), et le système la compile en un bouquet de permissions au moindre privilège. Autorisation dynamique fondée sur le risque : les actions de routine passent automatiquement, et seule une requête anormale déclenche une approbation humaine hors bande via CIBA. L'idée qui relie le tout est un hybride — se servir du modèle pour traduire l'intention humaine, floue, en une politique formelle et lisible par la machine, puis laisser le système déterministe tenir la ligne même si l'agent lit l'instruction de travers. L'humain approuve quelque chose d'intuitif ; le runtime applique quelque chose d'exact. C'est dans cet écart, entre l'intuitif et l'exact, que vit réellement la sécurité.
Et puis il y a l'argent
La section dont je n'attendais pas qu'elle soit la plus éclairante, c'est l'économique. La vraie utilité d'un agent apparaît quand il peut transiger — acheter de la donnée, payer une API, régler un achat — et tout le modèle de sécurité du commerce en ligne tient pour acquis qu'un humain est présent au point de vente. Retirez l'humain et il vous faut de nouveaux rails.
Le papier cartographie trois couches déjà en train de se former. FAPI, le profil de haute sécurité de l'OpenID Foundation, durcit OAuth pour les actions financières irréversibles avec des jetons liés à l'émetteur. L'Agent Payments Protocol de Google introduit le Mandate — un artefact d'intention signé cryptographiquement, scindé en un Intent Mandate (« voici ce que j'ai autorisé ») et un Cart Mandate (« voici l'achat précis qui y répondait »), de sorte qu'une piste d'audit non répudiable existe pour une transaction autonome. Et KYAPay propose un processus « Know Your Agent » qui, selon les termes du papier, étend « la vérification d'identité traditionnelle KYC/KYB à l'agent lui-même », émettant un jeton qui regroupe identité vérifiée et informations de paiement. Arrêtez-vous sur cette formule — Know Your Agent. Le marché tend déjà vers une responsabilité à la forme du KYC pour les agents. Sauf qu'il ne tend pas vers elle d'une manière qui protège l'humain derrière l'agent. Gardez cette pensée en réserve pour moi.
Le seul nœud que le papier laisse ouvert
Pour toute son envergure, le document ne cesse de revenir à une tension unique qu'il est trop honnête pour résoudre, et c'est celle autour de laquelle je tourne depuis une semaine.
« La traçabilité même qu'exigent les audits permet un pistage inter-domaines qui peut composer des profils comportementaux complets et potentiellement sensibles. Des mécanismes de divulgation sélective — exploitant des techniques cryptographiques comme les preuves à divulgation nulle de connaissance et les accréditations anonymes — offrent une voie de sortie… mais intégrer ces techniques aux standards d'identité et aux exigences réglementaires existants reste un défi considérable. »
La voilà encore, énoncée par les gens les mieux placés pour le savoir. Pour rendre un agent responsable, vous lui attachez une identité ; attachez-lui une identité et vous bâtissez de la surveillance. Les preuves à divulgation nulle de connaissance et les accréditations anonymes sont nommées comme le passage à travers le mur — prouver « un humain réel et responsable se tient derrière moi » sans révéler lequel —, puis nommées, tout aussi clairement, comme pas encore intégrées aux standards et aux régulateurs qui les rendraient réelles.
La conclusion même du papier cadre le travail de cette décennie comme trois bascules : la vraie délégation plutôt que l'usurpation, une gouvernance qui passe à l'échelle plutôt que la fatigue de consentement, et une confiance interopérable plutôt que des silos propriétaires. J'y ajouterais la phrase que les auteurs glissent presque au passage, parce que c'est la contrainte qui écarte les réponses paresseuses : quoi que nous bâtissions, « cela ne doit pas devenir un jardin clos ». Le mouvement bien financé, ici, c'est un service centralisé d'identité d'agents que vous louez. Le papier dit, à juste titre, que l'économie ouverte d'agents ne peut pas tourner sur la permission d'une seule entreprise.
Voilà donc la carte : les fondations sont réelles, les problèmes futurs sont nommés avec une franchise brute, et le plus dur d'entre eux — la responsabilité et la vie privée en même temps, sans gardien central — est laissé comme un défi ouvert, avec une direction cryptographique et aucune route bâtie.
J'ai justement bâti cette route. Dans le troisième et dernier post, j'esquisserai, à haut niveau, comment je démonterais ce nœud ouvert — comment un agent peut prouver qu'il y a derrière lui un humain réel, responsable et vérifié, sans que personne n'apprenne jamais qui. Pas comme une revue des idées des autres, cette fois. Comme l'approche à laquelle je consacre mes nuits — et que je poursuis depuis 2014, quand j'ai commencé à construire avec des identités numériques.
Source : OpenID Foundation, Identity Management for Agentic AI (éditeur principal Tobin South, avec l'AI Identity Management Community Group et la Loyal Agents Initiative de Stanford), octobre 2025. Tout le texte cité provient du papier.
