Supprimer les serveurs MCP abandonnés sans laisser d’accès derrière eux

Les serveurs MCP abandonnés méritent le même traitement que les scripts de déploiement oubliés : partez du principe qu’ils fonctionnent encore jusqu’à preuve du contraire. Une ancienne entrée peut lancer une commande locale, diriger un agent vers un point de terminaison distant, exposer une vieille variable d’environnement ou conserver un chemin vers un identifiant dont plus personne n’est responsable.

J’ai vu des développeurs supprimer un bloc de configuration, considérer le travail terminé, puis découvrir des mois plus tard que le même outil se lançait encore depuis une extension d’éditeur ou un fichier du dépôt. La solution n’est pas un tableur plus volumineux. Il faut séparer la découverte, la révocation, la suppression et la preuve que le chemin d’accès est bien fermé.

Une configuration supprimée ne révoque pas un chemin d’accès

Supprimer des serveurs MCP abandonnés signifie fermer tous les chemins qui permettent à un agent d’effectuer une action, et pas seulement masquer un serveur dans le menu d’un client. La définition du serveur n’est qu’une partie de ce chemin.

Une configuration locale classique comporte quatre éléments : la configuration du client, la commande de lancement, la configuration ou l’environnement transmis à cette commande, et l’autorité détenue auprès du service cible. Dans une configuration distante, la commande locale est remplacée par une URL, mais la configuration du client et l’autorité distante restent nécessaires. Les équipes suppriment souvent le premier élément et laissent les autres en place.

La spécification du Model Context Protocol décrit les serveurs comme des fournisseurs de capacités telles que des outils, des ressources et des prompts. Elle prend aussi en charge plusieurs transports, notamment stdio et les connexions fondées sur HTTP. Cette distinction compte lors du retrait. Un serveur stdio peut ne s’exécuter que lorsqu’un client local lance sa commande. Un service distant peut rester disponible même après que tous les développeurs ont supprimé l’entrée locale qui y menait.

Ne mélangez pas ces notions :

• Un enregistrement de configuration indique à un client donné où trouver un serveur.
• Un lanceur est l’exécutable, le script, la commande de conteneur, l’extension ou le service qui le démarre ou l’atteint.
• Une autorisation est le jeton, l’identité SSH, l’autorisation OAuth, la session de compte ou la permission réseau qui permet à l’action d’aboutir.
• Un enregistrement d’exécution montre qu’un client ou un agent a réellement utilisé le chemin.

Une mauvaise distinction entraîne deux conséquences indésirables. Vous pouvez laisser un ancien outil accéder aux données de production, ou révoquer un identifiant dont un outil actif a encore besoin et transformer un nettoyage courant en incident.

Commencez par une règle de retrait claire : si un serveur n’a pas de propriétaire actuel, de fonction documentée ni de preuve d’une utilisation récente et prévue, désactivez-le pendant l’enquête. « Nous en aurons peut-être besoin un jour » ne constitue pas une responsabilité. Un dépôt peut conserver la procédure de reconstruction en privé, avec un nouvel identifiant, si quelqu’un doit un jour la réutiliser.

Inventoriez les clients avant de chercher sur le disque

Votre premier inventaire doit lister les clients, pas les serveurs, car chaque client lit la configuration à des emplacements différents. Les développeurs ont souvent plusieurs clients d’agents installés, ainsi qu’une intégration d’éditeur, un utilitaire de terminal et des paramètres propres au projet, enregistrés à côté du code.

Notez chaque emplacement capable d’initier une connexion MCP sur la machine. Incluez les applications de bureau, les agents en ligne de commande, les extensions d’IDE, les scripts locaux qui invoquent un agent et tout environnement de développement distant qui monte le répertoire personnel. Demandez au développeur ce qu’il utilise réellement, puis vérifiez-le. La mémoire est une preuve médiocre lorsqu’un outil n’a été lancé qu’une fois, six mois plus tôt, pendant un prototype.

Pour chaque client, consignez sa version, les emplacements de configuration indiqués dans sa propre documentation et la prise en charge éventuelle de paramètres utilisateur et de paramètres de projet. Ne devinez pas un chemin parce qu’un autre client l’utilise. Les emplacements changent et un chemin inventé donne une fausse confiance.

Une ligne d’inventaire utile contient assez de détails pour permettre une décision de retrait :

Les paramètres de projet provoquent le plus de surprises. Un développeur peut nettoyer sa configuration personnelle et continuer à lancer un serveur chaque fois qu’il ouvre un ancien dépôt. Recherchez dans la branche actuelle, les fichiers ignorés utilisés pour la configuration locale, les fichiers de configuration d’exemple et les scripts d’intégration. Examinez aussi les dépôts partagés de fichiers dot. Un ancien serveur survit souvent parce qu’une personne a copié un extrait pratique dans un modèle.

Ne considérez pas l’inventaire comme un document de conformité. Utilisez-le pour piloter les actions. Si vous ne pouvez pas nommer le système cible et la source de l’autorité d’un serveur, marquez-le comme non résolu et empêchez son utilisation occasionnelle tant que vous ne disposez pas de ces informations.

Cherchez les lanceurs, pas seulement les fichiers nommés MCP

Une recherche textuelle sur « mcp » trouve les configurations évidentes, mais les lanceurs se cachent dans des scripts aux noms génériques et des exécutables de paquets. Recherchez le nom du serveur, le nom de la commande, le nom d’hôte, le port, le nom du paquet et les noms de variables d’environnement révélés par l’inventaire.

Sur macOS, cette commande fournit un premier ensemble limité de fichiers JSON probablement pertinents dans un répertoire personnel. Elle ignore volontairement l’arborescence du cache, qui produirait sinon une quantité de métadonnées de paquets sans intérêt.

find "$HOME" -type f \( -name '.mcp.json' -o -name 'mcp.json' -o -name '*mcp*.json' \) \
  -not -path "$HOME/Library/Caches/*" \
  -print 2>/dev/null

Le résultat peut ressembler à ceci :

/Users/dev/work/acme-api/.mcp.json
/Users/dev/Library/Application Support/example-client/settings.json
/Users/dev/.config/example-agent/mcp.json

Cette liste constitue une preuve, pas une liste de suppression. Ouvrez chaque fichier et identifiez le client qui en est responsable. Un nom de fichier contenant mcp peut désigner une documentation, une expérience archivée ou un fichier de verrouillage généré. À l’inverse, un fichier de paramètres au nom banal peut contenir la véritable définition du serveur.

Pour les fichiers JSON dont le schéma utilise un objet mcpServers, cette commande affiche un tableau de vérification compact. Elle ne modifie aucun fichier.

jq -r '
  .mcpServers // empty
  | to_entries[]?
  | [.key, (.value.command // .value.url // "unknown"),
     ((.value.args // []) | join(" "))]
  | @tsv
' path/to/config.json

Un résultat courant ressemble à ceci :

issue-tracker	npx	-y @example/issues-mcp
legacy-reporting	https://reports.internal.example/mcp	

Si la commande ne produit rien, n’en déduisez pas que le fichier est sans danger. Le fichier peut utiliser un autre schéma, le client peut stocker ses paramètres ailleurs ou le service peut être fourni par une extension.

Examinez ensuite les surfaces de lancement qui survivent à un nettoyage ordinaire des fichiers. Sur Mac, regardez les profils du shell, les paramètres des tâches de l’éditeur, les exécutables globaux du gestionnaire de paquets et les agents de lancement de l’utilisateur. launchctl print gui/$(id -u) peut révéler les processus lancés sous l’utilisateur connecté, mais sa sortie peut exposer des arguments de commande ou des valeurs d’environnement. Consultez-la localement et ne la copiez pas dans un ticket ou une conversation.

Recherchez le contenu avec des termes ciblés plutôt que de parcourir et d’exporter tout le répertoire personnel. Par exemple, si vous savez qu’un serveur abandonné appelle old-report, recherchez ce nom exact, son ancien nom d’hôte et son exécutable. Cette méthode trouve des wrappers tels que scripts/agent-tools.sh sans transformer une vérification de nettoyage en collecte de données privées.

Classez chaque serveur selon son autorité actuelle

Un serveur peut sembler inactif tout en détenant une autorité valide. Classez-le donc selon son mode d’authentification avant de toucher à ses fichiers. Le même nom de serveur peut utiliser des identifiants différents selon les machines. C’est pourquoi un retrait à l’échelle de l’équipe demande des preuves propres à chaque machine.

Utilisez cinq catégories pratiques. Elles décrivent l’emplacement du pouvoir, pas la manière dont le serveur se présente.

1. Aucune autorité distante. Le serveur lit des fichiers locaux non sensibles ou produit une sortie locale. Il peut toujours poser un problème de chaîne d’approvisionnement ou de confidentialité, mais la révocation consiste généralement à retirer ses permissions de processus et sa configuration.
2. Autorité fournie par l’environnement. Le lanceur reçoit un jeton API, un mot de passe ou une chaîne de connexion par l’intermédiaire d’un profil shell, d’un fichier .env, d’un paramètre d’IDE ou d’une configuration de lancement.
3. Autorité fournie par un fichier. Le lanceur lit une clé privée SSH, un certificat client, un fichier de compte de service ou une base locale d’identifiants.
4. Autorité gérée par un fournisseur. Le serveur utilise OAuth, une installation d’application, une connexion d’appareil ou une identité gérée. C’est le fournisseur, et non un fichier texte local, qui contrôle l’autorisation.
5. Autorité réseau et compte. Le serveur n’a pas besoin de secret explicite, car un réseau d’entreprise, un compte local, une session VPN ou une adresse autorisée lui permet d’atteindre un service. Cette catégorie est facile à manquer et difficile à retirer proprement.

Consignez le compte exact, la portée et la cible de chaque source d’autorité. « Jeton Git » ne suffit pas. Vous devez savoir s’il appartient à un compte personnel, à un compte robot ou à une identité machine partagée, et s’il peut lire des dépôts, écrire des tickets, déclencher des déploiements ou accéder à des API d’administration.

C’est à ce stade que le nettoyage révèle les raccourcis gênants. Une commande MCP locale qui reçoit un jeton personnel étendu par ~/.zshrc ne devient pas inoffensive parce que le développeur a cessé de l’utiliser. Le jeton peut aussi alimenter d’autres scripts, et sa révocation demande donc une coordination. Ce n’est pas une raison pour repousser le travail, mais une raison de cartographier les dépendances avant la révocation.

Restez factuel dans l’inventaire. N’y placez pas les valeurs des jetons, les clés privées, les en-têtes d’autorisation complets ou des copies de configurations. Une référence telle que « entrée d’identifiant nommée reporting-read » ou « empreinte SSH se terminant par 3f:91 » permet à la bonne personne de retrouver l’autorité sans créer un nouveau dépôt de secrets.

Révoquez auprès du service avant de supprimer les traces locales

Révoquez l’autorité active auprès du fournisseur ou du service cible avant de supprimer la configuration locale. Cet ordre empêche une configuration copiée, une autre machine ou un lanceur passé inaperçu de continuer à utiliser la même autorisation.

Pour les jetons API, utilisez l’interface de gestion des jetons du fournisseur ou son point de terminaison de révocation documenté. Confirmez le jeton à révoquer avec son identifiant, son libellé, son compte, ses informations de création ou son dernier relevé d’utilisation, si le fournisseur en fournit un. Supprimez ensuite sa valeur des fichiers locaux et des magasins d’identifiants. Ne testez jamais un jeton révoqué en le collant dans un formulaire web ou une commande shell susceptible d’être conservée dans l’historique.

OAuth demande une attention particulière. La RFC 7009 définit une demande de révocation de jeton envoyée au point de terminaison de révocation du serveur d’autorisation. Elle permet aussi au serveur de renvoyer une réponse positive même si le jeton est invalide, afin d’empêcher les appelants de savoir si un jeton existe. Un statut 200 ne prouve donc pas à lui seul que vous avez révoqué l’autorisation visée. Vérifiez la vue des autorisations ou des applications connectées du fournisseur, puis effectuez un appel contrôlé via l’ancien chemin uniquement si vos pratiques de sécurité habituelles l’autorisent.

Pour SSH, supprimez la clé publique ou la clé de déploiement de chaque endroit qui l’accepte. Cela peut inclure les clés autorisées d’un compte, les paramètres de clés de déploiement d’un dépôt, un compte bastion, un service CI et une source de gestion de configuration qui réinjecte authorized_keys. Supprimer ~/.ssh/old_agent_key ne retire qu’une copie locale. Cela ne fait rien aux autres copies ni à l’autorisation côté serveur.

Pour les installations d’applications et les comptes de service, désactivez ou supprimez l’installation, faites tourner le secret client ou l’identifiant privé si une exposition est plausible, et retirez les attributions de rôles qui n’existaient que pour le serveur retiré. Considérez les rôles étendus comme un élément à nettoyer même si le compte de service reste actif. Un outil d’agent a rarement besoin des mêmes accès qu’un administrateur humain.

Les accès fondés sur le réseau nécessitent une autre discussion. Supprimez les entrées d’autorisation, les règles de pare-feu, l’appartenance à un groupe VPN ou les routes DNS internes seulement après avoir identifié leurs propriétaires et leurs utilisateurs. Ne profitez pas d’un ticket de nettoyage MCP pour casser une intégration sans rapport. Isolez plutôt la règle concernée et fixez à son propriétaire une date limite pour confirmer son utilisation.

Consignez le résultat de la révocation comme un événement : personne qui l’a effectuée, identifiant de l’autorité révoquée, emplacement de l’opération et méthode de vérification. Évitez d’enregistrer des secrets ou des captures d’écran qui en contiennent. Cette trace est utile lorsqu’un dépôt tombe en panne et que quelqu’un demande si le nettoyage en est la cause.

Supprimez les définitions locales dans un ordre réversible

Après la révocation en amont, supprimez les définitions locales selon une séquence qui conserve un chemin de restauration privé sans conserver d’identifiants actifs. Une désinstallation précipitée peut rendre impossible l’explication des dépendances d’un projet. Une archive trop prudente peut garder un jeton utilisable dans un dossier oublié. Séparez la configuration des secrets.

Suivez cette séquence pour un serveur à la fois :

1. Arrêtez le client d’agent et l’extension d’éditeur concernés. Un client en cours d’exécution peut conserver un processus enfant ou réécrire ses paramètres à la fermeture.
2. Copiez les champs de configuration non sensibles du serveur dans le relevé de retrait : nom, commande ou URL, arguments, cible attendue, propriétaire et date de suppression. Remplacez les valeurs secrètes par une description de leur emplacement.
3. Révoquez l’autorité auprès du service cible et consignez les détails de confirmation.
4. Supprimez l’entrée du serveur de toutes les configurations utilisateur et projet identifiées. Supprimez les variables d’environnement et les références aux fichiers d’identifiants retirés.
5. Désinstallez le paquet dédié, l’extension, l’image de conteneur ou le script wrapper si aucun serveur actif ne l’utilise. Si d’autres activités utilisent ce paquet, retirez seulement la commande abandonnée et documentez la dépendance partagée.

Évitez les remplacements généralisés. Les virgules JSON, les guillemets du shell et les blocs d’environnement partagés sanctionnent les modifications faites à la légère. Utilisez l’interface de paramètres du client lorsqu’elle produit de manière fiable une configuration valide. Sinon, créez une sauvegarde avec des permissions restrictives, modifiez un seul objet et validez le résultat avant de rouvrir le client.

Pour le JSON, jq fournit une vérification syntaxique simple :

jq empty path/to/config.json && echo "valid JSON"

Cela prouve que le JSON peut être analysé. Cela ne prouve ni que le client accepte le schéma ni que vous avez supprimé toutes les références. Relisez l’objet concerné après la modification, puis utilisez le client pour examiner sa liste de serveurs configurés.

N’archivez pas un fichier .env complet, une clé privée ou un fichier de paramètres contenant un jeton bearer dans un dossier archive du projet. Le contrôle de version, les sauvegardes cloud et la recherche sur le bureau feraient voyager cette erreur très loin. Conservez une trace expurgée et appuyez-vous sur l’historique d’audit du fournisseur pour établir que l’ancien identifiant existait.

La suppression d’un paquet demande aussi de la retenue. Un paquet d’exécution installé globalement peut servir à plusieurs outils actifs. Avant de le supprimer, vérifiez quel nom d’exécutable chaque configuration active invoque. J’ai vu un nettoyage retirer une dépendance d’exécution partagée, puis obliger une autre équipe à déboguer une session d’agent cassée, parce que le message d’erreur signalait un paquet manquant plutôt que l’outil supprimé.

Prouvez que rien ne démarre ni n’atteint le serveur retiré

Un retrait est terminé lorsque les clients concernés ne peuvent plus découvrir, lancer ni authentifier le serveur. La seule vérification de la configuration ne prouve aucune de ces choses.

Redémarrez complètement le client. Fermer une fenêtre peut ne pas arrêter un utilitaire de barre des menus, un hôte d’éditeur ou un processus enfant. Rouvrez le client et examinez sa liste de serveurs configurés avec ses diagnostics habituels. Si le serveur retiré y apparaît, vous avez manqué une source de configuration ou un mécanisme de synchronisation l’a restauré.

Effectuez ensuite un test de lancement ciblé. Ouvrez le dépôt qui fournissait autrefois la configuration du serveur, démarrez l’agent et demandez-lui une action sans danger, sans rapport avec le serveur retiré. Observez l’activité des processus locaux pour repérer l’ancien nom d’exécutable et examinez les journaux du client à la recherche de tentatives de connexion vers l’ancien nom d’hôte. N’invoquez pas l’outil retiré contre une cible de production active simplement pour vérifier son échec.

Pour les points de terminaison distants, consultez les relevés d’audit du fournisseur, les journaux d’accès ou l’activité du compte afin de rechercher une utilisation après la révocation. Une requête refusée après un test contrôlé prouve que l’autorisation ne fonctionne plus. Le silence d’un journal apporte une preuve plus faible, car le client n’a peut-être jamais tenté la connexion.

Vérifiez aussi que l’ancien identifiant n’apparaît plus là où il ne devrait pas. Recherchez son libellé, le nom de sa variable d’environnement, le nom d’hôte connu, le nom de fichier et l’empreinte publique SSH. Ne recherchez pas la valeur complète d’un secret si elle risque de finir dans l’historique du shell, le contenu défilant du terminal ou un journal de commandes. Le libellé et la référence suffisent généralement.

Voici un échec typique : un développeur supprime legacy-reporting de la configuration de son agent personnel, redémarre l’agent et ne voit rien. Une semaine plus tard, il ouvre un ancien dépôt. Les paramètres locaux lancent npx avec un ancien paquet, le script charge REPORTING_TOKEN depuis un profil shell et l’API distante accepte encore le jeton. Chaque vérification individuelle semblait correcte parce qu’elle ne portait que sur la configuration personnelle. L’inventaire aurait dû relier la configuration du dépôt, le lanceur, la source d’environnement et l’autorisation API avant le début du retrait.

Conservez les preuves sans créer un nouveau cache de secrets

Conservez suffisamment de preuves pour expliquer un retrait, mais ne transformez pas votre dossier d’audit en archive d’accès utilisables. Le relevé doit permettre à un autre ingénieur de répondre à quatre questions : ce qui existait, ce qui pouvait être atteint, qui a approuvé le retrait et quelle preuve l’a clôturé.

Un relevé de retrait compact peut contenir l’identifiant du serveur, les emplacements locaux supprimés, la commande ou le point de terminaison sans les identifiants, le service cible, le type d’autorité, l’identifiant de l’autorisation ou l’empreinte, la date de révocation, le propriétaire et le résultat de la validation. Placez les notes opérationnelles protégées par contrôle d’accès là où votre équipe gère déjà les dossiers de sécurité. Ne créez pas un nouveau document partagé rempli de paramètres copiés.

L’historique d’exécution peut révéler des dépendances que l’inventaire ne montre pas. Examinez l’historique des sessions d’agent, les journaux du client, l’historique d’installation du gestionnaire de paquets, les changements du contrôle de version ayant ajouté la configuration et l’activité du service cible. Interprétez les horodatages avec prudence. Un journal peut montrer qu’un processus s’est exécuté sans prouver qu’un outil a terminé une action privilégiée.

Sallyport enregistre les exécutions d’agents et chaque appel HTTP ou SSH dans des journaux distincts, projetés depuis un journal d’audit chiffré en écriture seule. Lorsqu’une équipe l’utilise, sp audit verify peut vérifier hors ligne la chaîne d’audit sur le texte chiffré, sans nécessiter la clé du coffre. Cela aide à préserver les preuves pendant une vérification des accès.

Ne confondez pas la preuve d’altération avec un inventaire complet. Un journal n’enregistre que les actions qui sont passées par son point de journalisation. Il ne révélera pas un ancien serveur exécuté en dehors de ce point, une configuration oubliée que personne n’a lancée ou un jeton copié utilisé directement par un autre script.

Faites expirer la responsabilité avant que les outils ne deviennent des vestiges

Le nettoyage est moins pénible lorsque les équipes attribuent un propriétaire et une date de vérification dès l’installation. Cette règle semble administrative jusqu’au jour où vous devez comprendre pourquoi un agent peut encore atteindre une API dont le projet d’origine s’est terminé il y a des années.

Demandez un court plan de retrait chaque fois qu’une personne ajoute un serveur disposant d’un accès en écriture, d’une visibilité sur la production ou d’un accès étendu aux dépôts. Le plan doit indiquer le propriétaire, les dépôts prévus, le type d’autorité, les systèmes cibles et l’événement qui déclenchera le retrait. Un prototype peut avoir une date de vérification rapprochée. Un outil partagé peut avoir un mainteneur nommé. Aucun des deux ne doit bénéficier d’une exception permanente et anonyme.

Utilisez les configurations de dépôt avec mesure. Un serveur au niveau du projet convient lorsque le projet en a réellement besoin et que sa configuration n’intègre aucun identifiant. C’est un mauvais emplacement pour les expérimentations personnelles d’un développeur. Gardez les essais dans un espace privé et jetable, puis donnez-leur un propriétaire ou supprimez-les avant que l’arborescence de travail ne devienne un modèle.

Effectuez une vérification après les changements de client d’agent, les transferts d’équipe, l’archivage d’un dépôt et la rotation des identifiants. Ces événements révèlent la dérive plus sûrement qu’un rituel calendaire arbitraire. Si la vérification trouve un serveur inconnu, suspendez d’abord son accès aux systèmes sensibles, puis retracez son propriétaire et ses dépendances. Un outil que personne ne peut expliquer ne doit pas conserver la permission d’agir.

Le prochain nettoyage devrait commencer par une vraie machine et un seul client actif. Construisez l’inventaire jusqu’à ce que chaque serveur ait un propriétaire, un chemin de lancement et une source d’autorité. Les entrées qui ne répondent pas à ce standard vous ont déjà indiqué ce qu’il faut retirer.