9 min de lecture - Sandbox local GitHub Copilot : testez la politique avant le déploiement

GitHub a généralisé le sandbox local le 7 octobre 2026 dans Copilot CLI, l’application GitHub Copilot et les sessions VS Code qui utilisent Agent Host. Les commandes lancées par Copilot peuvent désormais s’exécuter sous une politique qui limite l’accès aux fichiers, au réseau, aux identifiants et à d’autres capacités du système.

Cette version apporte une couche de contrôle utile aux postes de développement, sans rendre chaque session locale approuvée. GitHub documente des réglages par client, des différences entre systèmes et une voie facultative de contournement.

La question d’adoption est précise : pouvez-vous prouver la politique effective pour le client, le poste et la tâche avant que l’agent accède à un vrai dépôt ? Un petit test d’acceptation peut y répondre.

La disponibilité générale apporte un contrôle exploitable

L’annonce de GitHub indique que le sandbox local couvre Copilot CLI, l’application Copilot et les sessions VS Code Agent Host. Elle distingue aussi l’exécution du modèle de l’isolation des outils : vous pouvez changer de modèle sans modifier la politique de sandbox appliquée aux outils.

Microsoft eXecution Container (MXC) fournit la couche multiplateforme. Son dépôt public répertorie plusieurs moteurs natifs : ProcessContainer sous Windows, Bubblewrap sous Linux et Seatbelt sous macOS. Un modèle de politique commun simplifie la gestion, mais le poste reste déterminant, car chaque moteur dépend de mécanismes propres au système.

Cette version justifie un pilote contrôlé, sans prouver qu’une politique a déjà été choisie. Un réglage administré peut imposer le sandbox ; un réglage local peut le laisser désactivé.

Lisez les valeurs par défaut avant d’écrire la politique

Le guide de configuration locale de GitHub documente plusieurs valeurs par défaut à inscrire dans la revue des risques :

L’application et la CLI ont des configurations séparées ; un changement n’atteint la session qu’après son redémarrage. Le résumé de l’application ne prouve pas que le sandbox fonctionne et ne montre pas toutes les restrictions. Dans la CLI, /sandbox policy affiche la politique effective.

Rédigez l’approbation à partir de ce résultat. « Sandbox Copilot activé » reste trop vague pour reproduire le contrôle.

Partez de la tâche, puis accordez les accès

Supposons qu’une équipe confie à l’agent la correction de tests et la préparation d’une pull request. Ce pilote fictif exige le dépôt, le registre de paquets, l’outil de test et peut-être le droit de créer une branche. Les identifiants cloud de production, les autres dépôts et le réseau du bureau restent hors scope.

Transformez cette tâche en contrat d’accès court :

• Pour les fichiers, limitez la lecture et l’écriture au checkout jetable. Bloquez les exports clients, les dossiers personnels, le matériel SSH et les CLI cloud. Les caches de développement peuvent contenir des jetons.
• Pour le réseau, autorisez uniquement la source, le registre et les mises à jour requises. Si le test exige un service local, inscrivez son nom et son port dans le compte rendu.
• Débutez sans Git ni GitHub CLI. Ajoutez un identifiant limité à la tâche seulement si la session doit pousser la branche ou créer la pull request.
• Inventoriez MCP et LSP. GitHub peut imposer le sandbox aux processus locaux lancés par la session ; les serveurs MCP distants restent hors de cette limite locale.

Chaque échec révèle une dépendance implicite. Examinez-la avant d’accorder la capacité manquante.

Prouvez la politique effective avec des sondes sans danger

Sur un dépôt jetable, placez des marqueurs non sensibles dans un fichier autorisé, un fichier bloqué, une variable qui simule un identifiant et un point d’accès HTTP local. Testez la sortie avec un service distant contrôlé, sans envoyer de secret.

Consignez le client, le système, la politique et la session, puis exécutez ces sondes :

1. Lisez et modifiez le marqueur autorisé ; le diff doit correspondre à l’attendu.
2. Tentez de lire et d’écraser le marqueur bloqué ; les deux opérations doivent échouer sans le révéler.
3. Interrogez un hôte autorisé puis un hôte bloqué. Conservez le résultat et la règle appliquée.
4. Tentez l’accès au réseau local, l’authentification Git, l’authentification gh et une demande de contournement du sandbox. Chaque résultat doit correspondre au contrat écrit.
5. Démarrez chaque MCP ou LSP approuvé, puis répétez par cet outil les sondes utiles.
6. Redémarrez la session et inspectez de nouveau la politique effective.

Gardez un contrôle positif pour l’installation, les tests et la modification prévue. Un environnement cassé peut paraître sûr uniquement parce qu’il ne sait rien exécuter.

Pour les déploiements administrés par l’entreprise, la référence des réglages GitHub décrit enabled: true, qui impose le sandbox, et failIfUnavailable: true, qui bloque le modèle et les outils si la politique ne peut pas être appliquée. allowBypass: false ferme la voie de contournement normale. Évaluez ces options selon votre contexte.

Testez chaque plateforme au lieu de supposer leur équivalence

Une même politique peut produire un comportement différent. Les prérequis de GitHub exigent des versions récentes de Windows 11, et Bubblewrap avec slirp4netns sous Linux. Sous Windows, un chemin bloqué non garanti fait échouer la commande.

Le réseau présente une autre différence. La documentation des réglages réseau administrés indique que les règles d’hôtes empêchent les connexions directes sous macOS et Linux. Sous Windows, elles dépendent du respect du proxy par les programmes ; elles n’offrent donc pas la même protection. Inscrivez cette différence dans le résultat et le risque résiduel.

N’approuvez pas « Windows, macOS et Linux » après un essai sur un seul portable. Approuvez la combinaison testée du client, de sa version, du système et de la politique. Ajoutez une autre combinaison après son passage par les mêmes sondes.

Séparez autorisation du dépôt, revue et sandbox

Un sandbox limite ce qu’un processus peut atteindre. Il ne décide pas ce qu’un jeton GitHub injecté peut faire dans un dépôt autorisé, ne prouve pas qu’une dépendance est digne de confiance et ne rend pas correct le diff produit par l’agent.

La fiche OWASP sur le développement sécurisé avec l’IA traite issues, pull requests, commentaires et instructions comme des entrées non fiables. Elle conseille aussi des outils autorisés, un contrôle réseau, des identifiants limités et la revue de chaque fichier. Ce guide indépendant ne certifie pas Copilot.

Conservez trois contrôles à côté du sandbox :

• des règles de dépôt et un identifiant qui ne peut pas les contourner ;
• une revue complète du diff, avec des responsables nommés pour les fichiers CI, de déploiement et d’instructions destinées aux agents ;
• des journaux qui relient la demande source, la politique effective, les appels d’outils, les décisions de contournement et le commit final.

Notre test des exclusions de contenu Copilot couvre le contenu que l’assistant peut utiliser. Le guide d’achat ou de construction d’un assistant de code sécurisé aide à comparer les contrôles du produit. Ces examens et l’isolation à l’exécution restent complémentaires.

Décidez du déploiement à partir des preuves

Un pilote tient en quatre étapes : inventaire des tâches, clients, postes, MCP et identifiants ; politique minimale et marqueurs synthétiques ; sondes par combinaison ; ouverture de la tâche acceptée à un petit groupe. Examinez les blocages, contournements, diffs inattendus et changements de politique avant d’élargir.

Avancez si l’équipe reproduit la politique, explique chaque autorisation, détecte un échec du sandbox et écarte les identifiants de production. Suspendez si le parcours dépend d’un large réseau local, d’identifiants durables, de MCP non examinés ou d’un contournement habituel.

La version est utile parce qu’elle rapproche les contrôles de l’agent local du système d’exploitation. Le succès du déploiement dépend toujours de la politique que vous pouvez prouver, pas de la case que vous pouvez montrer.

Sources et limites

Nous avons ouvert et examiné toutes les sources ci-dessous le 8 octobre 2026.

• L’annonce de GitHub du 7 octobre établit la disponibilité générale, les clients couverts, les domaines de politique, l’usage de MXC et la séparation entre le choix du modèle et l’isolation des outils.
• Le guide de configuration du sandbox local de GitHub documente les prérequis, réglages propres à chaque client, valeurs par défaut, inspection de la politique effective, accès aux identifiants, contournement et différences réseau entre plateformes.
• La référence GitHub des réglages administrés définit les restrictions minimales, le blocage en cas d’indisponibilité, le contrôle du contournement, les réglages MCP et LSP, les identifiants et les limites propres aux plateformes.
• Le dépôt MXC de Microsoft documente le modèle de politique et les moteurs d’isolation natifs utilisés sous Windows, Linux et macOS.
• La fiche OWASP sur le développement sécurisé avec l’IA apporte un guide indépendant sur le contenu non fiable des dépôts, les accès des outils, l’isolation à l’exécution, les identifiants et la revue des diffs.

Nous n’avons pas testé Copilot, MXC ou une politique d’entreprise, inspecté l’implémentation interne, tenté une sortie de sandbox ni mesuré la productivité. Le produit et sa documentation peuvent changer. Ces sondes forment un exercice proposé, pas une certification, un avis juridique ou une affirmation sur un environnement d’Exceev ou d’un client.