Au-delà de l'écran de consentement : la confiance agent-à-agent et agent-à-application
Cet article fait partie de la série Les défis d’authentification et d’autorisation de l’IA agentique.
Les deux articles précédents de cette série traitaient de la délégation et du consentement à l’intérieur d’une frontière que vous contrôlez largement — vos propres API, vos propres utilisateurs, vos propres flux d’approbation. Celui-ci traite de ce qui se passe au moment où un agent doit accéder en dehors de cette frontière : vers une autre application SaaS, ou vers l’agent d’une tout autre organisation. C’est la faille de chaîne de confiance, et c’est celle qui passe le plus mal à l’échelle si l’on tente de la résoudre avec les outils conçus pour une seule application.
Pourquoi le consentement par application ne survit pas à l’arrivée des agents
L’écran de consentement OAuth classique — « L’application X souhaite accéder à votre Google Agenda, cliquez pour autoriser » — fonctionne parce qu’un humain est présent, décidant une fois, à propos d’une connexion précise. Il a été conçu pour un monde où une personne connecte une poignée d’applications à une poignée de services sur la durée de vie d’un compte. Il n’a pas été conçu pour un monde où un agent, agissant pour le compte d’une entreprise, pourrait avoir besoin d’accéder à des dizaines de systèmes internes et partenaires, en ajoutant potentiellement de nouveaux à mesure que ses capacités s’étendent, avec une équipe IT ou sécurité qui n’a aucune visibilité sur les connexions existantes, qui les a approuvées, ni sous quelle politique.
Deux modes de défaillance apparaissent rapidement dès qu’on tente de forcer l’accès des agents dans ce modèle. Le premier est la fatigue de consentement à l’échelle : les employés cliquent sur « autoriser » sur des invites qu’ils n’évaluent pas pleinement, car elles sont trop nombreuses, ce qui annule l’intérêt même de l’existence d’une étape de consentement. Le second, plus lourd de conséquences : des employés individuels se retrouvent avec l’autorité pratique de connecter un agent d’entreprise au service tiers de leur choix, un clic à la fois, entièrement en dehors de la politique d’accès que l’organisation entend réellement faire respecter. C’est le shadow IT, réincarné pour les agents, et il est considérablement plus difficile à détecter que sa version « extension de navigateur », car « l’installation » n’est souvent que le fonctionnement normal d’un agent décidant d’accéder à un nouvel outil.
Le pattern : laisser le fournisseur d’identité arbitrer, comme il le fait déjà pour le SSO
La correction structurelle reprend quelque chose que les entreprises font déjà confiance pour un problème différent : le single sign-on. Quand un employé se connecte à une douzaine d’applications différentes via un seul fournisseur d’identité, aucune de ces applications ne décide individuellement de faire confiance à l’employé — elles font confiance à l’assertion de l’IdP selon laquelle l’employé est bien celui qu’il prétend être, et l’IdP applique la politique qui régit, en amont, quels employés peuvent accéder à quelles applications.
L’extension en cours de standardisation pour l’accès agent-à-agent et agent-à-application fait la même chose un niveau plus haut : au lieu que deux applications établissent directement une confiance bilatérale (le modèle OAuth traditionnel de consentement), c’est le fournisseur d’identité d’entreprise qui arbitre la connexion. Mécaniquement : après que l’employé s’est authentifié via SSO, l’application demandeuse (l’agent, ou l’application qui l’héberge) échange son token d’identité existant contre une assertion d’identité cross-domain signée par l’IdP — soumise à la politique d’accès que les administrateurs de l’organisation ont configurée pour cette connexion précise entre applications. Cette assertion est ensuite échangée auprès de l’authorization server de l’application ressource contre un access token scopé et lié à cette audience, que l’application ressource peut valider en s’appuyant sur la même relation de confiance qu’elle entretient déjà avec l’IdP pour le SSO ordinaire.
Le résultat est structurellement différent d’un utilisateur qui clique sur « autoriser » sur un écran de consentement : c’est l’IdP — pas l’employé individuel, ni un accord bilatéral entre deux éditeurs d’applications — qui décide si cette connexion est autorisée à exister, sur la base d’une politique configurée de façon centralisée. Si une connexion n’était jamais censée exister, peu importe le nombre de fois qu’un employé tente de l’autoriser ; l’IdP ne délivrera tout simplement pas l’assertion.
Ce mécanisme s’appuie directement sur le token exchange (RFC 8693) et l’assertion JWT bearer (RFC 7523) évoqués dans l’article précédent, étendus au-delà d’une frontière de domaine de sécurité plutôt qu’à l’intérieur des propres API d’une organisation. La distinction compte : le token exchange ordinaire suppose qu’on rescope l’accès à l’intérieur d’une frontière qu’on contrôle de bout en bout. Ce pattern suppose que l’application demandeuse et l’application ressource appartiennent entièrement à des organisations ou des éditeurs différents, et formalise l’IdP comme arbitre entre les deux.
Où en est ce standard, honnêtement
Cela vaut la peine d’être dit clairement plutôt qu’édulcoré : la spécification derrière ce pattern — le grant d’assertion d’identité qui étend la confiance du SSO à l’accès API cross-domain — est, à l’heure où nous écrivons, un draft IETF actif, pas une RFC ratifiée. L’élan derrière elle s’est accéléré spécifiquement à cause des cas d’usage agentiques (un agent ayant besoin d’accéder à l’API d’un partenaire pour le compte d’un utilisateur est une version bien plus urgente d’un problème qui existe pour l’intégration SaaS-à-SaaS depuis des années), et plusieurs éditeurs d’identité l’implémentent déjà sur la base du draft actuel. C’est un pari raisonnable, pas un fait acquis — attendez-vous à ce que les détails évoluent quelque peu avant la standardisation finale, et considérez toute implémentation spécifique que vous évaluez aujourd’hui comme suivant une cible mouvante.
Où cela se situe par rapport au reste de la série
Il vaut la peine d’être précis sur ce à quoi ce pattern sert, car il est facile de s’en emparer dans la mauvaise situation. Il résout le problème de l’accès gouverné, sans consentement permanent, entre des applications appartenant à des domaines de confiance différents — un agent interne accédant à l’API d’un partenaire, ou un agent géré par l’entreprise accédant à un outil SaaS que le département IT a approuvé mais auquel il ne veut pas que chaque employé consente individuellement. Ce n’est pas un remplacement du pattern de token exchange de l’article précédent, qui continue de gouverner la délégation à l’intérieur d’une frontière que vous contrôlez ; et cela ne supprime pas le besoin du consentement asynchrone approuvé par un humain vu dans l’article d’avant, pour les actions suffisamment précises et sensibles pour justifier l’accord explicite d’une personne, quelle que soit l’application impliquée.
Dans une architecture multi-agents, cette faille se démultiplie : l’agent A peut avoir besoin d’accéder à l’agent B, lui-même hébergé par une équipe ou une organisation entièrement différente, qui a ensuite besoin d’accéder à une ressource pour le compte de l’utilisateur d’origine. Chacun de ces sauts est un endroit où « cette connexion existe-t-elle parce que la politique l’autorise » a besoin d’une vraie réponse — pas « parce que quelqu’un, à un moment donné, a cliqué sur autoriser ».
Recommandations de conception
Centralisez la décision de savoir quelles applications et quels agents peuvent accéder à quelles autres applications et agents. C’est une question de politique pour qui administre votre fournisseur d’identité, pas une décision qui devrait pouvoir être déléguée à des employés individuels, un clic de consentement à la fois. Si votre organisation ne peut pas actuellement produire une liste des connexions agent-à-application autorisées, c’est la faille à combler avant d’adopter ce pattern, pas après.
Gardez les assertions de courte durée et liées à une audience précise. Une assertion d’identité cross-domain devrait être scopée étroitement à l’application ressource précise à laquelle elle est destinée, et ne pas survivre au-delà du besoin précis qui l’a justifiée — la même philosophie de courte durée et de scope étroit que dans l’article sur le token exchange, opérant simplement à travers une frontière organisationnelle plutôt qu’à l’intérieur d’une seule.
Ne considérez pas cela comme une suppression du consentement utilisateur — cela déplace où la décision est prise. Un employé peut encore avoir besoin d’être celui qui initie une connexion précise ou approuve l’accès d’un agent à son propre compte dans une application. Ce qui change, c’est que l’autorité permanente déterminant si cette connexion est autorisée à exister du tout repose sur la politique d’entreprise, pas sur ce que l’employé a cliqué au passage.
Traitez le statut de draft comme un risque de premier ordre, pas comme une note de bas de page. Si vous construisez aujourd’hui sur ce pattern, vous construisez sur une spécification qui bouge encore. Isolez cette dépendance afin que, lorsque les détails du draft évolueront, le rayon d’impact de la mise à jour de votre implémentation reste contenu — pas réparti sur chaque intégration d’agent que vous avez mise en production.
Prochain article de la série : Sécuriser la nouvelle surface d’attaque : l’autorisation pour les agents utilisateurs d’outils et MCP, qui passe de quelles applications un agent est autorisé à atteindre vers ce qu’est réellement un outil, du point de vue de l’autorisation, au moment où on en confie un à un agent.