GitHub a rendu disponibles les listes d'autorisation et de refus des serveurs Model Context Protocol (MCP) dans les réglages administrés de Copilot. Une entreprise peut désormais limiter les outils auxquels les agents de développement se connectent en fonction de l'URL d'un serveur distant, de la commande exacte d'un serveur local ou, avec davantage de précautions, de son nom déclaré.

La fonction répond à un problème concret. Un serveur MCP peut donner à un agent accès à un dépôt, une base de données, un navigateur, un ticket d'incident ou un terminal local. Sans politique centrale, chaque développeur peut ajouter un connecteur différent, avec ses propres dépendances, permissions et mécanismes d'authentification. Une liste d'autorisation réduit cette surface, mais elle ne remplace ni l'analyse des capacités du serveur, ni l'isolation de son exécution, ni la gestion des secrets.

La réponse rapide

QuestionRéponse
Que peut contrôler l'entreprise ?Les serveurs MCP distants par URL, les serveurs locaux par commande et arguments, et éventuellement un nom de serveur.
Où la règle s'applique-t-elle ?Dans l'application GitHub Copilot, Copilot CLI et Visual Studio Code selon la documentation actuelle.
Une liste vide bloque-t-elle tout ?Une liste allowedMcpServers vide bloque les serveurs ajoutés, sauf les serveurs intégrés par défaut à Copilot.
Que se passe-t-il si un serveur correspond aux deux listes ?Le refus l'emporte toujours sur l'autorisation.
Plusieurs politiques peuvent-elles se combiner ?Oui. Toutes les couches d'autorisation doivent accepter le serveur ; les listes de refus s'additionnent.
Une allowlist suffit-elle à sécuriser MCP ?Non. Il faut encore examiner les outils exposés, les identités, les secrets, le réseau, le sandbox et la chaîne d'approvisionnement.

Comment fonctionnent les deux listes

Le champ allowedMcpServers définit les serveurs que les utilisateurs peuvent ajouter. Lorsqu'il est absent, les serveurs restent autorisés sous réserve d'une éventuelle règle de refus. Lorsqu'il contient des entrées, seuls les serveurs correspondants passent. Une liste vide revient à bloquer tous les serveurs ajoutés par l'utilisateur, à l'exception des serveurs de première partie intégrés par défaut à Copilot.

Le champ deniedMcpServers constitue une interdiction inconditionnelle. Un serveur qui correspond à une entrée refusée reste bloqué même s'il correspond aussi à une entrée autorisée. Cette priorité évite qu'une règle large telle qu'un domaine approuvé réintroduise par accident une URL expressément interdite.

Lorsque plusieurs sources de réglages sont actives, l'autorisation est une intersection : chaque couche doit laisser passer le serveur. Les refus, eux, se comportent comme une union. Une interdiction définie à un niveau ne peut donc pas être annulée par une configuration plus permissive ailleurs. GitHub indique aussi un comportement de fermeture en cas de correspondance mal formée ou impossible à vérifier.

Un exemple de configuration

Les réglages administrés peuvent notamment être stockés dans copilot/managed-settings.json au sein du dépôt dédié de l'organisation source .github-private. Voici un exemple volontairement restrictif à adapter :

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.com/*" },
    {
      "serverCommand": [
        "npx",
        "-y",
        "@company/mcp-server@1.4.2"
      ]
    }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.unapproved.example/*" }
  ],
  "sandbox": {
    "enabled": true,
    "allowBypass": false,
    "sandboxMcpServers": true
  }
}

Chaque objet de liste doit utiliser un seul type de correspondance. La commande locale inclut l'exécutable et chacun de ses arguments dans leur ordre exact. Modifier une option ou une version change donc l'identité comparée. Cet exemple épingle le paquet au lieu d'employer @latest, afin qu'une nouvelle publication ne soit pas exécutée automatiquement sous une autorisation existante.

La partie sandbox illustre une défense complémentaire, pas une condition obligatoire de la liste MCP. Les clés réellement prises en charge et leur disponibilité doivent être vérifiées pour les clients et offres déployés. Une politique pilote doit être testée avant d'être généralisée.

Identifier correctement un serveur distant

Pour un serveur distant, serverUrl accepte des motifs génériques. GitHub canonicalise les URL avant comparaison : casse, noms de domaine internationalisés, ports par défaut, fragments, points finaux et certains octets encodés sont normalisés. Cette étape réduit les contournements fondés sur deux écritures différentes de la même destination.

Un joker trop large reste néanmoins dangereux. Autoriser tout un domaine partagé peut ouvrir l'accès à un service créé plus tard ou contrôlé par une autre équipe. Il vaut mieux cibler un nom d'hôte et un chemin dédiés, documenter le propriétaire et vérifier le comportement des redirections, du DNS et du proxy d'entreprise.

L'URL ne dit pas tout sur l'identité applicative. Le même point d'entrée peut changer de code, de locataire ou de permissions sans changer d'adresse. Il faut donc compléter la règle par une revue du fournisseur, de l'authentification, des journaux, de la rétention des données et du processus de changement.

Les commandes locales exigent une gestion de dépendances

Un serveur MCP local est souvent démarré par npx, uvx, un binaire ou un conteneur. La règle serverCommand compare exactement la commande et ses arguments, sans expansion de joker. Cette précision permet de bloquer une variante inattendue, mais elle ne garantit pas que le contenu exécuté soit immuable.

Une commande qui télécharge la dernière version d'un paquet à chaque lancement laisse la chaîne d'approvisionnement évoluer derrière une règle stable. Il est préférable d'épingler une version et, lorsque l'outil le permet, un digest ou une somme de contrôle. Un miroir interne, une analyse des dépendances et une procédure de promotion fournissent une assurance supplémentaire pour les outils ayant accès au code source ou au terminal.

Le répertoire de travail, les variables d'environnement et les secrets disponibles au processus comptent également. Deux lancements avec la même ligne de commande peuvent avoir des pouvoirs différents selon la machine. La politique MCP doit donc être reliée à la gestion du poste, aux profils de shell et aux identités techniques.

Pourquoi serverName ne doit pas servir de contrôle de sécurité

GitHub propose une correspondance par nom pour faciliter certains déploiements. Sa documentation avertit toutefois que ce nom est contrôlé par l'utilisateur et peut être modifié. Un serveur non approuvé pourrait reprendre le nom d'un connecteur autorisé.

Le nom convient à la lisibilité ou à une transition, pas à l'identification d'une frontière de confiance. Pour une règle de sécurité, il faut préférer l'URL canonique d'un service distant ou la commande exacte d'un serveur local. Une organisation qui utilise déjà des noms devrait prévoir leur remplacement et rechercher les doublons trompeurs.

Où déployer les réglages

GitHub documente plusieurs niveaux, avec l'ordre de priorité MDM, serveur, fichier, utilisateur. Les réglages servis centralement sont adaptés à une gestion homogène et auditable. Une solution MDM convient lorsque des groupes d'appareils exigent des politiques différentes ou une restriction qui doit rester présente même si un service distant est indisponible.

La configuration par fichier est utile pour certains conteneurs de développement, Codespaces ou environnements où la gestion serveur n'est pas disponible. Les chemins documentés sont /Library/Application Support/GitHubCopilot/managed-settings.json sur macOS, %ProgramFiles%\GitHubCopilot\managed-settings.json sous Windows et /etc/github-copilot/managed-settings.json sous Linux.

GitHub indique que les réglages serveur sont rafraîchis approximativement chaque heure ; un redémarrage ou une nouvelle connexion peut forcer leur récupération. En cas d'échec sans copie en cache, ces réglages peuvent devenir indisponibles. Une restriction qui doit s'appliquer en permanence mérite donc une couche locale administrée en plus de la distribution serveur.

Les angles morts à traiter

La couverture annoncée vise l'application Copilot, Copilot CLI et Visual Studio Code. Les autres clients MCP, scripts autonomes et outils d'IA non administrés ne sont pas automatiquement contrôlés par cette politique. Un inventaire logiciel et des restrictions d'installation restent nécessaires si l'objectif est de gouverner MCP dans toute l'entreprise.

Les serveurs intégrés de première partie fournis par Copilot sont exemptés des listes de refus selon la référence GitHub. Il faut comprendre leurs capacités et les politiques Copilot qui les encadrent, plutôt que supposer qu'une liste vide les désactive.

Le sandbox MCP concerne l'exécution locale dans l'environnement isolé de Copilot CLI. Il ne place pas un serveur distant dans un bac à sable local. Pour les services distants, les contrôles pertinents sont notamment les autorisations OAuth, les comptes de service, la segmentation réseau, les limites d'API et l'audit côté serveur.

Enfin, autoriser un serveur ne signifie pas autoriser chacun de ses outils pour tous les dépôts. Un connecteur peut exposer simultanément une recherche en lecture et une action destructive. Lorsque le serveur ne permet pas de séparer ces capacités, l'approbation doit considérer son pouvoir maximal.

Une méthode de déploiement en dix étapes

  1. inventorier les clients MCP, serveurs, propriétaires et utilisateurs actuels ;
  2. classer les données, outils et actions accessibles par chaque serveur ;
  3. supprimer les connecteurs sans propriétaire ou sans usage démontré ;
  4. épingler les paquets locaux et définir un circuit de mise à jour ;
  5. créer des correspondances précises par URL ou commande, jamais par nom seul ;
  6. ajouter les refus explicites pour les domaines et commandes connus comme indésirables ;
  7. combiner la liste avec sandbox, permissions, réseau et identités à privilège minimal ;
  8. tester les cas autorisés, interdits, mal formés et indisponibles sur chaque client ;
  9. lancer un pilote avec une petite équipe avant le déploiement global ;
  10. journaliser les exceptions, fixer leur expiration et réviser régulièrement la liste.

Les remplacements d'urgence doivent être rares, temporaires et attribués. Une demande d'exception utile contient le serveur, le besoin, les données concernées, le propriétaire, la durée et la stratégie de retrait. Une simple liste qui grandit sans échéance finit par devenir un catalogue d'anciennes décisions.

Une brique de gouvernance, pas une garantie

Les listes MCP administrées donnent aux équipes sécurité un contrôle qui manquait au moment où les connecteurs étaient souvent configurés poste par poste. Leur comportement cumulatif et la priorité du refus facilitent une politique de moindre privilège, tandis que la correspondance exacte des commandes peut réduire les variantes imprévues.

La valeur réelle dépendra de ce qui entoure la liste. Un serveur approuvé peut être compromis, surautorisé ou mis à jour de façon risquée. L'objectif n'est donc pas seulement d'obtenir un fichier JSON valide, mais de maintenir un petit ensemble de connecteurs identifiés, révisés, isolés et observables. C'est à cette condition que MCP devient une capacité gérée plutôt qu'un accès implicite supplémentaire pour chaque agent.