Comment les changements de liste d’outils MCP modifient une session active

Une session MCP active ne devrait pas hériter de la confiance accordée à des outils qui n’existaient pas au moment de son approbation. La découverte d’outils ressemble à une simple tuyauterie jusqu’à ce qu’un agent puisse appeler une action nouvellement disponible avec le même élan conversationnel et les mêmes identifiants en arrière-plan. À ce moment-là, la surface d’action a changé, même si personne n’a modifié l’invite.

J’ai vu des ingénieurs approuver une exécution de programmation pour travailler sur un dépôt, puis la laisser tourner pendant qu’un connecteur obtenait une action de déploiement ou de gestion de tickets. La défense habituelle est : « L’agent n’avait que les outils dont il avait besoin. » Cette phrase cesse d’être vraie dès que la liste change. Un agent de longue durée mérite moins de confiance accordée à la légère qu’un court processus en ligne de commande, pas davantage.

La règle que j’applique est simple : comparez l’inventaire des outils à chaque changement, classez le changement d’autorité, puis lancez une nouvelle exécution d’agent lorsque le changement ajoute ou modifie de façon importante une surface d’action. N’en faites pas un projet de rédaction de politiques. L’objectif est de préserver une décision humaine qui garde le sens qu’elle avait lorsque vous l’avez prise.

Une liste d’outils est un inventaire d’autorité

Une liste d’outils MCP n’est pas un menu. C’est l’ensemble des opérations qu’un agent peut proposer et, selon le client, invoquer. Chaque entrée associe un nom, une description, un schéma d’entrée et un comportement qui atteint souvent un service que le modèle ne peut pas examiner directement.

La spécification Model Context Protocol décrit les outils comme des fonctions contrôlées par le modèle et exposées par un serveur. Cette formulation compte. Un client peut présenter des descriptions au modèle, mais la description n’est pas une frontière de sécurité. Le schéma et le comportement côté serveur déterminent ce que l’appel peut faire.

Lorsque j’examine un inventaire, je pose cinq questions pour chaque outil :

• Quelles données cet appel peut-il lire ?
• Quel état cet appel peut-il modifier ?
• Où sa sortie peut-elle aller ?
• Quel identifiant ou quel hôte utilise-t-il ?
• Ses arguments peuvent-ils élargir le périmètre au-delà de ce que son nom suggère ?

Un outil nommé get_build_status peut être en lecture seule et limité. Un outil nommé request peut lire, écrire et envoyer des données partout où son identifiant l’autorise. Les noms rendent le premier facile à approuver et le second facile à sous-estimer.

On confond souvent découverte d’outils et autorisation. La découverte indique à l’agent ce qui est disponible. L’autorisation détermine s’il peut l’utiliser. Si vous fusionnez ces deux idées, une actualisation en pleine session devient un changement d’autorisation non examiné.

Les outils ajoutés exigent l’examen le plus strict

Un outil ajouté exige une nouvelle exécution lorsqu’il crée une nouvelle voie vers des données, des commandes ou une partie externe. C’est vrai même lorsque le nouvel outil semble lié au travail que l’agent effectue déjà.

Supposons qu’un agent démarre avec repo_search, read_issue et create_branch. En pleine session, le serveur ajoute post_comment. Certains y verront une petite extension, puisque l’agent lit déjà les tickets. Ce n’est pas mineur. Lire un ticket est une récupération privée. Publier un commentaire envoie un texte généré par le modèle à des personnes susceptibles d’agir, et peut révéler des détails de la conversation ou de l’espace de travail.

Traitez ces ajouts comme importants par défaut :

• Toute action qui écrit, supprime, déploie, publie ou envoie un message.
• Tout outil de requête généraliste dont la destination provient d’un argument.
• Toute action shell ou SSH, y compris lorsqu’elle est présentée comme un diagnostic.
• Toute action qui lit un nouveau dépôt, compte, hôte ou type de données.
• Toute action qui utilise un identifiant ayant un périmètre plus large que ceux des outils existants.

Une nouvelle action de lecture peut aussi exiger un redémarrage. Les ingénieurs réservent parfois leur inquiétude aux écritures, puis exposent un outil d’export capable de lire des dossiers clients, des journaux de compilation ou des secrets enregistrés dans la configuration. L’exfiltration commence par une lecture.

Il existe des exceptions étroites. Ajouter un second nom pour une opération déjà approuvée et fixe peut rester dans l’exécution si vous avez vérifié qu’il atteint le même service avec les mêmes arguments et le même identifiant. Ce cas est suffisamment rare pour que je n’accorde pas l’exception sur la seule base d’une note de version.

Les outils supprimés sont un signal, pas une révocation certaine

Un outil supprimé doit vous faire vérifier le client, car sa disparition d’une liste actualisée ne prouve pas que l’agent en cours a perdu l’accès. Le serveur a peut-être modifié sa liste annoncée tandis que le client conserve en mémoire une liste antérieure. Un autre client peut s’actualiser immédiatement. Vous ne pouvez pas déduire son comportement de manière sûre à partir de la seule suppression.

C’est important lors de l’examen d’un incident. Une équipe voit delete_environment supprimé du serveur, suppose que le danger est passé et laisse une ancienne session active. Si ce client avait déjà résolu la définition de l’outil, il peut encore tenter l’appel. Le serveur devrait le refuser si l’implémentation a supprimé le gestionnaire, mais la découverte annoncée et l’exécution réelle sont deux choses distinctes. Vérifiez les deux.

Suspendez l’agent et enregistrez l’inventaire avant et après. Testez ensuite l’action supprimée dans un environnement hors production, si vous possédez le serveur, ou terminez la session dans le cas contraire. Ne demandez pas au modèle s’il dispose toujours de l’outil. Sa réponse décrit son contexte de façon trop imprécise pour trancher une question d’autorisation.

La suppression a aussi une conséquence plus ordinaire : un renommage d’outil peut d’abord apparaître comme une suppression et un ajout. Voilà pourquoi vous comparez les définitions au lieu de compter les noms.

Les renommages exigent une preuve d’équivalence

Un renommage peut être cosmétique, mais il peut aussi masquer un contrat plus large. Les cas dangereux relèvent souvent de la maintenance ordinaire : search_logs devient query_logs, un schéma reçoit un champ project facultatif et le service commence à accepter des identifiants de projets distants. Le nom a à peine changé. L’autorité, si.

Créez un relevé de comparaison assez banal pour être utilisé sous pression. Pour chaque ancien et nouvel outil, consignez le nom, la description, le schéma JSON, les annotations déclarées de lecture seule ou destructives si elles existent, le point de terminaison ou la commande sous-jacente, l’identité de l’identifiant et les effets connus. Le schéma JSON ne révèle pas tous les comportements du serveur : traitez-le comme un élément de preuve, pas comme une réponse complète.

Voici une forme minimale utile d’inventaire :

{
  "name": "query_logs",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "query": {"type": "string"}
    },
    "required": ["query"]
  },
  "destination": "logs-api",
  "credential": "logs-read",
  "effects": ["read"]
}

L’échec que cela évite n’est pas une requête mal formée. Cela empêche un réviseur d’accepter un renommage tout en manquant le nouveau sélecteur project, qui peut transformer une requête locale en récupération entre projets.

Si les anciens et nouveaux relevés diffèrent par leur destination, leur identifiant, leurs effets ou le périmètre des arguments, considérez cela comme une capacité ajoutée et redémarrez. Si vous ne pouvez pas identifier le comportement sous-jacent, redémarrez quand même. « C’est probablement la même chose » n’est pas un résultat d’examen.

Les changements de schéma comptent plus que les descriptions

Un outil peut garder son nom tout en devenant plus dangereux. Les schémas d’entrée montrent souvent où cela se produit : nouveaux champs d’URL ou de chemin, sélecteurs de compte, chaînes de commandes libres, listes de destinataires et indicateurs facultatifs qui changent le mode d’exécution.

Prenons un outil qui commence avec cette entrée :

{
  "type": "object",
  "properties": {"issue_id": {"type": "string"}},
  "required": ["issue_id"]
}

Plus tard, il accepte include_private_notes ou destination_url. Le premier champ change ce que l’outil lit. Le second crée une voie de sortie. Aucun des deux n’a besoin d’un nouveau nom d’outil spectaculaire pour exiger une autre frontière d’approbation.

Les descriptions évoluent aussi. Un serveur peut changer « Obtenir les détails de la version » en « Obtenir et mettre à jour les détails de la version » sans modifier le schéma. Vous devez lire les descriptions, mais ne vous arrêtez pas là. Demandez au responsable quel gestionnaire s’exécute, quel principal il utilise et s’il effectue des requêtes sortantes. Une bonne réponse nomme une commande, un point de terminaison ou un compte de service. « C’est juste un assistant interne » ne vous apprend rien d’utile.

La spécification MCP autorise les métadonnées et annotations d’outils, mais la prise en charge des annotations et leur interprétation par les clients varient. Utilisez-les comme des étiquettes utiles. Ne fondez pas vos décisions d’approbation sur une étiquette comme lecture seule lorsque l’appel atteint au final un point de terminaison généraliste.

Une nouvelle exécution crée une limite que vous pouvez expliquer

Une nouvelle exécution est nécessaire lorsque l’approbation aurait un sens différent après le changement d’inventaire. Cette limite a une valeur pratique : elle arrête le processus actuel, rend la prochaine approbation attribuable à un exécutable connu et sépare dans vos archives l’ancien ensemble d’appels du nouveau.

Le processus est court :

1. Arrêtez les appels d’outils supplémentaires quand l’inventaire change de façon inattendue.
2. Enregistrez les anciens et nouveaux inventaires, y compris les schémas et la version du serveur si elle est disponible.
3. Marquez chaque différence comme supprimée, renommée, modifiée ou ajoutée.
4. Redémarrez si une différence élargit l’accès aux données, les effets, le périmètre de destination ou le périmètre de l’identifiant.
5. N’approuvez la nouvelle exécution qu’après avoir pu décrire en langage clair sa surface d’action autorisée.

Ne redémarrez pas seulement pour respecter un rituel. Redémarrez parce que cela invalide une approbation antérieure précise. Cette distinction maintient l’utilité de la règle. Une équipe qui redémarre pour chaque correction orthographique finira par ignorer la règle ; une équipe qui redémarre face à une nouvelle autorité apprendra à la reconnaître.

L’autorisation par session fonctionne bien lorsqu’elle lie l’approbation à un processus qui se termine. Sallyport suit ce modèle en affichant l’autorité de signature de code pour un nouveau processus d’agent, puis en conservant cette approbation jusqu’à la fin de l’exécution. Un inventaire modifié reste une raison de terminer ce processus si les actions qu’il peut demander se sont élargies.

L’approbation par appel couvre les actions qui doivent rester contraignantes

L’approbation par appel convient aux actions dont les conséquences sont trop importantes pour être cachées dans une large approbation de session. Utilisez-la pour les changements de production, les opérations destructrices, les messages publics, les opérations financières et les requêtes capables d’envoyer des données sensibles vers une destination choisie à l’exécution.

Certaines équipes tentent de résoudre ce problème avec une longue liste blanche de conditions rédigées en langage naturel. Cette approche reste populaire parce qu’elle promet moins d’interruptions. Elle donne aussi aux réviseurs un moteur de règles fragile qu’ils doivent comprendre pendant qu’un agent s’exécute. Une conception plus sûre propose un petit nombre de choix visibles : refuser tant que le coffre-fort est verrouillé, approuver un processus connu pour une exécution limitée ou exiger un clic pour l’utilisation d’un identifiant particulier.

Le réglage de clé par appel de Sallyport relève de cette dernière catégorie. L’agent peut demander l’exécution de l’action, mais il ne reçoit jamais la clé API ou SSH en clair. Cela réduit les fuites d’identifiants, tandis que la personne décide toujours si cette requête précise doit quitter la machine.

Ne définissez pas toutes les actions comme nécessitant une approbation par appel. Si une lecture inoffensive déclenche sans cesse des invites, les gens approuveront sans lire. Ajoutez de la friction là où elle préserve le jugement.

La trace d’audit doit résister à un changement contesté

Une piste d’audit doit répondre à trois questions : quel processus d’agent s’est exécuté, quels appels il a effectués et si quelqu’un a modifié la surface disponible avant l’appel. Consigner uniquement la requête finale ne suffit pas lorsque le litige porte sur cette question : « Cet outil était-il disponible lorsque nous avons approuvé la session ? »

Conservez un instantané d’inventaire avec une empreinte stable à côté des enregistrements de session. Notez le nom de l’outil, le schéma canonique, l’identité du serveur et l’heure à laquelle votre client l’a observé. Lorsqu’un changement survient, préservez les deux instantanés et la décision de classification. Vous n’avez pas besoin d’une base de données complexe pour commencer : un enregistrement signé ou inviolable avec la réponse brute de découverte vaut bien mieux qu’une reconstitution orale le lendemain matin.

Sallyport enregistre les exécutions d’agents dans son journal Sessions et les appels individuels dans son journal Activity, tous deux issus d’un même journal d’audit chiffré et chaîné par hachage. Sa commande sp audit verify vérifie cette chaîne hors ligne sur du texte chiffré, sans nécessiter de clé de coffre-fort. C’est un élément de preuve utile après un changement, mais seulement si l’équipe note aussi quel inventaire l’exécution a vu.

Une chaîne de hachage détecte la modification des entrées conservées. Elle ne prouve pas que vous avez enregistré chaque événement dans chaque composant, ni qu’une approbation était judicieuse. Gardez ces affirmations distinctes. Les examens de sécurité perdent en qualité lorsque l’on demande à un même mécanisme de répondre à des questions auxquelles il ne peut pas répondre.

Traitez la découverte dynamique comme un événement de déploiement

Si votre serveur MCP peut modifier ses outils sans redémarrer le client, l’équipe a en pratique déployé une nouvelle surface d’action dans un canal de contrôle actif. Traitez cet événement avec la discipline d’une mise en production : identifiez le responsable, examinez les différences, décrivez l’autorité attendue et créez une trace qu’un enquêteur pourra lire plus tard.

La première action concrète consiste à ajouter un instantané d’inventaire au début de chaque exécution d’agent et à le comparer avant qu’une actualisation ne prenne effet. N’attendez pas un incident spectaculaire. Le renommage discret qui ajoute un seul champ de destination facultatif est exactement le type de changement qui échappe aux personnes occupées et compétentes par ailleurs.