Identité de l’agent de confiance pour Agentic Enterprise

À mesure que les entreprises adoptent le paradigme agentique, un nouveau défi de sécurité apparaît : Comment l’identité de l’utilisateur final transite-t-elle à travers un réseau d’agents IA autonomes ? Dans les architectures d’API traditionnelles, un utilisateur s’authentifie une fois et l’application appelle des services back-end au nom de l’utilisateur. La chaîne d’identité est courte, bien comprise et généralement gérée dans un seul domaine Trust. Cependant, les architectures Agentic contiennent des chaînes beaucoup plus longues où une seule requête s’étend à travers divers agents, services et serveurs MCP (Model Context Protocol), chacun pouvant franchir des frontières de service, des domaines Trust et même des frontières organisationnelles. Sans stratégie délibérée de propagation de l’identité, les entreprises doivent choisir entre la sécurité et la fonctionnalité, un dilemme auquel aucun architecte ne devrait être confronté.

MuleSoft répond aux complexités de la propagation de l’identité avec sa fonctionnalité Identité de l’agent de confiance. Cette solution utilise une stratégie basée sur une stratégie et gérée par la passerelle pour s’assurer que l’identité de l’utilisateur est conservée dans divers types d’interaction, notamment les protocoles agent à agent (A2A), les appels d’outils MCP et les requêtes d’API REST.En centralisant la gestion de l’identité au niveau de la couche Flex Gateway via des stratégies d’authentification sortantes, les entreprises peuvent sécuriser l’ensemble de leur réseau d’agents sans modifier les services ou les agents back-end.

Ce document présente le défi de la propagation de l’identité en utilisant une série progressive de scénarios, chacun introduisant une complexité supplémentaire. Ensemble, ces scénarios illustrent les raisons pour lesquelles Identité d’agent de confiance est une exigence fondamentale pour tout déploiement d’agent à l’échelle de l’entreprise.

Dans une application classique, le flux d’identité (flux JWT OAuth) est simple : L’utilisateur se connecte, reçoit un jeton et l’application utilise le jeton pour accéder aux ressources back-end. Le jeton est incorporé à l’identité de l’utilisateur, y compris qui il est et ce qu’il est autorisé à faire, et voyage à chaque requête. La chaîne d’appels est courte, généralement un ou deux sauts, et la propagation de l’identité est résolue.

Cependant, les architectures Agentic contiennent des chaînes d’appels beaucoup plus longues où une requête utilisateur unique peut se propager entre divers agents, services back-end et serveurs MCP (Model Context Protocol). Chaque destination de requête constitue un saut séparé. Ces défis – tels que la propagation de l’identité à sauts multiples, les modèles d’autorisation mixtes, les frontières inter-domaines Trust – sont communs dans toute configuration d’API distribuée, mais ce qui est distinct, c’est la façon dont l’écosystème actuel réagit par défaut. Aujourd’hui, le modèle dominant de communication d’agent à agent et d’agent à API repose sur des identifiants clients, des clés API ou des secrets partagés. Cela signifie :

L’identité de l’utilisateur est perdue par défaut. Lorsqu’un agent appelle un serveur MCP ou une API en aval en utilisant des identifiants client, la requête porte l’identité de service de l’agent, pas celle de l’utilisateur. Le service en aval n’a aucun moyen de savoir quel utilisateur a initié l’action, ce qui rend impossible l’autorisation par utilisateur et les pistes d’audit.
Les besoins en autorisations mixtes sont ignorés. Les services en aval ne nécessitent pas tous un contexte utilisateur.Alors que certains gèrent des informations spécifiques aux utilisateurs, telles que des transactions ou des portefeuilles, d’autres fournissent des données accessibles au public ou au niveau du système, telles que des documents de référence ou des tendances du marché.Comme la norme actuelle s’appuie exclusivement sur les identifiants des clients, il n’est pas possible de différencier ces besoins ou de propager sélectivement l’identité des utilisateurs uniquement lorsque nécessaire.
Les frontières de confiance interdomaines ne sont pas résolues. Les agents dans des scénarios B2B et réglementés peuvent avoir besoin d’interagir avec des systèmes régis par des fournisseurs d’identité (IdP) entièrement séparés. Par exemple, un système bancaire externe ne peut pas interpréter un jeton d’authentification unique (SSO) d’entreprise, mais il doit quand même recevoir le consentement et l’intention de l’utilisateur. Le flux des identifiants clients n’offre aucun mécanisme pour cela.

Il en résulte un écart entre l’exigence de l’entreprise en matière d’accès à moindre privilège attribuable à l’utilisateur et la dépendance de l’écosystème actuel à l’authentification au niveau du service sans contexte utilisateur. Pour combler cet écart, il faut adopter une approche délibérée et par paliers de la propagation de l’identité. Pour illustrer ces concepts, les scénarios suivants utilisent Finport, une application de technologie financière fictive, pour fournir des exemples pratiques de ces modèles architecturaux.

Finport est une application Web fictive de gestion de portefeuille Fintech accessible aux consommateurs, soutenue par une architecture agentique. Un courtier Agent (élaboré en utilisant MuleSoft Agent Broker) coordonne plusieurs agents en aval et serveurs MCP pour répondre aux demandes des utilisateurs.

Finport expose trois fonctionnalités principales, chacune avec une exigence d’identité distincte :

“Montre-moi mon portfolio.” L’utilisateur demande ses avoirs personnels et l’historique des transactions. Comme ces données sont spécifiques à l’utilisateur, l’agent de services de portefeuille et le serveur de gestion de portefeuille en aval doivent connaître les données de _l’_utilisateur à renvoyer et vérifier que l’utilisateur est autorisé à y accéder. L’identité de l’utilisateur doit être propagée à chaque saut.
Quelles sont les tendances actuelles du marché?: L’utilisateur demande des données de marché public et les prix des actifs. Les données sont publiques et ne varient pas selon l’utilisateur. Par conséquent, l’agent des données de marché en aval et le serveur MCP Asset Market n’ont pas besoin ou ne s’attendent pas à un jeton limité à l’utilisateur. Les propres identifiants de service du courtier sont suffisants.
« Transférer 5 000 $ à mon compte d’épargne externe. »: L’utilisateur initie un transfert de fonds vers une banque qui utilise un autre fournisseur d’identité (par exemple, Auth0 au lieu de Okta). Le jeton Finport de l’utilisateur n’a aucun sens pour le système de la banque. L’utilisateur doit s’authentifier directement auprès de la banque (en ligne dans la conversation) avant de procéder au transfert.

Chacune de ces fonctionnalités est mappée avec un modèle de propagation de l’identité différent. Les scénarios suivants s’élaborent progressivement à partir d’une base standard (sans agent) à travers chaque modèle distinct, illustrant comment les stratégies sortantes dans Flex Gateway répondent à chaque exigence sans modifier les agents ou les services back-end.

Avant d’introduire des agents, il est essentiel d’établir la base de référence : un utilisateur qui s’authentifie avec une application cliente et accède à un service back-end.

Le flux:

L’utilisateur ouvre Finport et est redirigé vers la page de connexion de l’IdP (par exemple, Okta) .
L’utilisateur s’authentifie (nom d’utilisateur, mot de passe, SSO, authentification multifacteur (MFA) et toute autre exigence).
L’IdP émet un jeton d’accès JWT signé pour l’application Finport.
Finport a maintenant un jeton utilisateur qui représente l’identité de l’utilisateur : qui il est, quels scopes lui ont été accordés et quand le jeton expire. Il peut le présenter à n’importe quel service en aval au nom de cet utilisateur.

Ce que cela établit: Ce processus suit le modèle d’architecture OAuth 2.0 standard. Le jeton utilisateur initial, validé par un fournisseur d’identité de confiance, sert de base essentielle pour toutes les opérations ultérieures. Chaque scénario suivant s’appuie sur ce jeton.

La demande: Une fois authentifié, l’utilisateur initie des actions telles que des transferts de fonds, une analyse de marché ou des examens de portefeuille. Ces requêtes sont traitées via un courtier Agent et peuvent impliquer plusieurs agents en aval ou serveurs MCP. Cela soulève des questions critiques : Comment l’identité de l’utilisateur est-elle conservée dans ces requêtes distribuées ? Que se passe-t-il lorsqu’un service en aval utilise un fournisseur d’identité complètement différent ?

L’utilisateur demande à l’agent Finport de « Me montrer mon portefeuille ». Cette interaction déclenche une chaîne back-end en commençant par Finport Agent Broker, élaboré en utilisant MuleSoft Agent Broker. Le courtier confie la tâche à un Portfolio Service Agent, qui interroge ensuite un Portfolio MCP Server. Le jeton d’authentification initial de l’utilisateur doit maintenant parcourir plusieurs sauts pour accéder aux enregistrements de portefeuille demandés.

La transmission du jeton d’origine enfreint le principe du moindre privilège, tandis que l’utilisation d’un compte de service fait perdre l’identité de l’utilisateur.

L’agent Finport reçoit le jeton de l’utilisateur, mais il ne peut pas simplement le transmettre à l’agent de service de portefeuille, car cela violerait le principe du moindre privilège et ne définirait pas correctement la portée de la requête pour le service en aval. Inversement, l’utilisation d’un compte de service entraîne une perte d’identité totale. L’agent de service de portefeuille et le serveur Portfolio MCP n’auraient aucun moyen de savoir quel portefeuille d’utilisateur renvoyer, et le journal d’audit attribuerait chaque action à l’identité de service du courtier plutôt qu’à l’utilisateur final.

Flex Gateway résout ces complexités de propagation de l’identité de façon transparente avec sa politique d’échange de jetons OAuth 2.0 sortante. Cette solution intercepte les requêtes sortantes à chaque saut dans la chaîne d’appels, échangeant le jeton utilisateur entrant avec l’IdP contre un nouvel identifiant spécifique au service en aval. La stratégie OBO (On-Behalf-Of) prend en charge les protocoles OAuth 2.0 Token Exchange (RFC 8693) et Microsoft Entra ID On-Behalf-Of.

Avantage architectural clé: Tout ce processus est géré par la politique sortante Flex Gateway. Le courtier et les agents ne contiennent aucune logique d’authentification. À la place, ils se concentrent uniquement sur la logique métier alors que la couche passerelle applique automatiquement la propagation de l’identité.

Le flux:

L’utilisateur s’authentifie avec Okta et l’application Finport envoie une requête via Flex Gateway.
Le courtier reçoit le jeton utilisateur validé et détermine que l’agent de service de portefeuille est requis.
La stratégie OBO sortante de Flex Gateway échange le jeton utilisateur avec l’IdP contre un jeton limité à l’Agent de service portefeuille.
L’agent de service de portefeuille reçoit un jeton correctement délimité et appelle le serveur Portfolio MCP.
La passerelle Flex échange de nouveau le jeton, cette fois-ci limité au serveur MCP.
Le serveur Portfolio MCP renvoie les données de portefeuille spécifiques de l’utilisateur.
Un journal d’audit complet existe. Chaque saut est attribuable à l’utilisateur d’origine.

Pourquoi cela compte: Sans échange de jetons OBO, les entreprises doivent choisir entre transférer le jeton d’origine, qui viole le moindre privilège, ou utiliser des comptes de service, qui risquent de perdre l’identité de l’utilisateur. Le modèle OBO élimine ce compromis, car l’identité de l’utilisateur est préservée à chaque saut, chaque jeton est limité à sa cible et les agents eux-mêmes ignorent totalement les mécanismes d’identité.

Les services en aval ne nécessitent pas tous un contexte utilisateur. L’utilisateur demande à l’agent Finport « Quelles sont les tendances actuelles du marché ? » Contrairement à la demande de portefeuille dans le scénario 1, les données sur les tendances du marché sont publiques lorsqu’elles ne varient pas selon l’utilisateur. L’agent des données de marché en aval et le serveur MCP Asset Market n’ont pas besoin ou n’attendent pas de jeton limité à l’utilisateur.

La propagation de jetons utilisateur là où ils ne sont pas nécessaires élargit la surface d’attaque.

Si le courtier de l’agent Finport propageait le jeton de l’utilisateur à l’agent des données du marché en utilisant le modèle OBO du scénario 1, cela fonctionnerait, mais ne serait pas nécessaire. La propagation de jetons utilisateur là où ils ne sont pas nécessaires élargit la surface d’attaque, crée des dépendances inutiles à l’IdP pour les échanges de jetons et enfreint le principe du moindre privilège. L’agent des données de marché doit simplement savoir que la demande provient d’un service autorisé, pas de l’utilisateur qui la demande.

La politique d’identifiants clients OAuth 2.0 sortante de Flex Gateway gère cela de façon transparente. Au lieu d’échanger le jeton de l’utilisateur, la stratégie injecte les propres identifiants de service du courtier via une attribution d’identifiants client dans la requête sortante. L’agent des données de marché en aval reçoit un jeton de niveau de service correctement authentifié dans lequel aucune identité utilisateur n’est propagée, car aucune n’est requise.

Avantage architectural clé: La stratégie de propagation de l’identité n’est pas unique, elle est déterminée par itinéraire en aval en fonction de la nature des données et des exigences du service cible. Les stratégies sortantes de la passerelle Flex permettent de configurer cette fonctionnalité par itinéraire. Le même courtier Agent Finport peut participer aux flux OBO (scénario 1) et S2S sans modification de code. La configuration de la stratégie dans la passerelle de sortie détermine le modèle applicable à l’appel en aval.

Le flux :

L’utilisateur demande à l’agent Finport « Quelles sont les tendances actuelles du marché ? »
Le courtier détermine que l’agent des données du marché est requis pour répondre à la demande.
La stratégie Identifiants clients sortante de Flex Gateway obtient un jeton de niveau de service en utilisant les propres identifiants du courtier (aucun jeton utilisateur n’est échangé ni propagé).
L’agent des données de marché reçoit une demande de service correctement authentifiée et appelle le serveur MCP Asset Market.
Le serveur MCP Asset Market renvoie les données du marché public.
Aucune identité utilisateur n’est présente dans la chaîne par conception, car aucune n’est requise pour ce type de données.

Pourquoi cela compte: L’infrastructure pilotée par la stratégie de Flex Gateway permet aux architectes de sélectionner le modèle d’identité optimal pour chaque interaction, ce qui résout le difficile choix entre la propagation universelle des jetons utilisateur (qui augmente les risques généraux et de sécurité) et l’utilisation globale des comptes de service, qui sacrifie le contexte et la conformité des utilisateurs.

Le scénario d’identité le plus complexe se produit lorsqu’un agent doit interagir avec un système régi par un fournisseur d’identité complètement différent, qui ne reconnaît pas le jeton utilisateur existant.

Le scénario: L’utilisateur de Finport demande à l’agent de Finport de « transférer 5 000 $ à mon compte d’épargne externe ». Cette requête implique deux parcours en aval distincts :

Le chemin de l’agent de service de portefeuille (OBO) pour vérifier les avoirs de l’utilisateur
Le chemin Transaction Agent → Transaction MCP Server → User’s Bank pour exécuter le transfert réel

L’agent des transactions doit interagir avec la banque de l’utilisateur, qui utilise son propre fournisseur d’identité. Le jeton Okta de l’utilisateur de Finport n’a aucun sens pour le système de la banque, car la banque n’a aucune relation Trust avec l’IdP de Finport. Ni le schéma OBO (du scénario 1) ni le schéma S2S (du scénario 2) ne peuvent résoudre ce problème. OBO échange des jetons dans le même fournisseur d’identité, et S2S utilise des identifiants de service qui ne contiennent aucune identité utilisateur. La banque demande à l’utilisateur de s’authentifier directement avec ses propres identifiants bancaires, y compris éventuellement la MFA.

La politique Code d’autorisation en cours A2A sortant dans Flex Gateway utilise un mécanisme de réponse au défi dans la conversation de l’agent. Si un jeton secondaire est manquant lors du contact avec la banque, la politique renvoie un défi d’authentification requise. Ce défi inclut tous les détails nécessaires, tels que les points de terminaison, les étendues et les paramètres PKCE, pour permettre au client d’initier un flux OAuth 2.0 avec le fournisseur de la banque.

L’application Finport affiche ensuite la connexion en ligne de la banque pour l’authentification directe des utilisateurs. Une fois terminé, le client renvoie le jeton dans la requête A2A. La stratégie extrait ce jeton pour le système de la banque et le nettoie du corps du message pour garantir la sécurité.

Avantage architectural clé: La couche de stratégie de passerelle orchestre l’ensemble du processus d’authentification inter-domaines, garantissant que ni le courtier ni les agents n’interagissent jamais avec des identifiants bruts ou n’exigent Knowledge de l’IdP de la banque. En utilisant cette infrastructure de réponse aux défis, les utilisateurs gardent un contrôle total : ils fournissent un consentement explicite à l’authentification avec des systèmes externes, tandis que le jeton résultant est transmis en toute sécurité via la couche de stratégie.

Le flux:

L’utilisateur demande à Finport d’initier un transfert. La requête transite par le courtier.
Le courtier diffuse la requête, faisant appel au module Portfolio (OBO) pour vérifier les avoirs de l’utilisateur et au module Transaction (In-Task) pour exécuter le transfert.
Le chemin Transaction déclenche un défi d’authentification requis par la stratégie En tâche dans Flex Gateway.
Le défi se propage à l’application Finport, qui présente le flux de connexion de la banque à l’utilisateur en ligne.
L’utilisateur s’authentifie auprès de sa banque, y compris la MFA si nécessaire.
Le jeton bancaire est inclus dans la requête A2A suivante. La stratégie l’extrait, la définit dans l’en-tête Authorization et transmet la requête.
Le serveur MCP Transaction reçoit la requête avec le jeton de la banque et exécute le transfert.

Pourquoi c’est important : L’identité inter-domaines est un défi majeur dans les architectures agentiques. Sans authentification dans la tâche, les entreprises doivent soit établir des relations Trust complexes entre chaque IdPin du réseau, soit demander aux utilisateurs de fournir des identifiants bancaires à un agent. Le modèle En tâche résout ce problème en autorisant l’authentification directe des utilisateurs avec des fournisseurs externes. La stratégie gère les mécanismes de jeton tout en gardant les agents découplés des domaines d’identité externes.

Dans les trois scénarios, un seul principe architectural prévaut : La propagation de l’identité est automatiquement appliquée à la couche passerelle, pas dans les agents ou les services. Les agents et les serveurs MCP contiennent une logique d’authentification nulle. Leur rôle est limité au traitement des requêtes authentifiées et au renvoi de résultats, tandis que la couche de stratégie sortante Flex Gateway gère toutes les opérations liées à l’identité.

Cela fonctionne, car les stratégies d’authentification sortantes de Flex Gateway interceptent le trafic au bon endroit : lorsque l’agent prend sa décision d’acheminement, mais avant que la requête n’atteigne le service en aval. La stratégie transforme le jeton, qu’il s’agisse d’un échange OBO, d’une injection d’identifiants client ou d’une réponse au défi en cours de tâche, et transmet une requête correctement authentifiée. Le service en aval ne voit jamais la différence, donc l’agent n’a jamais à s’en soucier. La logique d’authentification est centralisée à la passerelle, pas dispersée entre les services. Les services back-end ne nécessitent aucun changement de code et la même configuration de stratégie peut être réutilisée sur plusieurs itinéraires.

Cette approche est également indépendante du protocole. Les stratégies fonctionnent au niveau de la couche HTTP. Par conséquent, elles s’appliquent de façon cohérente, que l’agent communique via REST, MCP, A2A ou webhooks. Comme indiqué dans Agent Fabric Deep Dive, tout le trafic A2A et MCP est acheminé via Flex Gateway pour s’assurer que les stratégies sont appliquées à chaque point de terminaison, ce qui signifie que la propagation de l’identité est appliquée uniformément, quel que soit le protocole de communication.

Trois modèles composables couvrent le spectre complet des exigences d’identité dans une architecture agentique :

Modèle	Police	Identité de l’utilisateur	Interaction de l’utilisateur	Cas d’utilisation
Au nom de (OBO)	Stratégie d’injection d’identifiants OBO OAuth 2.0	Conservé	Aucun (transparent)	Données spécifiques à l’utilisateur dans le même domaine Trust
Serveur à serveur (S2S)	Identifiants client OAuth 2.0 sortants	Non propagé	Aucun	Données publiques, opérations au niveau système
Code d’autorisation en cours de tâche	Code d’autorisation A2A en cours de tâche sortant	Primaire + Secondaire	Obligatoire (authentification en ligne	Opérations inter-domaines, multi-fournisseurs d’identité, à haut risque

Ces modèles ne sont pas mutuellement exclusifs. Comme le montrent les scénarios Finport, un courtier unique peut utiliser OBO pour un appel en aval, S2S pour un autre, et In-Task pour un troisième. La configuration de la stratégie sur chaque itinéraire sortant détermine le modèle applicable. Il n’y a aucun changement de code d’agent et aucune modification de service, seulement la stratégie.

Les schémas appliqués par la passerelle décrits ci-dessus sécurisent les interactions individuelles, mais la propagation de l’identité n’est pas une préoccupation isolée. Il s’agit d’une couche fondamentale du modèle de gouvernance plus large de MuleSoft Agent Fabric. Comme décrit dans Agent Fabric Deep Dive, Agent Fabric repose sur quatre piliers : Découvrir, Orchestrer, Gouverner et Observer, et chacun dépend d’une chaîne d’identité fiable pour fonctionner efficacement.

Découvrir: Le Registre des agents répertorie les agents et leurs capacités. Les métadonnées des agents, y compris les exigences d’authentification, permettent aux courtiers de comprendre les modèles d’identité attendus par chaque agent.
Orchestrer: Le courtier d’agents coordonne les workflows multi-agents. La passerelle Flex gère de façon transparente la transformation de l’identité à chaque saut, ce qui permet au courtier de se concentrer sur la décomposition et l’acheminement des tâches.
Gouverner: Tout le trafic A2A et MCP est acheminé via Flex Gateway, même si le système cible n’est pas sécurisé, pour s’assurer que les stratégies sont appliquées à chaque point de terminaison. Les stratégies d’authentification sortantes font partie de la couche de gouvernance.
Observer: Agent Visualizer offre une observabilité en temps réel grâce à une carte dynamique et interactive des interactions des agents. Avec l’identité des utilisateurs préservée à chaque saut, les traces et les journaux fournissent des pistes d’audit attribuables aux utilisateurs à travers le réseau d’agents.

Sans propagation de l’identité de confiance, la gouvernance est incomplète. Vous pouvez cataloguer et orchestrer des agents, mais vous ne pouvez pas vous assurer qu’ils agissent dans les limites de l’autorisation de l’utilisateur. Trusted Agent Identity comble cette lacune, en veillant à ce que la sécurité et le contexte utilisateur restent au cœur des workflows des agents.

Pour implémenter les modèles suivants :

Comprendre le Répertoire des stratégies sortantes. Examinez l’ensemble complet de stratégies d’authentification sortantes disponibles pour Flex Gateway.
Commencer par OBO. La politique d’échange de jetons OAuth 2.0 répond aux besoins les plus courants de propagation de l’identité : préserver le contexte utilisateur à travers les sauts des agents.
Ajouter In-Task pour des scénarios inter-domaines: Lorsque votre réseau d ’ agents franchit les limites Trust, la politique A2A In-Task Authorization Code fournit le mécanisme de réponse au défi permettant d ’ obtenir des identifiants secondaires de l ’ utilisateur.
Tirer parti d’Agent Fabric. Définissez votre réseau d’agents dans le YAML réseau-agent avec des configurations de stratégie qui spécifient le modèle d’identité par itinéraire. La plate-forme gère le reste.

Pour des conseils de mise en œuvre détaillés, consultez le guide de mise en œuvre complémentaire.

Nikhil Aggarwal est un ingénieur émérite chez Salesforce, où il dirige l’architecture pour MuleSoft et Salesforce Automation Cloud. Nikhil apporte plus de 18 ans d’expérience dans la livraison de produits à grande échelle et est passionné par l’architecture évolutive, les expériences intuitives de développement et la création d’équipes très performantes. Avant Salesforce, il a dirigé plusieurs initiatives dans Microsoft Power Platform, Dataverse et Office 365, du concept au lancement. Son travail continue de façonner la façon dont les entreprises modernes connectent les systèmes, automatisent les workflows et libèrent la valeur métier à l’ère de l’IA.

Akash Trivedi est directeur de l’ingénierie chez Salesforce avec plus de 18 ans d’expérience dans la construction de systèmes d’entreprise évolutifs, sécurisés et performants. Il travaille au croisement de l’IA, de l’architecture d’entreprise et de l’intelligence des processus, avec un focus sur les plates-formes natives du cloud et des solutions fiables qui fonctionnent à grande échelle. Avant Salesforce, il a occupé des fonctions d’ingénieur chez Microsoft, où il a contribué à des produits tels que Copilot, Dataverse et Power Platform.