Une connexion peut aller plus loin qu'une permission
GitHub partage les connexions de services entre clients Copilot. Les décisions sur chaque action doivent garder une trace distincte.
GitHub partage les connexions de services entre clients Copilot. Les décisions sur chaque action doivent garder une trace distincte.
Le changement lu aujourd'hui
Le 28 octobre, GitHub a annoncé les GitHub-verified MCP servers, ou connecteurs, en public preview. Une connexion doit fonctionner dans l'application Copilot, le CLI, VS Code, Copilot dans le cloud et GitHub Mobile. J'ai lu cette annonce et la documentation du GitHub MCP Server le 1er novembre. Je n'ai testé aucun client et ne confirme pas une disponibilité dans chaque compte.
Le contrôle change de place
GitHub cite 26 services au lancement, dont Slack, Figma, Notion, Sentry, Linear et Atlassian Rovo. La connexion reste active en arrière-plan. Mon analyse: un nouvel écran de connexion ne signalera plus forcément chaque nouveau point d'accès. Une équipe a besoin d'un inventaire des clients, services et travaux autorisés. Le souvenir d'avoir saisi un mot de passe ne décrit pas la portée actuelle.
Les conditions de la preview
L'annonce vise tous les plans Copilot. Pour Business et Enterprise, un administrateur doit activer Editor preview features. Une liste MCP gérée doit inclure les serveurs vérifiés. Le service peut exiger sa propre autorisation, comme Slack MCP. Ces conditions ne prouvent pas qu'une organisation donnée est prête. L'annonce ne fournit pas les règles complètes de conservation et révocation de chaque service.
Des décisions séparées
Le README du GitHub MCP Server distinct décrit des ensembles d'outils, des outils individuels et un mode read-only qui écarte les écritures même explicitement demandées dans la configuration. Cela ne prouve pas les mêmes réglages pour tout connecteur géré. Un outil disponible ne signifie pas qu'une personne a approuvé un commentaire précis. Je conserverais séparément connexion, configuration et décision sur l'action.
Le test proposé
Dans un dépôt temporaire autorisé avec de faux tickets, lire depuis un client puis ouvrir un second client pris en charge. Demander une proposition de commentaire sans publication. Vérifier le refus d'écriture et le signalement d'une connexion perdue. Révoquer ensuite par la voie documentée et examiner les clients concernés. Ce sont des essais proposés, sans résultat mesuré ni délai de révocation établi.
La trace à garder
Noter client et version, service, libellé du compte, droits, opération, cible exacte et résultat. Un refus du serveur diffère d'un assistant qui choisit de ne pas appeler un outil. Garder l'heure de révocation et de la tentative suivante. Une capture de réglages ne prouve pas une révocation partout. Le JSON ci-dessous illustre une fiche non exécutée, sans mécanisme de contrôle intégré.
{"trial":"proposed_not_run","service":"example","client":"PIN_VERSION","operation":"draft_comment","target":"synthetic_issue","write_approved":false,"revoked_at":null,"observed_result":null}Mon critère
La récupération du contexte doit devenir plus simple, avec une provenance et des limites encore lisibles. Peut-on réduire la portée? Expliquer pourquoi un commentaire est resté brouillon? Le LICENSE du code GitHub MCP Server est MIT; il ne fixe ni conditions du service hébergé, ni prix, ni permissions de compte. Aucun service n'a été connecté pour cet article.