Les défis d'authentification et d'autorisation de l'IA agentique
Depuis vingt ans, la gestion des identités et des accès repose sur deux acteurs. Un humain, authentifié via quelque chose comme OpenID Connect, derrière un navigateur et une session. Et une machine — un service backend, un batch, un script cron — authentifiée via un grant client credentials, porteuse d’un ensemble statique de permissions qu’elle n’a jamais à justifier.
L’IA agentique ne rentre dans aucune de ces deux cases, et faire comme si c’était le cas est à l’origine de la plupart des problèmes de sécurité actuels.
Un agent peut agir de façon autonome, sans aucun humain dans la boucle. Il peut agir comme un délégué, exécutant une tâche pour le compte d’une personne précise, avec l’autorité de cette personne mais sans sa session littérale. Et il peut être un maillon d’une chaîne — appelant un outil, qui appelle un autre service, qui transmet la main à un autre agent — parfois les trois à la fois au sein d’une seule requête utilisateur. Rien de tout cela ne correspond proprement à « humain » ou « machine ». C’est une troisième catégorie, et l’infrastructure d’identité que la plupart des équipes exploitent aujourd’hui n’a jamais été conçue pour la modéliser.
Cet article sert de carte pour le reste de la série. Chaque section ci-dessous nomme un endroit précis où le modèle à deux acteurs se fissure, et renvoie vers l’article qui approfondit le sujet.
Ce qui change réellement par rapport à l’authentification applicative classique
Avant d’entrer dans le détail des différentes failles, il vaut la peine d’être précis sur ce qui est véritablement nouveau ici, car beaucoup de contenus sur la « sécurité des agents IA » exagèrent la nouveauté. Les protocoles sous-jacents — OAuth 2.0, OpenID Connect, JSON Web Tokens — ne sont pas remplacés. Ce qui change, c’est la forme des problèmes qu’on leur demande de résoudre :
Permission permanente contre permission scopée à la tâche. Une session humaine authentifiée porte généralement un ensemble de permissions large et relativement statique pendant toute la durée de la session. Un agent exécutant une tâche devrait idéalement ne détenir que la tranche étroite de permission nécessaire à cette tâche précise, pour la durée la plus courte possible, et rien de plus une fois la tâche terminée. La plupart des systèmes existants n’ont, par défaut, aucun concept de permission aussi éphémère et aussi étroite.
Action asynchrone et longue durée contre requête/réponse synchrone. Un flux OAuth basé navigateur suppose qu’un humain est présent, devant un écran, à l’instant présent, pour cliquer sur « autoriser ». Un agent peut décider, trois étapes dans un workflow, qu’il a besoin d’une permission élevée pour une action donnée — et l’humain dont il a besoin de l’approbation n’est peut-être en train de regarder rien du tout à ce moment-là.
Chaînes de délégation contre un seul saut. La délégation d’accès classique est un saut unique : l’application A agit pour l’utilisateur U auprès de l’API B. Les systèmes agentiques ont couramment plusieurs sauts — un agent appelle un outil, lui-même adossé à un autre service, qui peut appeler un second agent. Chaque saut doit préserver à qui appartient réellement l’autorité exercée, sous peine de perdre, quelques sauts plus loin, la capacité de répondre à « pourquoi cela a-t-il été autorisé ».
L’attribution. Quand quelque chose tourne mal, « qui a fait ça » a désormais au moins trois réponses possibles : l’humain qui a initié l’action, l’agent qui l’a exécutée, et l’autorisation précise sous laquelle il a agi. Confondre deux de ces éléments est précisément ce qui rend les journaux d’audit inutiles au moment où on en a le plus besoin.
Les sept failles
Tout ce qui compose cette série se rattache à l’un de ces sept endroits où le modèle à deux acteurs arrive en bout de course.
La faille d’identité. L’agent est-il son propre principal — une entité distincte et identifiable, avec ses propres identifiants et son propre journal d’audit — ou emprunte-t-il simplement la session d’un humain ou les permissions statiques d’un compte de service générique ? Les deux réponses faciles (le traiter comme l’utilisateur, ou le traiter comme n’importe quel autre service backend) font perdre quelque chose d’important : soit le scoping en moindre privilège, soit une attribution propre. → Identité de l’agent : pourquoi votre agent IA doit être un principal à part entière
La faille de délégation. Une fois l’agent constitué en principal distinct, comment prouve-t-il — à un resource server qui ne l’a jamais vu — qu’il agit pour un utilisateur précis, avec un scope précis, et non qu’il présente simplement un credential volé ou trop large ? C’est un problème résolu en théorie (des patterns de token exchange existent précisément pour cela) et souvent mal implémenté en pratique. → Bien déléguer : le Token Exchange et le pattern On-Behalf-Of
La faille de consentement. Certaines actions sont suffisamment sensibles pour mériter l’approbation spécifique d’un humain, mais les agents agissent souvent à des moments où aucun humain ne regarde un écran. La solution naïve — une case « autoriser cet agent à agir » large et cochée une fois pour toutes — entraîne les utilisateurs à cliquer oui, et vide le mécanisme de son sens. → Human-in-the-loop, automatisé : l’autorisation asynchrone pour les actions d’agent à fort enjeu
La faille de chaîne de confiance. Les écrans de consentement OAuth par application fonctionnent quand un humain est présent pour accorder chaque connexion individuellement. Ils cessent de tenir la charge dès que des agents commencent à accéder à d’autres applications, ou à d’autres agents, pour le compte d’une entreprise — il devient nécessaire que l’IdP arbitre cette confiance, de la même façon qu’il arbitre déjà le SSO. → Au-delà de l’écran de consentement : la confiance agent-à-agent et agent-à-application
La faille de surface d’outils. Donner un outil à un agent revient fonctionnellement à mettre en production un nouveau client API — avec toutes les obligations d’authentification et d’autorisation que cela implique. Une bonne partie des déploiements d’agents en phase initiale sautent complètement cette étape, sous prétexte que « ce n’est qu’un appel d’outil ». Ce n’est pas qu’un appel d’outil ; c’est un nouveau point d’entrée. → Sécuriser la nouvelle surface d’attaque : l’autorisation pour les agents utilisateurs d’outils et MCP
La faille de scoping des données. Les scopes et les rôles répondent à « cet agent peut-il appeler cette API ». Ils ne répondent pas à « cet agent peut-il récupérer cet enregistrement précis, pour cet utilisateur précis, maintenant ». C’est précisément cette seconde question qui compte pour le retrieval-augmented generation, où le mauvais document devient silencieusement partie intégrante de la réponse d’un modèle. → Le moindre privilège au niveau des données : l’autorisation relationnelle pour le RAG
La faille de gouvernance. Une fois les six points précédents correctement traités sur le moment, il reste la question de l’après : peut-on auditer ce qui s’est passé, révoquer une autorisation instantanément et voir cette révocation réellement s’appliquer, et prouver — pas seulement affirmer — ce qu’un humain a réellement autorisé par rapport à ce que l’agent a exécuté en son nom ? → Gouverner les systèmes autonomes : auditabilité, non-répudiation et révocation
Le schéma ci-dessous constitue l’épine visuelle de la série : trois acteurs (humain, agent, ressource), plus le quatrième nœud — une autre application ou un autre agent — qui apparaît dès que les chaînes de délégation s’allongent. Chaque flèche est annotée avec les numéros des failles qui s’y appliquent. Nous réutiliserons et recadrerons ce même schéma dans les articles individuels, afin que la série se lise comme une architecture cohérente plutôt que comme sept essais déconnectés.
Où en sont réellement les standards aujourd’hui
Il importe d’être honnête sur le niveau de maturité ici, car une série comme celle-ci vieillit mal si elle surestime ce qui est déjà stabilisé.
OAuth 2.1 et OpenID Connect restent le socle de tout ce qui est abordé dans cette série — rien ici ne propose de les remplacer. Plusieurs des extensions qui rendent possible la délégation aux agents sont matures et déjà déployées en production : les patterns de token exchange pour l’accès on-behalf-of, le Client-Initiated Backchannel Authentication pour l’approbation asynchrone, et les Rich Authorization Requests pour porter des demandes de permission structurées et précises plutôt qu’une simple chaîne de scope.
Au moins un élément central à la faille de chaîne de confiance agent-à-agent — le grant d’assertion d’identité qui étend la confiance du SSO à l’accès API — est, à l’heure où nous écrivons, encore un draft IETF actif, pas une RFC ratifiée. Plusieurs éditeurs l’implémentent déjà, ce qui constitue un pari raisonnable sur la direction que prend le standard, mais la standardisation n’est pas terminée. Nous le signalerons explicitement dans l’article concerné, et nous reviendrons sur cette série à mesure que le draft progresse.
Comment utiliser cette série
Ce n’est pas une checklist où il faudrait implémenter les sept patterns dès le premier jour, pour chaque agent mis en production. Les failles qui comptent réellement pour vous dépendent fortement du type d’agent que vous construisez :
- Vous construisez un assistant orienté client qui appelle quelques API first-party pour le compte d’un utilisateur connecté ? Commencez par l’article sur la délégation et celui sur la surface d’outils.
- Vous construisez un agent autonome en arrière-plan, sans aucun utilisateur dans la boucle ? Commencez par l’article sur l’identité — vous devez décider de quel type de principal il s’agit avant que le reste ait un sens.
- Vous construisez un workflow multi-agents qui traverse plusieurs systèmes internes ou partenaires ? Commencez par l’article sur la chaîne de confiance ; c’est de là que proviennent la plupart des incidents réels de cette catégorie.
- Vous construisez quelque chose qui touche à un pipeline de retrieval sur des documents à niveaux d’accès mixtes ? Commencez par l’article sur le scoping des données — c’est la faille la plus souvent découverte après une fuite, pas avant.
Où que vous commenciez, l’article sur la gouvernance mérite d’être lu quel que soit l’agent que vous construisez. C’est celui qui détermine si, dans six mois, vous serez capable de répondre à « que s’est-il passé et pourquoi » quand quelqu’un posera la question.
Conclusion
Rien de tout cela n’exige d’inventer un nouveau théâtre de sécurité spécifique à l’IA. Cela exige d’appliquer une discipline de gestion des identités et des accès vieille de plusieurs décennies — moindre privilège, délégation explicite et prouvable, auditabilité — à une forme de système qui n’existait tout simplement pas il y a cinq ans. Les protocoles existent déjà, pour l’essentiel. La faille se situe dans la reconnaissance des endroits où les anciennes hypothèses cessent silencieusement de tenir, et c’est ce que le reste de cette série va décortiquer, une faille à la fois.