L'authentification MCP expliquée : identité entrante, identifiants sortants et délégation

Le jeton qui identifie un appelant auprès d'une passerelle et l'identifiant utilisé pour atteindre un service en aval résolvent des problèmes différents. Les systèmes MCP sécurisés préservent cette distinction.

‍

L'authentification n'est pas une opération en une seule étape

Une requête MCP peut franchir plusieurs limites de confiance avant d'être traitée par un système métier. Une personne ou un service s'authentifie auprès d'une application. Un agent peut agir en tant qu'entité logicielle distincte. Le client s'authentifie auprès de la passerelle MCP. La passerelle décide si cet appelant peut utiliser un serveur ou un outil. Ensuite, la passerelle s'authentifie auprès du serveur MCP en aval, qui peut lui-même appeler un autre service faisant autorité.

Utiliser le terme « jeton » pour désigner chaque identifiant fait disparaître ces limites. L'identifiant entrant répond à la question de savoir qui appelle la passerelle. La politique d'accès répond à la question de savoir quelles ressources de la passerelle cette identité peut utiliser. L'authentification sortante détermine quels identifiants et quelles permissions le serveur en aval reçoit. Ces réponses peuvent être intentionnellement différentes.

La documentation de TrueFoundry sépare l'architecture en authentification entrante, contrôle d'accès et authentification sortante. Cette séparation est le point de départ idéal pour réfléchir à la délégation, à l'attribution et au risque de « député confus » (confused-deputy).

La passerelle est intentionnellement divisée en trois vérifications. Une authentification entrante réussie identifie un appelant, mais la politique d'accès sélectionne toujours les outils autorisés et l'authentification sortante détermine toujours l'entité vue par le serveur MCP.

L'authentification entrante résout l'appelant de la passerelle

TrueFoundry documente plusieurs méthodes entrantes : un jeton d'accès personnel pour les utilisateurs possédant des comptes TrueFoundry, un jeton de compte virtuel pour les appels de service à service, un jeton de fournisseur d'identité pour les clients ou services utilisant l'émetteur JWT d'une organisation, et TrueFoundry OAuth pour les clients IDE compatibles.

Après avoir validé l'identifiant, la passerelle résout une identité TrueFoundry et applique le contrôle d'accès aux serveurs MCP et aux outils individuels. L'identité pertinente peut être un utilisateur, une équipe ou un compte virtuel. L'identité d'agent, documentée en version bêta, ajoute un acteur agent enregistré distinct pour les appels initiés par des agents. Cela diffère d'un compte virtuel, qui représente un service ou une application sans intervention humaine.

La résolution d'identité doit valider l'émetteur, l'audience, la signature, les limites temporelles et le mappage des revendications utilisé pour sélectionner le sujet. Un jeton valablement signé pour la mauvaise audience ne constitue pas une autorisation pour la passerelle. Les mappages doivent être suffisamment spécifiques pour que deux services ne puissent pas être résolus accidentellement vers la même identité d'agent.

L'authentification sortante sélectionne l'entité en aval

La passerelle peut s'authentifier auprès d'un serveur MCP en utilisant un code d'autorisation OAuth par utilisateur, des identifiants de client OAuth au niveau de l'application, la configuration documentée d'échange de jetons/OBO Okta, des clés API partagées ou individuelles, aucune authentification pour les services publics, le transfert de jetons, le routage de jetons ou AWS SigV4 pour les points de terminaison AWS pris en charge.

Ces modes encodent des autorités différentes. OAuth par utilisateur permet à chaque personne d'autoriser son propre compte tiers. Les identifiants de client représentent l'application et exposent généralement des permissions de service partagées. L'échange de jetons ou OBO demande à un système d'identité de générer un jeton en aval dérivé de l'identité de l'appelant et ciblé vers une autre audience. Une clé API partagée regroupe tous les appelants sur une seule entité en amont, même si la passerelle préserve l'attribution interne.

Choisir l'intégration la plus simple peut modifier silencieusement le modèle d'autorisation. Si un serveur MCP Gmail utilise un identifiant de service partagé, l'amont ne voit pas l'autorité de la boîte aux lettres personnelle de chaque employé. Si un serveur MCP interne valide directement le jeton IdP de l'organisation, le transfert peut préserver le sujet, mais uniquement si l'émetteur, l'audience et les portées sont acceptés délibérément.

Le diagramme regroupe les modes selon la sémantique d'autorité plutôt que par étiquettes de protocole. Les flux par utilisateur et OBO peuvent préserver le contexte du sujet, tandis que les identifiants client et les clés partagées représentent l'autorité de l'application, à moins que le service en aval n'applique des contrôles supplémentaires tenant compte du sujet.

Le passage direct (passthrough) et le transfert (forwarding) ne sont pas des synonymes.

Dans la terminologie documentée de TrueFoundry, le passage direct de jeton (token passthrough) transmet au serveur MCP le même jeton que celui utilisé pour l'authentification entrante. Le serveur doit être capable de valider ce jeton TrueFoundry ou celui du fournisseur d'identité. Le transfert de jeton (token forwarding) utilise des identifiants distincts, spécifiques au serveur, fournis par le client dans des en-têtes dédiés. L'identifiant sortant n'est pas le porteur entrant.

Cette distinction est importante pour la journalisation, le masquage, la révocation et la modélisation des menaces. Le passage direct préserve un identifiant unique au-delà de la passerelle et nécessite donc une confiance correcte de la part de l'audience en aval. Le transfert introduit un autre secret que le client doit obtenir et protéger. Aucun des deux ne prouve automatiquement qu'une API métier finale a bien identifié la relation prévue entre l'humain et l'agent.

L'échange de jetons OAuth et l'OBO offrent un modèle différent : la passerelle ou la couche d'identité obtient un nouveau jeton spécifique à l'audience, représentant une autorité déléguée. Cela peut réduire la réutilisation des jetons de porteur et permettre aux systèmes en aval d'appliquer des portées conçues pour leurs ressources. Les garanties exactes dépendent du fournisseur d'identité, des revendications, de la validation et de l'application en aval.

Modélisez les entités, pas seulement les en-têtes.

Entité | Question à laquelle elle répond | Échec courant Sujet humain | Au nom de qui le travail est-il demandé ? | Perdu lorsqu'un identifiant de service partagé remplace le contexte utilisateur. Agent logiciel | Quel agent logiciel effectue le travail ? | Confondu avec l'utilisateur ou un jeton d'application générique. Appelant de la passerelle | Quelle identité s'est authentifiée auprès de ce plan de contrôle ? | Le jeton accepté a le mauvais émetteur ou la mauvaise audience. Entité en aval | Quelle autorité le serveur ou le service MCP applique-t-il ? | L'identifiant partagé accorde des accès plus larges que ce que l'utilisateur devrait voir. Propriétaire de la ressource métier | Qui peut autoriser l'objet et l'action spécifiques ? | L'accès à la passerelle est confondu avec une autorisation de domaine.

Prévenir le problème du « député confus » (confused deputy).

Une passerelle devient un « député confus » lorsqu'elle dispose d'une large autorité en aval et l'utilise pour un appelant qui ne possède pas de permission équivalente. L'authentification entrante peut être parfaitement valide alors que l'action composée est toujours sur-autorisée. La passerelle doit combiner l'identité de l'appelant, l'identité de l'agent, le serveur et l'outil demandés, le mode d'identifiant sortant et la portée en aval.

Pour les identifiants partagés, le serveur MCP ou l'application sous-jacente doit recevoir suffisamment de contexte de confiance pour réappliquer une autorisation tenant compte du sujet, ou l'outil ne doit exposer que des ressources sûres pour chaque appelant autorisé. Ne comptez pas sur le modèle pour filtrer les résultats après une requête large. Pour les identifiants par utilisateur, vérifiez que l'autorisation est liée au sujet prévu et ne peut pas être substituée par un autre utilisateur via des remplacements.

Chaque saut doit également préserver un identifiant de corrélation d'audit sans copier les jetons de porteur dans les journaux. Enregistrez le mode d'identifiant, l'identité résolue, l'émetteur, l'audience, la classe de portée, la version de la politique et les métadonnées de réponse en aval. Les valeurs secrètes doivent rester dans des coffres sécurisés, et non dans des transcriptions ou des traces.

La chaîne transporte à la fois un sujet humain et un acteur logiciel à travers la décision de la passerelle. Le mode sortant peut préserver, échanger ou fusionner ce contexte d'identité ; le système en aval effectue toujours l'autorisation finale de la ressource et de l'action.

Exemple pratique : accès au CRM du support client.

Un agent de support reçoit une demande d'un employé authentifié. L'application envoie le jeton du fournisseur d'identité de l'employé à la passerelle MCP et présente séparément l'identité de l'agent enregistré. La politique de la passerelle autorise cette paire utilisateur-agent à appeler l'outil de recherche CRM.

Supposons que le déploiement utilise la configuration Okta OBO documentée de TrueFoundry. La passerelle échange le jeton utilisateur entrant contre un jeton d'audience CRM avec une portée de lecture seule sur les dossiers. Le CRM valide le nouveau jeton et applique sa propre autorisation au niveau des lignes. L'agent peut récupérer les dossiers autorisés de l'employé mais ne peut pas les modifier. Un outil de mise à jour distinct nécessite une portée en aval plus restreinte et une approbation.

Si le déploiement utilise plutôt une clé API partagée, l'architecture doit compenser. Le service faisant face au CRM reçoit un attribut de sujet résolu et de confiance de la passerelle, le valide et filtre les enregistrements côté serveur. Si le service ne peut pas appliquer le contexte du sujet, la clé partagée n'est pas adaptée aux données nécessitant une autorisation spécifique à l'utilisateur.

Choisissez l'authentification sortante selon la sémantique d'autorité.

• Utilisez une autorisation par utilisateur lorsque la ressource en amont appartient à chaque personne ou est soumise à ses permissions.
• Utilisez les identifiants client pour les ressources appartenant réellement à l'application, et non comme un raccourci pour contourner l'autorisation utilisateur.
• Utilisez l'échange de jetons ou le modèle OBO (On-Behalf-Of) lorsque l'aval nécessite un jeton utilisateur délégué et spécifique à une audience.
• Utilisez le transfert (passthrough) uniquement lorsque l'aval fait délibérément confiance au jeton entrant et le valide.
• Utilisez le routage (forwarding) lorsque le serveur MCP dispose d'un système d'identification distinct et acceptez la charge de gestion des secrets client qui en découle.
• Considérez les serveurs sans authentification comme des capacités publiques ; n'y placez aucune donnée sensible ni aucune fonction de modification.

Tests d'échec pour la chaîne d'authentification

• Rejouez un jeton valide avec une audience, un émetteur, un locataire ou un sujet mappé incorrect.
• Maintenez l'utilisateur constant et modifiez l'identité de l'agent ; vérifiez que la portée effective des outils change comme prévu.
• Maintenez l'agent constant et modifiez l'utilisateur ; vérifiez que les données en aval suivent bien le sujet humain lorsque cela est requis.
• Substituez un identifiant individuel via le remplacement d'autorisation d'un autre utilisateur.
• Révoquez une autorisation de passerelle et une autorisation OAuth en amont indépendamment ; vérifiez leurs effets distincts.
• Appelez le serveur MCP en dehors de la passerelle ; vérifiez que les politiques réseau et serveur empêchent tout contournement lorsque nécessaire.
• Inspectez les journaux, les traces, les erreurs et le contexte du modèle pour détecter toute fuite de jetons porteurs ou de secrets transmis.

Le cycle de vie des identifiants fait partie du chemin de données

La conception de l'authentification se poursuit après l'acceptation d'un jeton. Les identifiants expirent, sont actualisés, renouvelés et révoqués au sein de différents systèmes. La documentation de TrueFoundry note, par exemple, que son action « Révoquer tous les jetons » supprime les identifiants stockés de l'AI Gateway, mais ne révoque pas les autorisations auprès du fournisseur OAuth en amont. Les opérateurs doivent disposer de procédures distinctes pour l'identifiant de la passerelle, la session du fournisseur d'identité, l'autorisation en amont et tout jeton mis en cache en aval.

Définissez quel composant actualise chaque identifiant, quel sujet le jeton actualisé représente, et ce qui se passe lorsque l'actualisation échoue au milieu d'une tâche d'agent. Un flux d'autorisation suspendu ne doit pas basculer silencieusement vers un identifiant d'application disposant d'un accès plus large. Lorsque l'utilisateur reconnecte un compte, la nouvelle autorisation doit être corrélée avec le sujet et le serveur prévus avant que l'agent ne poursuive.

Le renouvellement crée une limite de test supplémentaire. Les clés API partagées peuvent nécessiter une période de double clé ; les jetons OAuth par utilisateur peuvent être invalidés indépendamment ; les jetons OBO peuvent être mis en cache jusqu'à leur expiration, tandis que le jeton entrant doit rester à jour pour le rééchange. Stockez les identifiants de mode d'authentification et de famille de jetons dans des métadonnées opérationnelles protégées afin que les intervenants puissent identifier les appels concernés sans exposer les secrets.

La révocation doit être vérifiée de l'extérieur vers l'intérieur. Supprimez le collaborateur de la passerelle, révoquez l'autorisation en amont, désactivez le compte en aval et testez chaque effet séparément. Une procédure d'incident complète doit identifier quelle action arrête les nouveaux appels de passerelle, laquelle invalide l'accès direct, et laquelle supprime uniquement une copie locale.

La gestion des jetons doit également être absente du contexte visible par le modèle. Les agents peuvent raisonner sur des étiquettes d'identité stables, des résultats d'autorisation et des instructions de reconnexion sans recevoir de matériel porteur. Les erreurs renvoyées par les fournisseurs doivent être normalisées afin que les sorties de débogage ne divulguent pas d'en-têtes, de jetons d'actualisation, de secrets client ou de composants de requête signés dans la transcription.

La règle opérationnelle

Une authentification MCP sécurisée commence par l'identification de chaque acteur et de chaque étape. L'identité entrante, l'accès à la passerelle, les identifiants sortants et l'autorisation métier sont des contrôles liés mais non interchangeables. La conception la plus sûre rend explicite tout changement d'acteur ou d'audience.

La passerelle MCP de TrueFoundry fournit des mécanismes documentés pour chaque couche exposée, et l'identité de l'agent — documentée en version bêta dans la carte de disponibilité de la gouvernance — permet de distinguer l'acteur logiciel du sujet humain. L'application en aval conserve la responsabilité de son autorisation de domaine et l'organisation celle de la minimisation des identifiants. Cette limite n'est pas une restriction dans l'explication ; c'est ce qui rend le modèle de sécurité testable.

Références

1. TrueFoundry — Authentification et sécurité de la passerelle MCP.
2. TrueFoundry — Identité de l'agent.
3. TrueFoundry — Présentation de la passerelle MCP.
4. IETF RFC 8693 — Échange de jetons OAuth 2.0.

Note éditoriale. Cet article reflète l'interprétation technique de TrueFoundry des documents publics cités au 17 septembre 2026. Les fonctionnalités du produit sont limitées à la documentation liée. Les exemples et les paramètres par défaut sont fournis à titre illustratif ; ils ne constituent ni un conseil juridique, ni un avis d'audit, ni une référence indépendante, ni une garantie de sécurité, de sûreté ou de conformité.

‍