La porte humaine : concevoir les approbations d'outils MCP à la limite de la passerelle

MCP offre aux clients et aux serveurs un moyen standardisé de découvrir et d'appeler des outils. Il ne cherche délibérément pas à standardiser une interface utilisateur d'approbation ou un flux de travail spécifique avec intervention humaine. La spécification des outils du 28/07/2026 indique que les implémentations sont libres de choisir leur modèle d'interaction, tout en recommandant aux applications de permettre à un humain de refuser les appels d'outils. Les approbations d'outils MCP de TrueFoundry s'inscrivent dans cet espace d'implémentation : la passerelle peut suspendre un tools/callcorrespondant, créer une demande d'approbation, notifier un approbateur et renvoyer un résultat positif contenant des métadonnées d'approbation spécifiques à TrueFoundry, afin qu'un appelant compatible puisse distinguer l'attente d'approbation de l'échec de l'exécution de l'outil. L'intérêt technique ne réside pas dans le fait que MCP ait standardisé l'approbation — ce qui n'est pas le cas — mais dans la possibilité d'appliquer cette approbation à une frontière d'outil partagée, délimitée par l'identité et l'outil, et corrélée au chemin d'exécution, sans transformer une décision humaine ponctuelle en une politique d'autorisation permanente.

‍

1. Commencer par la frontière du protocole

La distinction la plus importante réside entre ce que MCP standardise et ce que la passerelle implémente. Le MCP normalise la découverte des outils, leur invocation, les schémas, les résultats et — dans la révision du 28 juillet 2026 — des moyens plus riches pour qu'un flux de travail d'outil puisse nécessiter une saisie supplémentaire. Les directives de la spécification concernant l'interaction utilisateur sont volontairement plus souples : les applications doivent rendre l'exposition et l'invocation des outils visibles et permettre à un humain de refuser des opérations, mais le protocole n'impose pas d'interface de confirmation ou de cycle de vie d'approbation particulier. Cela laisse à la passerelle la possibilité d'imposer une politique à l'échelle de l'organisation sans prétendre que son objet de politique fait partie intégrante du MCP lui-même.

Le flux documenté de TrueFoundry peut être résumé en six étapes. Un tools/call atteint la passerelle MCP et correspond à une politique d'approbation ; la passerelle retient l'appel au lieu d'invoquer l'outil en aval ; elle crée ou réutilise la demande d'approbation en attente et notifie le chemin d'approbation configuré ; l'appelant reçoit un résultat positif dont le _meta.approval_status indique que l'exécution est en attente ; un humain approuve ou refuse ; et, après approbation, la passerelle autorise l'exécution selon la validité configurée. Les appels répétés pour le même contexte demandeur/outil en attente peuvent réutiliser la demande en attente plutôt que de générer une nouvelle notification d'approbation à chaque fois.

La pause est un état au niveau de l'implémentation, pas une erreur de protocole. C'est un bon contrat client, car un orchestrateur qui comprend les métadonnées peut bifurquer sur « en attente d'approbation » au lieu de considérer l'outil comme indisponible. Mais la contrainte est explicite : les clients qui ne comprennent pas les métadonnées TrueFoundry ne sont pas garantis d'attendre correctement. La spécification MCP du 28 juillet 2026 définit également input_required des résultats pour les demandes à plusieurs allers-retours et déplace les tâches de longue durée dans une extension ; ce sont des mécanismes MCP standardisés avec des sémantiques de transmission différentes. La porte d'approbation doit donc être décrite comme compatible avec un monde MCP de plus en plus interruptible, et non comme une tâche MCP insérée par la passerelle.

Le lien d'audit est une corrélation, pas de la magie. Les métadonnées de résultat documentées fournissent au chemin d'exécution un statut d'approbation et un identifiant de demande qui peuvent être utilisés pour corréler l'appel avec le flux de travail d'approbation. Ne déduisez pas que chaque charge utile de résultat d'outil contient elle-même l'identité de l'approbateur, l'horodatage de la décision, le motif ou la fenêtre de validité, à moins que ces champs ne soient présents séparément dans l'enregistrement ou la trace d'approbation. « Corrélable à une décision d'approbation » est la propriété défendable ; « enregistrement de conformité autonome » ne l'est pas.

2. Les sémantiques de sécurité sont dans le périmètre

La fonctionnalité d'approbation est plus facile à appréhender lorsqu'elle est traitée comme un point de contrôle d'autorisation restreint plutôt que comme une couche de sécurité universelle. Quatre propriétés sont importantes.

Premièrement, la validité modifie le sens du terme « approuvé ». Avec une validité à exécution unique, l'approbation est liée à l'exécution en attente. Avec une autorisation basée sur le temps, la décision humaine crée une autorité temporaire pour les invocations ultérieures du même tuple demandeur + serveur MCP + outil, jusqu'à l'expiration du délai. C'est utile lorsqu'une confirmation répétée n'apporterait aucune valeur ajoutée, mais cela signifie également que des ensembles d'arguments ultérieurs peuvent être exécutés sans nouvel examen humain. Plus l'action est sensible aux arguments ou irréversible, plus il est justifié d'opter pour une approbation à exécution unique ou pour une politique supplémentaire au niveau des arguments.

Deuxièmement, le cloisonnement des demandeurs empêche le transfert d'approbation. Une approbation accordée à une identité ne devrait pas autoriser silencieusement une autre identité simplement parce que les deux agents accèdent au même serveur et au même outil. Cela fait de l'identité résolue du demandeur une partie intégrante de la limite de sécurité, et non un simple libellé d'audit.

Troisièmement, le refus est intentionnellement éphémère. Un refus répond par « pas maintenant » à la requête en attente. Si une identité ne doit jamais appeler l'outil, la réponse durable doit relever de l'accès au serveur, de l'exposition de l'outil ou d'une autre couche de politique permanente. Garder ces concepts séparés évite qu'une file d'attente de décisions d'approbation ponctuelles ne devienne accidentellement une base de données d'autorisations.

Quatrièmement, la priorité des politiques nécessite un langage précis. La correspondance de la portée et la durée de validité de l'autorisation sont deux questions distinctes. Une configuration d'approbation plus spécifique détermine quelle politique d'outil s'applique, tandis que la validité doit se résoudre vers la durée la plus restrictive lorsque cela est applicable. Ne résumez pas ces deux idées par le slogan « la politique la plus restrictive l'emporte » sans préciser quelle dimension est concernée.

‍