Le filtre humain : concevoir l'approbation d'outils MCP au niveau de la passerelle

MCP offre aux clients et aux serveurs un moyen standardisé de découvrir et d'invoquer des outils. Il ne standardise volontairement pas d'interface utilisateur d'approbation ni de workflow d'humain dans la boucle unique. La spécification d'outils du 28/07/2026 indique que les implémentations sont libres de choisir leur modèle d'interaction, tout en recommandant aux applications d'offrir à un humain la capacité de refuser des invocations d'outils. Les approbations d'outils MCP de TrueFoundry s'inscrivent dans cet espace d'implémentation : la Gateway peut intercepter un tools/call correspondant, créer une demande d'approbation, notifier un approbateur et renvoyer un résultat réussi contenant des métadonnées d'approbation spécifiques à TrueFoundry. Ainsi, un appelant compatible peut distinguer en attente d'approbation de l'exécution de l'outil a échoué. La valeur d'ingénierie ne réside pas dans le fait que MCP a standardisé l'approbation — ce n'est pas le cas — mais dans le fait que l'approbation peut être appliquée à une frontière d'outil partagée, restreinte à une identité et à un outil, et corrélée au parcours d'exécution sans transformer une décision humaine temporaire en une politique d'autorisation permanente.

1. Commencer à la frontière du protocole

La distinction la plus importante réside entre ce que MCP standardise et ce que la Gateway implémente. MCP standardise la découverte d'outils, l'invocation, les schémas, les résultats et — dans la révision du 28/07/2026 — des moyens plus riches pour qu'un workflow d'outil requière des saisies supplémentaires. Les recommandations de la spécification concernant l'interaction utilisateur sont délibérément plus souples : les applications doivent rendre l'exposition et l'invocation des outils visibles et donner à un humain la possibilité de refuser des opérations, mais le protocole n'impose pas d'interface de confirmation spécifique ni de cycle de vie d'approbation. Cela laisse à une passerelle la latitude d'imposer une politique à l'échelle de l'organisation sans prétendre que son objet de politique fait partie de MCP lui-même.

Le flux documenté de TrueFoundry peut se lire en six étapes. Un tools/call atteint la Gateway MCP et correspond à une politique d'approbation ; la Gateway 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 canal d'approbateurs configuré ; l'appelant reçoit un résultat réussi dont _meta.approval_status communique que l'exécution est en attente ; un humain approuve ou me refuse ; et, en cas d'approbation, la Gateway libère l'exécution selon la validité configurée. Des 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 traiter l'outil comme indisponible. Mais la contrainte est explicite : les clients qui ne comprennent pas les métadonnées TrueFoundry ne sont pas garantis de patienter correctement. La spécification MCP du 28/07/2026 définit également des résultats input_required pour les requêtes multi-allers-retours et déplace les Tasks à longue durée d'exécution vers une extension ; ce sont des mécanismes MCP standardisés avec des sémantiques réseau différentes. Le filtre d'approbation doit donc être décrit comme compatible avec un écosystème MCP de plus en plus interruptible, et non comme une Task MCP insérée par la Gateway.

Le lien d'audit est une corrélation, pas de la magie. Les métadonnées de résultat documentées fournissent au parcours d'exécution un statut d'approbation et un identifiant de requête qui peuvent être utilisés pour corréler l'appel avec le workflow d'approbation. N'en déduisez pas que chaque charge utile de résultat d'outil contient en 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 séparément présents dans l'enregistrement d'approbation ou la trace. « Correlable à 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é résident dans la portée

Il est plus facile d'analyser la fonctionnalité d'approbation 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 essentielles.

Premièrement, la validité modifie la signification d me « approuvé ». Avec une validité à exécution unique, l'approbation est liée à l'exécution en attente et à une décision d me humain dans la boucle. Avec une autorisation temporelle, la décision humaine crée une autorité temporaire pour les invocations ultérieures du même n-uplet demandeur + serveur MCP + outil jusqu'à l'expiration de la fenêtre. C'est utile lorsque des confirmations répétées n'apporteraient aucune valeur de jugement, mais cela signifie également que des ensembles d'arguments ultérieurs peuvent s'exécuter sans nouvelle révision humaine. Plus l'action dépend des arguments ou est irréversible, plus l'argument en faveur d'une approbation à exécution unique ou d'une politique supplémentaire au niveau des arguments est fort.

Deuxièmement, la délimitation par demandeur empêche le transfert d'approbation. Une approbation accordée à une identité ne doit pas autoriser silencieusement une autre identité simplement parce que les deux agents atteignent le même serveur et le même outil. Cela fait de l'identité résolue du demandeur un élément de la frontière de sécurité, et pas seulement une étiquette d'audit.

Troisièmement, le refus est intentionnellement éphémère. Un refus répond « pas maintenant » pour la requête en attente. Si une identité ne doit jamais appeler l'outil, la réponse durable relève de l'accès au serveur, de l'exposition de l'outil ou d'une autre couche de politique permanente. Maintenir ces concepts séparés empêche une file d'attente de décisions d'approbation ponctuellement prises de devenir une base de données d'autorisation accidentelle.

Quatrièmement, la priorité des politiques nécessite un langage précis. La portée de correspondance et la durée de vie de l'autorisation sont des questions différentes. 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 de vie la plus restrictive le cas échéant. Ne résumez pas ces deux idées sous le slogan « la politique la plus restrictive l'emporte » sans préciser quelle dimension est en cours de résolution.

3. La fatigue de l'approbation est un mode d'échec opérationnel

L'approbation humaine n'ajoute de la sécurité que si la décision humaine contient des informations que la politique statique ne possède pas. Si la réponse est effectivement prédéterminée, le filtre devient une source de latence ajoutée à un événement d'audit — et non un acte de jugement. L'objectif de conception n'est donc pas d'« approuver plus », mais de transmettre les décisions résiduelles et dépendantes du contexte à des personnes, et de coder tout le reste sous forme de politique.

Commencez par soumettre à approbation une classe restreinte d'actions critiques : mutations destructrices, modifications en production, communications externes, opérations coûteuses ou autres appels où le contexte peut modifier la réponse. Acheminez les requêtes vers des responsables désignés, et non vers de larges audiences. Conservez une fenêtre de validité proportionnelle à l'autorité qu'une seule décision doit accorder. Et traitez le comportement de repli sur l'administrateur comme une exception opérationnelle à surveiller, car un serveur sans approbateur responsable peut transformer un contrôle de sécurité en un goulot d'étranglement.

Mesurez le fonctionnement du filtre, mais distinguez les métriques que vous devez exploiter des métriques actuellement documentées comme intégrées au produit. Les métriques d'approbation utiles incluent la latence entre la création et la décision, le taux d'approbation/refus, la fréquence de nouvelle requête après expiration, la proportion d'invocations soumises à approbation utilisant des autorisations à exécution unique par rapport aux autorisations temporelles, et la fraction acheminée via un repli administrateur. Le tableau de bord de métriques documenté de TrueFoundry expose le débit, la latence et les échecs des requêtes/outils MCP ; il ne documente pas actuellement de tableau de bord de premier ordre pour la latence d'approbation, le taux d'approbation ou les modèles de renouvellement. Si vous avez besoin de ces mesures spécifiques aux approbations, dérivez-les des enregistrements d'approbation ou des événements exportés disponibles dans votre déploiement plutôt que de les attribuer à la vue générique des métriques MCP.

L'audit du filtre. Pour chaque outil soumis à approbation, répondez à sept questions : Pourquoi un humain est-il nécessaire plutôt qu'une politique statique ? La validité est-elle liée à une seule exécution ou temporelle ? Si elle est temporelle, quelles modifications d'arguments ultérieures peuvent survenir sans réapprobation ? Quelle identité résolue possède l'autorisation ? Qui est l'approbateur désigné et quel est le recours en cas d'absence ? Le client appelant peut-il reconnaître explicitement et réessayer la convention de résultat en attente ? Et si le filtre dépend d'annotations MCP telles que destructiveHint, le serveur est-il de confiance — ou l'organisation a-t-elle classé l'outil de manière indépendante ? Vérifiez ensuite que l'ID de la demande d'approbation peut être corrélé avec l'exécution de l'outil et l'enregistrement de décision correspondants. L'objectif est d'obtenir la preuve d'une décision réelle, et non un volume élevé d'événements « approuvés ».

4. Où se situe le filtre — et ce qu'il ne remplace pas

Un parcours d'outil en production nécessite plusieurs contrôles ayant des rôles différents. Le registre ou le processus d'admission détermine quels serveurs et outils sont autorisés dans l'environnement. L'authentification identifie l'appelant. Le contrôle d'accès détermine quels outils cet appelant peut atteindre. Les guardrails pré-outil inspectent ou transforment l'invocation. L'approbation d'outil peut retenir un appel autorisé dans l'attente d'une décision humaine. La Gateway applique cette rétention. Le serveur MCP en aval effectue l'effet de bord. Les guardrails post-outil inspectent le résultat. Les traces et les enregistrements d'approbation fournissent la chaîne de preuves.

Cela clarifie également la relation avec l me mécanisme d'humain dans la boucle de l'Agent Harness. L'Harness peut mettre en pause un agent géré avant un appel d'outil sensible, émettre tool.approval_required, terminer le tour actuel et reprendre la même session lorsqu'un UserToolApprovalEvent arrive. Les approbations d'outils de la Gateway appliquent la politique à la frontière MCP partagée. Les deux peuvent filtrer l'exécution d'un outil ; ils diffèrent par leur cycle de vie et leur emplacement, et non parce que l'un serait un « point de contrôle de raisonnement » générique et l'autre le seul filtre d'outil.

Il existe des limites qu'il convient d'énoncer clairement. L'approbation ne remplace pas l'autorisation. Un humain peut toujours être induit en erreur par une description d'outil altérée ou des arguments manipulés, de sorte que la vérification à l'admission et les contrôles au niveau des arguments restent nécessaires. Les annotations d'outils ne sont pas fiables du seul fait qu'elles arrivent via MCP. Les autorisations temporelles échangent délibérément une révision répétée contre une commodité encadrée. La disponibilité humaine ajoute de la latence et peut devenir une dépendance pour la fiabilité. Et une politique de Gateway ne peut pas régir le trafic MCP qui contourne la Gateway.

L'affirmation architecturale durable est donc plus restreinte que « la pause est devenue un citoyen de premier ordre du protocole », et gagne en force en étant précise : MCP standardise le substrat d'appel d'outil et prend désormais en charge des workflows interrompus plus riches ; les sémantiques d'approbation d'entreprise restent un choix d'implémentation et de politique. Une Gateway partagée peut rendre ce choix centralement applicable, limité à une identité, encadré dans le temps et auditable.

Références

• Sources primaires MCP — Spécification MCP 28/07/2026 pour les outils (modèle d'interaction utilisateur, résultats input_required, annotations d'outils) ; Annonce de la version de la spécification MCP du 28/07/2026 (extension Tasks et vue d'ensemble de la révision).
• Documentation TrueFoundry — Approbations d'outils MCP ; Gateway MCP ; Humain dans la boucle avec Agent Harness ; Rôles et collaborateurs ; Guardrails pré/post outil MCP ; Tableau de bord des métriques.
• Contexte d'ingénierie TrueFoundry associé — Registre MCP ; Défense contre la falsification d'outils (tool poisoning) ; Contrôle d'accès basé sur les tâches ; Propagation de l'autorisation ; Gouvernance et audit.

Les mécanismes du produit décrits dans cet article s'appuient sur la documentation actuelle de TrueFoundry ; les affirmations relatives au protocole sont basées sur la spécification MCP du 28/07/2026 et le matériel officiel de publication. Les sémantiques de résultat en attente et d'octroi d'approbation de TrueFoundry sont des conventions au niveau du produit, et non des états d'approbation standardisés par MCP. Les métriques d'exploitation spécifiques aux approbations proposées ci-dessus sont des mesures recommandées, et non des garanties que le tableau de bord actuel des métriques expose des graphiques d'approbation dédiés. Le comportement du produit et la documentation peuvent évoluer ; vérifiez les documents actuels avant de traiter les noms de champs ou la sémantique des politiques comme un contrat de compatibilité.

‍