Comment gérer l'authentification et l'autorisation des agents IA multi-utilisateurs en 2026 (OAuth 2.1, OIDC et accès délégué)

TL;DR : authentification et autorisation des agents IA multi-utilisateurs en 2026

Faire passer des agents IA de démos desktop mono-utilisateur à la production enterprise impose de résoudre un problème d’ingénierie redoutable : l’autorisation déléguée multi-utilisateurs et multi-systèmes.

Les architectes sécurité et les ingénieurs IA senior gèrent désormais des agents qui exécutent des workflows complexes sur des infrastructures critiques pour le compte de milliers d’utilisateurs simultanés.

Le principe de conception central est non négociable : toute action d’un agent doit être traitée comme un accès délégué de l’utilisateur, jamais comme un accès propre et global de l’agent. Toute la stack d’autorisation découle de cette distinction. Neuf capacités, deux identités, une règle d’intersection stricte.

Ce guide explique comment combiner OpenID Connect, OAuth 2.1 et un runtime MCP comme Arcade.dev pour prévenir les abus d’outils, les fuites de données et les excès d’agentivité. Il s’adresse aux responsables IAM, aux architectes sécurité et aux ingénieurs IA qui ont besoin des exigences d’infrastructure précises pour déployer des agents multi-utilisateurs en production en toute sécurité.

Modèle de menace pour les agents IA multi-utilisateurs : injection de prompt, abus d’outils et confused deputy

Impossible de concevoir une autorisation sécurisée sans définir le modèle de menace au préalable. Pour les grands modèles de langage, le vecteur d’attaque le plus dangereux va de l’injection de prompt directement à l’abus d’outils.

Si un agent enterprise hérite d’un accès administrateur global à un système backend, un seul document RAG empoisonné ou un prompt malveillant peut le transformer en arme. Un attaquant ordonne au modèle de scanner une boîte mail, de résumer des données financières sensibles et d’exfiltrer la charge utile via un appel d’outil externe. Toute la chaîne d’exfiltration se complète sans aucun humain dans la boucle.

L’Open Web Application Security Project met en évidence ces vulnérabilités dans ses recommandations actualisées, citant l’injection de prompt et l’excès d’agentivité comme risques majeurs menant directement au problème du confused deputy.

Dans une attaque de type confused deputy, une application est manipulée pour détourner l’autorité qu’elle a héritée.

Il existe une deuxième catégorie d’attaque qui cible le flux d’autorisation lui-même. Un attaquant capable d’intercepter ou de deviner l’identifiant d’une autorisation OAuth en attente peut rediriger l’étape de consentement vers son propre navigateur, capturant ainsi le grant de l’utilisateur ou injectant dans l’agent des identifiants qu’il ne devrait pas posséder. Traiter chaque première autorisation d’outil comme une étape cryptographiquement liée à un utilisateur applicatif vérifié est la seule défense durable.

Le modèle à deux identités pour l’autorisation des agents

Les équipes d’ingénierie commettent généralement l’une de deux erreurs lors de la conception de l’autorisation des agents. Donner à l’agent sa propre identité, et un stagiaire peut contourner ses permissions via l’agent. Hériter de l’accès complet de l’utilisateur, et une seule injection de prompt se propage à travers tous les systèmes connectés.

La bonne réponse, c’est l’intersection : ce que cet agent est autorisé à faire ET ce que cet utilisateur est autorisé à faire, évalué par action, au moment de l’exécution.

Une autorisation efficace dans les systèmes agentiques exige que chaque requête transporte deux couches d’identité :

• La clé au niveau projet (l’application agent) : L’identité de charge de travail qui effectue l’appel. Enregistrée comme client OAuth, limitée à l’application exécutant la logique de l’agent.
• L’identité au niveau utilisateur (au nom de qui l’action est effectuée) : La personne réelle qui demande l’action, authentifiée via un protocole comme OpenID Connect, et représentée dans la requête comme un sujet délégué.

Le runtime évalue ces deux identités par rapport à un contexte d’exécution délégué : un lien borné et de courte durée qui rattache un utilisateur précis à un agent précis pour une tâche précise. Ce contexte n’est pas une troisième identité. C’est le tuple de claims (utilisateur, agent, scopes, audience, tenant, ID de tâche, expiration) que le runtime évalue à chaque appel d’outil.

Ce modèle applique la règle d’intersection des identités, fondement de la sécurité des agents modernes.

L’autorité effective d’un agent doit toujours être calculée comme la stricte intersection de ses permissions de base et des permissions de l’utilisateur humain demandeur. Jamais leur union.

Si un utilisateur ne peut pas supprimer un enregistrement en base de données, l’agent agissant en son nom doit échouer lorsqu’il tente la même action. Peu importe les capacités théoriques maximales de l’agent.

Cette intersection exige une séparation stricte des protocoles. OpenID Connect authentifie l’utilisateur humain pour établir qui interagit avec le système. OAuth 2.1 autorise les appels d’outils spécifiques que l’agent peut effectuer au nom de l’utilisateur.

Confondre ces deux protocoles produit des tokens sur-permissionnés, réutilisés sur des systèmes pour lesquels ils n’ont jamais été prévus, offrant à un agent compromis un accès durable bien au-delà de ce que l’utilisateur a réellement autorisé.

Neuf capacités pour l’auth d’agents IA multi-utilisateurs en production

La spécification d’autorisation propre au Model Context Protocol, fruit d’une collaboration avec Anthropic, Arcade.dev, Microsoft, Okta/Auth0 et d’autres, définit des ressources protégées de style OAuth et la découverte de serveurs d’autorisation, avec liaison d’audience via les Resource Indicators (RFC 8707) et délégation via le Token Exchange (RFC 8693). MCP définit le handshake d’auth ; la couche runtime au-dessus doit toujours gérer le vaulting de tokens, le consentement just-in-time, la vérification des utilisateurs, le RBAC et l’audit. Les neuf capacités ci-dessous comblent cet écart.

Construire une infrastructure d’agents multi-utilisateurs résiliente implique d’évaluer vos systèmes face à cette checklist de capacités 2026. Les unifier prévient les accès non autorisés tout en garantissant une exécution fiable des outils.

Capacité 1 : modéliser l’utilisateur, l’agent et le contexte délégué

Chaque décision d’autorisation dans votre runtime doit évaluer simultanément le triplet utilisateur, agent et contexte.

Si votre plan d’outils backend ne vérifie que la clé API de l’agent, vous n’avez pas modélisé l’utilisateur humain.

Une modélisation déléguée réelle garantit que le serveur de ressources en amont sait exactement quel humain a initié la requête, quel workload l’a orchestrée, et le contexte précis dans lequel la délégation a été accordée.

En pratique, cela signifie que le user_id circule depuis la session authentifiée de votre application vers chaque appel runtime. Un schéma courant : votre IdP (Stytch, Auth0, Okta ou similaire) authentifie l’utilisateur et émet une session, votre application extrait l’identifiant utilisateur de cette session, et votre code transmet cet identifiant explicitement à chaque appel du SDK runtime. Par exemple, getTools({ tools: [...], userId: userEmail }) et tools.execute({ ..., user_id: userEmail }). Le runtime résout ensuite les tokens OAuth vaultés de cet utilisateur spécifique pour le fournisseur et le scope demandés. Sans cette liaison utilisateur explicite à chaque appel, le runtime ne peut pas appliquer la règle d’intersection.

Capacité 2 : séparer l’authentification OpenID Connect de l’autorisation OAuth

Vous devez strictement séparer l’authentification humaine de l’autorisation déléguée de l’agent. OpenID Connect gère la session de connexion initiale. OAuth 2.1 gère l’autorisation des outils qui s’ensuit.

En séparant ces responsabilités, vous évitez la confusion d’identité. Un agent compromis par un prompt malveillant ne peut pas réutiliser les cookies de session humaine pour accéder à des systèmes sans rapport.

Capacité 3 : émettre des tokens d’accès à courte durée de vie, scopés et liés à une audience

Les tokens d’accès des agents doivent respecter les standards cryptographiques les plus stricts pour prévenir le replay de tokens et les mouvements latéraux.

Chaque token d’accès délégué doit porter le contexte d’exécution complet sous forme de claims. Dans un token délégué, le sujet (sub) identifie l’utilisateur humain au nom duquel l’action est effectuée (ex. : user:alice). L’acteur (act) identifie l’agent qui effectue l’appel (ex. : agent:support-copilot). L’audience (aud) lie le token à un serveur de ressources spécifique (ex. : gmail-api), et le scope (scope) accorde une permission précise (ex. : email.draft, pas email.send). L’expiration (exp) est fixée à une fenêtre courte, généralement 5 à 30 minutes. Un claim tenant (ex. : tenant:acme) porte le contexte client ou workspace, et un identifiant de tâche (ex. : task_123) relie l’appel à la tâche ou session utilisateur d’origine.

Cette structure de claims applique la règle d’intersection cryptographiquement : chaque token porte l’utilisateur, l’agent et le contexte d’exécution délimité, et le serveur de ressources valide les trois avant d’honorer la requête.

Votre stack doit appliquer les resource indicators RFC 8707 pour lier les tokens à une audience spécifique, garantissant qu’un token émis pour une API de calendrier ne puisse pas être rejoué contre un CRM.

Utilisez le token exchange RFC 8693 pour échanger en toute sécurité des tokens utilisateur larges contre des tokens d’agent étroitement restreints.

Contraignez les tokens à leur émetteur via la preuve de possession (DPoP) RFC 9449, garantissant que même si un token d’accès est intercepté, les attaquants ne peuvent pas l’utiliser sans la clé privée du client. Le stack doit également prendre en charge RFC 9126 les pushed authorization requests et RFC 9396 les rich authorization requests pour une granularité renforcée et inviolable.

Capacité 4 : vaulter les tokens et automatiser le refresh entre fournisseurs

Un runtime qui gère le stockage et le refresh des tokens par utilisateur et par fournisseur est non négociable pour des agents en production. Gérer le cycle de vie des tokens OAuth pour des milliers d’utilisateurs et des dizaines de fournisseurs est à lui seul un problème d’ingénierie conséquent.

Les tokens d’accès et de refresh doivent être vaultés et chiffrés sur une base strictement par utilisateur et par fournisseur. Votre système doit gérer automatiquement les spécificités de chaque fournisseur en dehors du contexte du modèle de langage.

Par exemple, Google impose une limite glissante de 100 refresh tokens par client, et Microsoft Entra renouvelle les refresh tokens à chaque utilisation avec une fenêtre d’inactivité glissante de 90 jours. Un coffre-fort de tokens dédié doit abstraire cette logique de renouvellement pour l’éviter au développeur d’agents.

Capacité 5 : Imposer des étapes d’approbation pour la lecture, la rédaction et la validation

Les architectes sécurité doivent imposer des flux d’approbation hors bande pour toute action irréversible.

Lire des données ou rédiger des réponses demande peu de friction et peut s’exécuter de façon synchrone. Mais les effets de bord externes (envoyer des e-mails, supprimer des enregistrements, valider du code) doivent déclencher une approbation humaine explicite.

Ces approbations doivent passer par un canal sécurisé hors bande : une app d’authentification d’entreprise, une interface utilisateur séparée ou une plateforme de messagerie directe.

Capacité 6 : Évaluer la politique avant chaque appel d’outil en s’intégrant aux systèmes d’habilitation existants

Ne faites jamais confiance à une requête API directe d’un modèle de langage. Chaque appel d’outil doit transiter par une couche de politique centralisée qui croise l’utilisateur, l’agent, le tenant, l’action, la ressource et la tâche, et l’évaluer en quelques millisecondes pour ne pas alourdir la latence conversationnelle de l’agent.

Ce n’est pas une invitation à déployer un nouveau système de politique. Les entreprises disposent déjà de systèmes d’habilitation et de fournisseurs d’identité comme Okta, Entra, SailPoint, ainsi que leurs propres stores de rôles. Le rôle du runtime : s’y brancher, acquérir des tokens à portée restreinte à la volée, et appliquer les politiques déjà définies, sans les dupliquer dans un nouvel outil.

Open Policy Agent, Cedar, Oso, OpenFGA, WorkOS FGA et les graphes relationnels de style Zanzibar sont utiles comme moteur d’application local. Mais la source de vérité sur qui peut faire quoi doit rester dans vos systèmes d’identité et de gouvernance existants. Un runtime qui vous demande de redéfinir votre modèle d’autorisation dans son propre DSL déplace le problème, il ne le résout pas.

Capacité 7 : Utiliser le consentement et l’autorisation juste-à-temps

Un consentement global lors de l’onboarding viole le principe du moindre privilège.

Optez plutôt pour l’autorisation juste-à-temps. Lorsqu’un agent a besoin d’accéder à un nouveau système ou à un scope non accordé pour répondre à un prompt, le runtime suspend l’exécution. Il présente à l’utilisateur une interface de consentement granulaire et contextuelle, capture le consentement cryptographique, obtient le nouveau token, puis reprend la tâche sans perdre le contexte conversationnel.

La MCP URL Elicitation Specification Enhancement Proposal (SEP), rédigée par Arcade.dev en collaboration avec Anthropic et intégrée dans la spec MCP, standardise la façon dont un runtime d’agent transmet des URL de consentement granulaires et contextuelles à l’utilisateur en cours de tâche.

Capacité 8 : Lier les premiers flux d’authentification à un utilisateur applicatif vérifié

Le consentement granulaire (Capacité 7) n’a de valeur que si le runtime peut confirmer quel utilisateur se trouve devant le clavier lors de la première autorisation OAuth. Sans cette confirmation, un attaquant qui intercepte un flow_id peut rediriger l’étape de consentement vers son propre navigateur et soit détourner l’autorisation dans la session de votre utilisateur, soit capturer la délégation pour son propre compte.

La parade : un vérificateur d’utilisateur côté serveur. Lors de la première autorisation d’un outil, le runtime redirige l’utilisateur vers une route de vérification dans votre app. Votre vérificateur lit le flow_id depuis la query string, récupère l’utilisateur actuellement authentifié depuis la session de votre app (Stytch, Auth0, Okta comme IdP, ou un système d’auth applicatif comme Supabase), puis renvoie ce user_id au runtime via un appel serveur confirm_user signé avec votre clé API.

Si le user_id de votre session correspond au user_id spécifié au lancement du flux, le runtime continue. Sinon, il rejette le flux. Chaque première autorisation est ainsi liée à une identité vérifiée et authentifiée dans votre app, ce qui ferme la surface d’attaque par phishing de flux.

Dans les déploiements multi-utilisateurs en production, c’est non négociable. Les implémentations de référence d’Arcade illustrent ce schéma avec Next.js et Stytch et Next.js et Supabase, et le guide Secure Auth in Production d’Arcade détaille la route de vérification de bout en bout.

Capacité 9 : Générer des journaux d’audit immuables pour chaque action de l’agent

Chaque action d’un agent doit générer un journal d’audit immuable avec une chaîne de traçabilité complète.

Cela implique de capturer l’utilisateur demandeur, l’identité de l’agent, le tenant, l’ID de tâche, l’outil précis invoqué, la ressource accédée, la décision de politique et sa version, le hash du prompt, les références d’entrée, le hash de sortie, le statut d’approbation et l’horodatage exact.

Ces journaux doivent être compatibles OpenTelemetry, fournissant des traces structurées qui s’exportent proprement dans les systèmes SIEM d’entreprise pour une réponse aux incidents immédiate.

L’histoire de l’audit ne se limite pas aux journaux eux-mêmes. Elle porte aussi sur les contrôles qui les produisent. La certification SOC 2 Type 2 valide que les contrôles d’audit, d’accès et de gestion des changements du runtime fonctionnent comme prévu, sous audit indépendant. Traitez la certification comme un seuil minimal à l’achat, et la structure du journal par action comme la capacité produit réelle. Vous avez besoin des deux.

Pourquoi un runtime, pas une gateway : le changement d’architecture derrière l’autorisation multi-utilisateurs

Dans le modèle traditionnel, les utilisateurs interagissent avec des applications, les applications appellent des API, et une gateway s’intercale entre les deux pour router, authentifier et limiter les requêtes en périphérie. Le proxy est le point de contrôle parce qu’il est le point de passage obligé : toutes les requêtes le traversent.

Dans le modèle agentique, cette topologie s’inverse. L’agent est déjà le proxy. Un utilisateur parle à un agent. L’agent raisonne, planifie et appelle des outils en son nom. Il gère déjà la médiation, le routage et l’orchestration. Ajouter une API gateway traditionnelle devant les outils n’ajoute pas un point de contrôle ; ça ajoute un saut redondant qui ne voit pas le contexte d’exécution qui compte vraiment : quel utilisateur, quelle action, quelle permission, à cet instant précis.

C’est pourquoi « MCP gateway » est le mauvais cadre pour le problème d’auth. Un proxy sans état évalue chaque requête isolément. Il ne peut pas savoir qu’une requête est l’étape 3 d’un workflow agent en 6 étapes, exécutée pour un utilisateur précis qui a autorisé un périmètre particulier il y a quelques minutes. Greffer le support MCP sur une API gateway n’est pas un pivot. C’est un patch.

Le point de contrôle dans une architecture agentique, c’est la couche d’exécution où l’outil tourne. C’est là que les credentials sont résolus, les permissions vérifiées, et les actions exécutées pour un utilisateur précis. C’est le runtime. Les neuf capacités évoquées plus haut ne peuvent être appliquées qu’à cet endroit.

La place de chaque couche dans la stack d’auth agentique (IdP, coffre OAuth, moteur de politiques, MCP runtime)

Comprendre le paysage éditeur, c’est classer les plateformes par leur fonction architecturale stricte. Mal situer un outil dans la stack crée des failles d’auth dangereuses.

Le vrai problème, c’est la cohérence à l’échelle. Même avec les bons composants (un IdP, un coffre à tokens, un moteur de politiques), la plupart des stacks n’ont aucun moyen uniforme de les appliquer à chaque agent, chaque utilisateur et chaque système. Chaque équipe assemble sa propre intégration, et deux équipes dans la même entreprise finissent par appliquer la même politique différemment. Le runtime est ce qui rend un modèle d’autorisation unique applicable à tous les agents, sans que chaque équipe reconstruise la plomberie.

Couche architecturale	Exemples d’éditeurs	Fonction principale	Lacune clé pour les agents multi-utilisateurs
Fournisseurs d’identité	Okta, Auth0, Entra, WorkOS et Clerk	Authentifient l’utilisateur dans l’application via OpenID Connect.	Stack d’autorisation agent incomplète. Le support des flux de délégation explicites (RFC 8693, sender-constraining via DPoP) varie fortement et exige souvent de lourdes actions personnalisées. L’audit couvre les événements d’authentification, pas les appels d’outils.
Bibliothèques OAuth et coffres	Authlib, HashiCorp Vault, Doppler	Stockent, chiffrent et gèrent les tokens OAuth bruts.	Pas de moteur de décision contextuel, ni d’évaluation de politiques robuste, ni de logique de refresh multi-provider pour les workflows asynchrones. L’audit capture les opérations sur les tokens, pas le contexte utilisateur, agent et outil derrière chaque appel.
Moteurs de politiques et plateformes FGA	Open Policy Agent, Cedar, Oso (Polar DSL), OpenFGA, WorkOS FGA, style Zanzibar, Sailpoint	Évaluent des politiques d’autorisation fine-grained sur des graphes de relations complexes.	Laissent au développeur le soin de construire le courtage de tokens, les UX de consentement et la connectivité aux outils. L’audit enregistre la décision de politique, pas le contexte d’exécution complet vu par le serveur de ressources.
Frameworks d’agents	LangChain, Mastra, Crew IA	Fournissent une abstraction d’outils pour les workflows d’agents.	Renvoient la charge d’auth dans le code applicatif ; traitent les outils comme des clés dans un fichier dotenv et cassent silencieusement dès qu’un second client s’inscrit. Aucune piste d’audit native pour les actions d’agents.
Gateways MCP et wrappers d’intégration	Composio	Connectent les modèles de langage à des outils externes via des interfaces standardisées.	Conçu pour le prototypage rapide et les agents mono-utilisateur en preuve de concept. Wrapper d’intégration au niveau SDK, pas un runtime. L’OAuth par utilisateur est supporté, mais SSO, OIDC et audit sont limités plutôt que natifs, et l’intersection agent/permissions utilisateur n’est pas appliquée.
MCP runtimes	Arcade.dev	Premier MCP runtime conçu pour l’autorisation agentique. Fournit des permissions par utilisateur post-prompt, une gestion isolée du cycle de vie des tokens (refresh, rotation, mismatch), du courtage de protocole OAuth, de l’application contextuelle des politiques d’accès, et des journaux d’audit immuables par action exportables via OpenTelemetry.	Non applicable. Cette couche unifie explicitement les couches précédentes et comble leurs lacunes opérationnelles.

Architectures de référence pour l’auth agent multi-utilisateurs

Ces capacités n’ont de sens que si vous pouvez les projeter sur des architectures réelles. Les trois patterns ci-dessous montrent comment un MCP runtime applique l’autorisation multi-utilisateurs en production.

Ces patterns supposent le setup multi-utilisateurs canonique : une application agent qui authentifie les utilisateurs via son propre fournisseur d’identité (Stytch, Auth0, Okta ou Entra) et appelle le runtime via son SDK client, en passant le user_id authentifié à chaque appel d’outil. Le runtime est le backend qui courtise OAuth, stocke les tokens par utilisateur et applique les politiques. Pour les intégrations MCP-client comme Copilot, Cursor ou Claude Desktop, on utilise le chemin MCP gateway du runtime, mais la sémantique du runtime reste la même.

Deux flux d’auth distincts s’exécutent dans chaque pattern. L’auth au niveau serveur détermine si l’application agent (un client MCP) peut se connecter au serveur MCP. L’auth au niveau outil détermine si l’utilisateur actuellement authentifié peut invoquer un outil précis sur cette ressource avec ces paramètres, à cet instant. L’auth serveur se produit une fois par connexion client-serveur. L’auth outil s’exécute à chaque appel d’outil : c’est là qu’opèrent le vérificateur d’utilisateur (Capacité 8), le consentement just-in-time via URL Elicitation (Capacité 7) et la règle d’intersection des permissions. Le guide Server-Level vs Tool-Level Authorization détaille cette distinction.

Pattern 1 : agent de productivité interne (Google Workspace)

Flux architectural : Utilisateur humain -> [Fournisseur d’identité OIDC] -> Application agent -> MCP Runtime -> Outils MCP Gmail et Calendar -> Google Workspace

Scénario : Un assistant interne basé sur Claude organise des réunions et résume des e-mails dans un environnement Google Workspace multi-utilisateurs.

Implémentation : L’agent ne doit jamais disposer d’une délégation à l’échelle du domaine. À la place, le runtime MCP orchestre un flux OAuth propre à chaque utilisateur. Il demande les scopes délégués gmail.readonly et gmail.compose, en liant le token obtenu strictement à l’employé concerné.

Lors de la première autorisation, le runtime redirige le navigateur de l’utilisateur vers une route de vérification dans l’application. Celle-ci lit le flow_id, identifie l’utilisateur authentifié depuis la session OIDC et confirme le user_id au runtime. L’autorisation OAuth n’est accordée qu’une fois que le runtime a mis en correspondance le user_id confirmé par le vérificateur et celui qui a initié le flux. Ensuite, le token de l’utilisateur est stocké en coffre par fournisseur et réutilisé lors des appels suivants, sans nouvelle autorisation.

Quand l’agent tente de lire une boîte de réception, l’application transmet le user_id authentifié depuis sa session vers l’appel SDK du runtime. Celui-ci évalue le moteur de politique, récupère le token de cet utilisateur dans le coffre et exécute l’appel.

Si l’agent hallucine ou reçoit un prompt malveillant pour envoyer un e-mail, il demande le scope gmail.send. Le runtime intercepte cette requête non autorisée, suspend l’exécution et déclenche une validation hors bande sur l’appareil de l’utilisateur. Un humain autorise explicitement l’envoi, sinon il n’a pas lieu.

Modèle 2 : agent Slack multi-tenant (isolation par workspace)

Flux architectural : Utilisateur humain -> [Fournisseur d’identité OIDC] -> Application agent -> Runtime MCP -> Outils Slack MCP -> Workspace Slack

Scénario : Une application B2B déploie un agent qui agrège des alertes et effectue des actions d’administration sur plusieurs workspaces Slack clients.

Implémentation : La gestion des accès entre entités distinctes exige une isolation multi-tenant stricte. Le runtime gère les installations OAuth au niveau du workspace, en générant des tokens bot associés à des permissions canal granulaires par utilisateur, comme chat:write et channels:history.

Le runtime utilise les indicateurs de ressource RFC 8707, garantissant que les tokens émis pour l’instance Slack du Tenant A sont mathématiquement liés à l’audience de ce tenant.

Si une attaque par injection tente de forcer l’agent à lire les données du Tenant B avec le contexte du Tenant A, le moteur de politique rejette instantanément ce rejeu de token cross-tenant. Cela prévient toute fuite catastrophique de données entre clients.

Modèle 3 : agent CRM Salesforce (permissions au niveau utilisateur)

Flux architectural : Utilisateur humain -> [Fournisseur d’identité OIDC] -> Application agent -> Runtime MCP -> Outils Salesforce MCP -> Salesforce

Scénario : Un copilote commercial met à jour les opportunités, rédige des e-mails de suivi et interroge l’historique client pour le compte de chaque account executive.

Implémentation : Les règles d’accès aux données Salesforce sont notoirement complexes. Le runtime MCP demande les scopes OAuth api et refresh_token pour appeler Salesforce au nom de l’utilisateur, puis évalue le profil Salesforce et les jeux de permissions de l’account executive à chaque appel d’outil avant d’autoriser l’agent à poursuivre. L’accès au niveau objet (lecture sur Account/Contact, modification sur les transitions de phase d’Opportunity, validation sur la conversion de Lead) est conditionné par les permissions Salesforce existantes de l’utilisateur, et non par les propres credentials de l’agent.

L’implémentation impose une séparation stricte entre la lecture des contacts, la rédaction de notes de réunion et la validation des mises à jour de pipeline.

Grâce à l’autorisation juste-à-temps, si un commercial junior demande à l’agent de modifier une opportunité closed-won sur laquelle il n’a pas les droits, le moteur de politique du runtime bloque l’action à la frontière de l’outil. Il retourne un refus d’accès explicite au modèle de langage, sans exposer les credentials du backend.

Anti-patterns d’auth à éviter en production

Les moteurs de recherche et les audits de sécurité privilégient les systèmes qui éliminent les failles architecturales connues. Si votre infrastructure agent maison repose sur l’un de ces anti-patterns, elle n’est pas prête pour la production enterprise.

• Routage via une clé API unique : Votre backend agent partage une seule clé de compte de service très privilégiée entre tous les utilisateurs. Cela brise l’attribution des identités au niveau des requêtes. Le backend ne peut plus distinguer la requête d’un stagiaire de celle d’un PDG, et une seule injection de prompt hérite du rayon d’explosion maximal sur toute la base utilisateurs.
• Mode dieu avec garde-fous en prompt : L’agent tourne avec des credentials root ou admin, et les équipes s’appuient sur des system prompts du type « ne pas supprimer les données » pour maintenir la sécurité. Les modèles de langage se manipulent aisément via l’injection indirecte : laisser le modèle gérer sa propre autorisation est un échec de sécurité fondamental.
• Consentement global à l’inscription : Forcer les utilisateurs à accorder des scopes OAuth massifs couvrant plusieurs systèmes dès leur onboarding initial. Cela viole le principe du moindre privilège, génère une fatigue de consentement et provisionne des tokens avec des capacités dangereuses bien avant que l’utilisateur en ait besoin.
• Contrôles uniquement côté interface : Les vérifications d’autorisation sont appliquées exclusivement dans l’interface de chat ou le frontend web, laissant le plan d’exécution des outils sans protection. Si un attaquant contourne l’interface de chat et envoie des payloads directement à l’endpoint d’exécution des outils, le système obéit sans vérifier le contexte utilisateur délégué.
• Pas de distinction entre brouillon et validation : Votre agent traite chaque action avec le même niveau d’autorisation, envoyant des e-mails ou effectuant des virements aussi facilement qu’il les rédige. Sans gradient lecture/brouillon/validation ni étape d’approbation hors bande pour les actions irréversibles, une seule injection de prompt provoque des dommages irréparables.
• Pas de piste d’audit immuable : Votre système d’agents ne dispose d’aucun journal d’audit par action, ou s’appuie sur des logs applicatifs modifiables après coup. Sans trace immuable indiquant qui a autorisé quelle action sur quel outil, à quel moment (avec la version de politique, le hash du prompt et le statut d’approbation), impossible de reconstituer un incident de sécurité ni de produire des rapports d’audit pour les régulateurs.

Conclusion : la règle d’autorisation déléguée pour les agents multi-utilisateurs

Passer à des agents IA multi-utilisateurs en production exige de repenser l’architecture de sécurité de fond en comble. Toute la philosophie de l’autorisation des agents se résume à une règle stricte :

Cet agent précis peut effectuer cette action précise sur cette ressource précise, pour cet utilisateur précis, dans ce tenant précis, pour cette tâche précise, pendant une durée strictement limitée.

Si votre infrastructure actuelle ne peut pas appliquer et auditer cryptographiquement cette phrase exacte, du prompt de chat jusqu’à la couche API backend, votre système n’est pas prêt pour une production multi-utilisateurs en 2026.

Une gateway ne peut pas appliquer cette règle. Un runtime, oui.

Avant de vous engager sur un runtime, faites trois choses. Auditez votre mapping d’identité actuel pour vérifier que vos systèmes backend modélisent bien le tuple utilisateur/agent/contexte à chaque appel d’outil. Arrêtez de construire votre propre plomberie OAuth sur mesure. La logique de refresh, les interfaces de consentement just-in-time et le vaulting de tokens multi-tenant sont une dette technique sans valeur différenciante que vos ingénieurs ne devraient pas écrire. Testez agressivement la règle d’intersection en envoyant des prompts malveillants contre vos propres agents pour vérifier que votre moteur de politique les intercepte à la frontière réseau.

Arcade est le runtime MCP conçu pour l’autorisation des agents, gérant OAuth par utilisateur, consentement just-in-time, vaulting de tokens, intersection de politiques et audit immuable comme des capacités natives, non des plugins ajoutés après coup. Les neuf capacités ci-dessus sont unifiées sous un seul plan de contrôle, aux côtés du catalogue d’outils optimisé pour les agents et de la gouvernance du cycle de vie d’Arcade, afin que vos équipes d’ingénierie se concentrent sur la livraison de logique agent à forte valeur ajoutée plutôt que sur une plomberie d’identité fragile.

Questions fréquentes

Quelle est la meilleure approche pour gérer l’authentification et l’autorisation d’agents IA multi-utilisateurs en 2026 ?

Traitez chaque appel d’outil comme un accès délégué à l’utilisateur, pas un accès propre à l’agent. Implémentez un modèle à deux identités (l’application agent et l’utilisateur au nom duquel l’action est effectuée), liez chaque appel à un contexte d’exécution délégué, et appliquez la règle d’intersection via des tokens délégués OAuth 2.1, un moteur de politique devant les outils, des tokens à durée de vie courte et des journaux d’audit immuables.

Qu’est-ce que le modèle à deux identités pour l’autorisation des agents ?

Chaque requête porte deux identités : la clé au niveau projet (l’application agent qui effectue l’appel) et l’identité au niveau utilisateur (la personne au nom de qui l’action est prise). Le runtime évalue ces deux identités par rapport à un contexte d’exécution délégué, un lien borné qui associe un utilisateur spécifique à un agent spécifique pour une tâche spécifique, permettant au backend d’attribuer et de contraindre chaque action.

Qu’est-ce que la « règle d’intersection » et pourquoi est-elle importante ?

Les permissions effectives de l’agent doivent être l’intersection des permissions de l’utilisateur et des capacités autorisées de l’agent. Jamais leur union. Cette règle prévient les défaillances de type « confused deputy », où un prompt injecté amène l’agent à abuser d’un accès système trop large.

Comment utiliser OpenID Connect et OAuth 2.1 ensemble pour les agents ?

Utilisez OpenID Connect pour authentifier l’utilisateur humain (qui il est). Utilisez OAuth 2.1 pour autoriser les appels d’outils de l’agent (ce que l’agent peut faire au nom de l’utilisateur) avec des tokens à portée limitée et liés à une audience.

Comment empêcher l’injection de prompt de se transformer en mauvais usage des outils ?

Ne comptez pas sur les prompts pour la sécurité. Faites transiter chaque appel d’outil par une couche d’application des politiques qui vérifie utilisateur/agent/contexte, portées, tenant et ressource. Utilisez des tokens à courte durée de vie et liés à une audience, pour qu’une injection réussie ne puisse pas pivoter entre les systèmes.

Quelles propriétés de token sont requises pour un accès agent délégué sécurisé ?

Les tokens doivent être à courte durée de vie, à portée limitée et liés à une audience (pour ne pas être rejouables sur d’autres API). Pour une résistance accrue au rejeu, utilisez des tokens liés à l’émetteur (ex. DPoP) : un token volé devient inutilisable sans la clé client.

Comment gérer les refresh tokens OAuth en toute sécurité pour des milliers d’utilisateurs ?

Stockez les tokens dans un coffre chiffré par utilisateur et par fournisseur, et automatisez le refresh/la rotation en dehors du LLM. Cela évite que les secrets ne fuient dans les prompts et que les cas limites de refresh spécifiques au fournisseur ne cassent les workflows des agents.

Quand un agent doit-il exiger une approbation renforcée ou une confirmation humaine ?

Exigez une approbation renforcée pour les actions irréversibles ou à fort impact (ex. envoi d’un e-mail externe, suppression d’enregistrements, commit de code ou transfert de fonds). Laissez l’agent lire et rédiger avec moins de friction, mais bloquez les actions « commit » via un flux de confirmation hors bande.

Qu’est-ce que l’autorisation just-in-time pour les agents IA ?

L’agent demande de nouvelles portées ou un accès système uniquement quand c’est nécessaire pour une tâche précise. Le runtime se met en pause, collecte un consentement granulaire, génère un token à portée réduite, puis reprend. Cela réduit le sur-provisionnement et la fatigue du consentement.

Qu’est-ce que la MCP URL Elicitation ?

URL Elicitation est une Specification Enhancement Proposal rédigée par Arcade.dev avec Anthropic et acceptée dans la spécification du Model Context Protocol. Elle définit comment un runtime MCP renvoie à l’utilisateur une URL de consentement granulaire et contextuelle en cours de tâche, lorsque l’agent a besoin d’une nouvelle portée ou d’un nouveau système, permettant à l’utilisateur d’autoriser la demande hors bande avant que le runtime ne reprenne l’exécution. URL Elicitation est le mécanisme standardisé derrière l’autorisation just-in-time des agents.

Que doit contenir un journal d’audit pour les appels d’outils d’un agent ?

Enregistrez l’identité de l’utilisateur, l’identité de l’agent, le tenant, l’outil/action/ressource, la décision de politique, l’horodatage et un hash du prompt ou de la requête. Rendez les logs immuables et exportables via des formats compatibles OpenTelemetry pour la réponse aux incidents et la conformité.