(1/3) Il n'y a plus personne au clavier

Depuis quelques jours, je réfléchis beaucoup à l'identité — personnelle et publique, humaine et synthétique — et je n'ai rien publié pour me dégager du temps et travailler là-dessus. Je me suis plongé dans un seul problème, à lire des spécifications et des brouillons de protocoles jusque tard, parce que je crois qu'il est sur le point de devenir l'un des problèmes porteurs de notre domaine et que presque personne, en dehors d'une poignée de groupes de normalisation, n'en parle en termes clairs.

Le problème est le suivant : tous les systèmes d'identité que nous avons bâtis depuis trois décennies tiennent pour acquis qu'il y a un humain devant le clavier. Quelqu'un se connecte. Quelqu'un voit un écran de consentement. Quelqu'un clique sur « accepter » et peut, ensuite, être tenu pour responsable de ce qui suit. L'authentification répond à qui es-tu, l'autorisation à que peux-tu faire, et le journal d'audit à qui a fait cela. Les trois reposent sur le même postulat tacite : que derrière chaque action il y a quelqu'un. Les usages qui débordaient de ce « quelqu'un », nous les avons couverts tant bien que mal avec des comptes de service, des artefacts divers, des systèmes de permissions.

Les agents brisent ce postulat et mêlent les actions des comptes de service à celles des utilisateurs réels.

Nous, les ingénieurs seniors, gérons l'IAM, la réponse aux incidents et les guardrails qui se tiennent entre un service et ce qui a le droit de l'appeler. Alors quand je dis que le modèle actuel ne s'étire pas assez pour couvrir les agents autonomes, ce n'est pas une prédiction. C'est que je suis allé voir où sont les coutures, et elles se défont déjà.

Un agent agit avec vos identifiants, indistinct de vous

Commençons par le cas le plus simple, parce qu'il est déjà en production partout. Vous donnez à un assistant l'accès à votre boîte mail, à votre agenda, à votre dépôt. En coulisses, il réutilise vos tokens, vos cookies, votre session. Pour tout service en aval, l'agent, c'est vous. Le récent groupe de travail de l'OpenID Foundation l'a dit nettement : les agents « agissent souvent de manière indistincte des utilisateurs, créant des lacunes de responsabilité et des risques de sécurité ».

C'est le problème du confused deputy, sauf que le délégué raisonne désormais, improvise et continue de tourner des heures après que vous vous êtes levé. Un client traditionnel agit sur « des entrées utilisateur structurées et sans ambiguïté » — un clic sur un bouton, l'envoi d'un formulaire, une concession d'intention claire et auditable. Un agent interprète des instructions non structurées, un fil de courriel transféré, une capture d'écran, et décide quoi faire au moment de l'inférence. Le signal de consentement explicite et lisible par la machine, sur lequel tout l'univers d'OAuth a été construit, a disparu. Reste un logiciel qui agit avec toute votre autorité et rien de votre jugement, et un journal qui ne sait pas vous distinguer l'un de l'autre.

N'importe qui peut forger un client anonyme, et personne ne le signe

Descendez d'une couche, vers la manière dont les agents obtiennent leur identité au départ, et cela empire. Le Model Context Protocol — le standard de connexion sur lequel a convergé l'essentiel du tooling d'agents — s'est appuyé sur Dynamic Client Registration pour rester sans friction : n'importe quel client peut s'enregistrer auprès d'un serveur et obtenir des identifiants, sans paperasse. Commode, et un trou de sécurité par lequel passe une flotte entière. Comme le décrit le papier d'OpenID, « un point de terminaison d'enregistrement public et non authentifié permet de créer des clients sans aucun lien avec un développeur réel… une absence totale de trace écrite », ouvert à « l'abus du point de terminaison (p. ex., DoS par enregistrement massif) ».

La population d'agents explose donc, et une large part en est anonyme par construction. Il n'y a aucune partie responsable à l'autre bout de l'identifiant. Quand l'un de ces clients fait ce qu'il ne devrait pas, vous ne pouvez remonter le fil jusqu'à personne à qui demander des comptes. Les auteurs d'OpenID nomment le résultat avec exactitude : « un trou noir pour la responsabilité et l'analyse forensique ». Cette formule m'est restée en tête une semaine, parce que j'ai contemplé des journaux comme ceux-là. Vous voyez l'action. Vous ne trouvez pas l'acteur.

La délégation casse dès qu'elle franchit la frontière d'une entreprise

À l'intérieur d'une seule entreprise, une équipe plateforme compétente peut masquer une bonne partie de tout cela. Donnez à l'agent une identité de workload, faites-le passer par l'IdP de l'entreprise, bornez ses permissions, et le cas d'un domaine de confiance unique fonctionne raisonnablement bien aujourd'hui. Je veux être juste là-dessus : les briques de base — OAuth 2.1, PKCE, jetons à durée de vie courte et portée limitée — sont solides, et pour un agent qui appelle des outils internes elles suffisent, pour l'instant.

La couture se déchire dès qu'un agent franchit une frontière organisationnelle. Un agent financier qui puise dans votre banque, dans une API de données de marché et dans un bureau de crédit opère dans trois domaines de confiance distincts, et aucun fournisseur d'identité n'est la source de vérité pour les trois. Les cadres d'identité de workload comme SPIFFE/SPIRE reposent sur le contrôle d'une infrastructure partagée et, selon les mots du papier, « ne s'étendent pas naturellement entre organisations ». La vraie délégation exige que le jeton d'accès porte deux identités distinctes — la personne qui a délégué et l'agent qui agit — et que la portée s'atténue à chaque saut quand un agent sous-délègue à un autre. La délégation récursive entre entreprises, avec la piste d'audit intacte de bout en bout, reste en grande partie non résolue. Et l'économie ouverte d'agents inter-organisations vers laquelle tout le monde court vit entièrement de l'autre côté de cette couture.

Mille demandes d'approbation valent zéro approbation

La correction instinctive à tout cela est « gardez un humain dans la boucle : que l'agent demande ». Elle ne survit pas au contact de l'échelle. Un seul agent marketing optimisant un budget peut déclencher des centaines d'actions distinctes en quelques secondes ; une seule personne peut avoir derrière elle des dizaines d'agents prenant des milliers de décisions par jour. L'EU AI Act, à juste titre, impose une « supervision effective » pour les systèmes à haut risque. Mais demander à un humain d'approuver chaque action autonome produit ce que le papier appelle la fatigue de consentement : « un déluge ingérable de demandes d'autorisation » qui « réduit paradoxalement la sécurité », car une personne qui clique sur « accepter » quatre cents fois par jour n'exerce aucun jugement. Elle tamponne sans regarder, et il suffit à un attaquant qu'elle tamponne une fois.

Une supervision qui ne passe pas à l'échelle n'est pas une supervision. C'est du théâtre, avec un mode de défaillance pire que de ne rien avoir, parce qu'elle a l'air d'un contrôle.

Révoquer un agent reste un problème largement non résolu

Supposons maintenant que le pire soit arrivé : un agent est compromis, ou se comporte simplement mal. Vous le voulez dehors. Là aussi, la réponse honnête en 2026 est que nous ne sommes pas encore bons à cela. Les auteurs d'OpenID qualifient la révocation de « problème critique, et largement non résolu », et avec les agents elle se durcit, car une seule identité compromise peut « déclencher une défaillance en cascade à travers tout un écosystème de sous-agents » auxquels elle avait déjà délégué. Révoquer un jeton porteur n'atteint pas le fond d'une chaîne d'autorité déjà transmise.

Et la révocation n'est que le frein d'urgence. L'exigence plus profonde, c'est le déprovisionnement : effacer définitivement l'identité d'un agent et chaque droit qu'il a accumulé, dans tous les systèmes qu'il a touchés, assez vite pour qu'un identifiant compromis et dormant ne puisse être réactivé plus tard. Un agent opère à vitesse machine avec l'autorité déléguée d'un humain et un rayon d'impact démesurément amplifié. La capacité d'en faire disparaître un, de façon vérifiable et partout, n'est pas un confort d'exploitation. C'est une condition préalable pour les laisser tourner, ne serait-ce qu'un peu.

Vous pouvez avoir la responsabilité ou la vie privée, et aujourd'hui il faut choisir

J'ai gardé pour la fin celui qui ne me sort pas de la tête, parce que c'est le nœud dont parle le reste de cette série.

Tout ce qui précède vous pousse vers une seule réponse : pour rendre un agent responsable, attachez-lui une identité réelle et connue. Reliez chaque action de l'agent à une personne nommée et le trou noir se referme. Mais faites cela et vous avez construit autre chose : un système où chaque agent que quiconque exécute est lié pour toujours à son identité réelle, où la traçabilité ajoutée pour les audits « permet un pistage inter-domaines » et laisse n'importe qui composer « des profils comportementaux complets et potentiellement sensibles » de ce que font les agents des gens toute la journée. Vous avez résolu la responsabilité en supprimant la vie privée.

Cela se présente, presque partout, comme un dilemme fermé. Soit les agents sont anonymes et irresponsables, soit ils sont responsables et surveillés. Le papier d'OpenID est inhabituellement honnête en admettant qu'il existe peut-être une troisième porte — des techniques de divulgation sélective, « des preuves à divulgation nulle de connaissance et des accréditations anonymes », qui laissent un agent prouver une affirmation précise sans révéler qui se cache derrière —, mais il est tout aussi honnête en reconnaissant qu'« intégrer ces techniques aux standards d'identité et aux exigences réglementaires existants reste un défi considérable ». Chemin indiqué. Porte pas encore construite.

Prenez du recul sur ces six douleurs et vous verrez qu'elles partagent une même source. Usurpation, clients anonymes, délégation qui casse au passage des frontières, fatigue de consentement, agents que vous ne pouvez révoquer proprement, responsabilité qui vous coûte la vie privée : ce ne sont pas six problèmes distincts. Ce sont six symptômes d'une seule garantie qui manque : que derrière chaque action il y a une personne précise et responsable que vous pouvez retrouver. L'authentification, l'autorisation et le journal d'audit ont tous été bâtis sur cette garantie. Les agents nous ont ôté la capacité de reconnaître clairement qui détient l'autorité.

Un agent peut être autonome — c'est tout l'intérêt d'en construire un —, mais la responsabilité doit demeurer. Un agent n'est pas une personne morale : vous ne pouvez ni le poursuivre, ni l'amender, ni l'asseoir pour lui demander ce qu'il avait en tête. Donc, quel que soit le nombre de couches de délégation empilées entre les deux, la responsabilité doit finir par reposer sur un humain réel et redevable qui a choisi de le déployer. C'est tout le problème de cette série : comment rendre ce lien — cette action remonte à cette personne responsable — prouvable à quiconque doit le vérifier, sans exposer la personne à tous ceux qui n'en ont pas besoin. Un agent qui ne remonte à personne, ce n'est pas de l'autonomie. C'est un risque sans propriétaire, courant à vitesse machine : tout le monde en aval le subit, et personne ne peut être sommé d'en répondre.

Où cela nous mène

Rien de tout cela n'est de la science-fiction, et rien n'est lointain. L'échelle, à elle seule, force la question : les auteurs d'OpenID décrivent la destination comme « un monde peuplé de millions d'acteurs non humains », et les projections des fournisseurs — indicatives, pas parole d'évangile — situent les agents à plusieurs fois le nombre d'utilisateurs humains d'ici quelques mois. Nous sommes sur le point de déployer une population d'acteurs autonomes plus grande que la population humaine, sur une pile d'identité qui tient pour acquis que chacun d'eux est une personne capable de cliquer sur un bouton.

Je suis donc allé chercher la carte la plus claire de ce terrain, et j'en ai trouvé une. Le prochain post de cette série en est une lecture attentive : Identity Management for Agentic AI, de l'OpenID Foundation, l'étude la plus honnête de ces problèmes que j'aie lue, y compris ceux qu'elle reconnaît comme non résolus. Ensuite, j'esquisserai comment je m'attaquerais vraiment au nœud le plus difficile — la responsabilité et la vie privée en même temps —, parce que je n'ai pas fait que lire.

Si vous construisez des systèmes agentiques aujourd'hui et voulez la pièce voisine, celle qui borne ce qu'un agent a le droit de faire une fois que vous savez qui est derrière, j'ai écrit sur la gouvernance vérifiable pour l'IA agentique en début d'année. L'identité, c'est la question du qui ; celle-là, c'est la question du quoi. Il vous faut les deux. Et nous sommes à court des deux.