Un agent reçoit une consigne, ouvre quelques fichiers, lance un outil puis propose une modification. Si le résultat surprend l’équipe, deux questions se posent : quelles actions l’agent pouvait-il effectuer, et que s’est-il passé pendant cette session ? Une sandbox limite certaines actions. Des traces d’observabilité aident à reconstruire le déroulement. Il faut les traiter comme deux contrôles complémentaires.
GitHub a annoncé l’export OpenTelemetry pour Copilot app le 22 septembre 2026, puis une sandbox locale le 23 septembre. Le premier changement permet à une organisation de configurer l’export de données d’activité d’agents vers des outils de supervision compatibles. Le second limite l’accès local aux fichiers, au réseau et à certains identifiants. Les annonces concernent le client Copilot app ; elles ne permettent pas de déduire le comportement de Copilot CLI, des sessions distantes ou des autres intégrations.
Commencer par identifier le client et la session
Le nom Copilot désigne plusieurs expériences. Avant une qualification, écrivez le client concerné, son mode d’exécution, la version utilisée, le type de session et la source de configuration. L’annonce de sandbox du 23 septembre précise que la fonctionnalité vise les sessions locales sur un dépôt et un arbre de travail locaux. Elle ne s’applique pas aux sessions dans un environnement cloud ni aux sessions sur hôte distant. Les paramètres de Copilot app et ceux de Copilot CLI sont configurés séparément.
L’activation locale est désactivée par défaut dans l’annonce. Un administrateur ou un développeur doit ouvrir les réglages du projet et activer la sandbox pour les nouvelles sessions, ou activer celle d’une session avec /sandbox on. La seconde action ne change pas le réglage par défaut du projet. Les paramètres modifiés s’appliquent aux nouvelles sessions ou à une session relancée. Une session déjà ouverte n’est donc pas une preuve que la configuration de demain est la même.
GitHub présente la sandbox comme une préversion publique susceptible d’évoluer. Les réglages du projet décrivent la politique demandée au démarrage ; des paramètres gérés par l’entreprise peuvent la rendre plus restrictive. L’annonce indique également que si le système d’exploitation ne peut pas appliquer la politique demandée, le shell sandboxé échoue au lieu de continuer sans isolation. Il est essentiel de tester ce comportement d’échec : un bouton activé n’est pas en soi la preuve que chaque frontière fonctionne sur toutes les machines.
Établir les limites sans chercher à les contourner
La sandbox de Copilot app expose trois domaines de réglage décrits par GitHub : l’accès au système de fichiers (autorisations de lecture et d’écriture supplémentaires, lecture seule et dossiers interdits), les connexions réseau sortantes et locales, et certains identifiants Git utilisés pour les opérations HTTPS ou l’authentification GitHub CLI. Cette liste sert de point de départ à un inventaire, pas de garantie que l’application peut contrôler chaque action du système.
Pour une évaluation inoffensive, préparez un dépôt de démonstration fictif avec un fichier autorisé et un dossier témoin interdit. Demandez à l’agent une lecture du fichier autorisé, puis une tentative d’accès au dossier interdit. Notez le résultat attendu, le refus observé et le journal technique disponible. Ne testez pas avec des secrets ou des données de salariés ; ne cherchez pas à désactiver une règle d’entreprise pour obtenir un résultat favorable. Si l’isolation ne peut être imposée, traitez le refus de démarrer comme le résultat de sécurité prévu, pas comme un défaut qu’il faudrait contourner.
La sandbox réduit l’espace d’action du processus selon une politique. Elle ne prouve pas qu’une suggestion produite est correcte, qu’une modification demandée est sûre ou que les privilèges utilisés sont adaptés. Continuez à examiner les changements proposés et à appliquer la revue de code, les règles d’accès et les contrôles habituels.
Envoyer des traces avec un objectif clair
OpenTelemetry, souvent abrégé OTel, est un ensemble de conventions et d’outils pour décrire des traces, métriques et journaux de systèmes. Le changement Copilot app annoncé le 22 septembre permet de configurer la télémétrie via les paramètres gérés de l’entreprise, notamment dans managed-settings.json, avec une destination d’export. GitHub présente comme cas d’usage l’analyse des sessions d’agents, l’examen d’étapes lors d’un comportement inattendu et la gestion centralisée du suivi.
Selon cette annonce, le contenu des prompts et des réponses est exclu par défaut. Cela ne prouve pas que toute télémétrie possible soit dénuée d’information sensible, ni que les paramètres n’aient aucune option de capture de contenu. Avant d’activer l’export, consignez quels événements et champs partent, vers quel endpoint, quels rôles y accèdent, combien de temps les données sont gardées et comment une configuration de capture de contenu est traitée. L’équipe sécurité, l’administrateur de la plateforme et le responsable de la rétention doivent connaître le périmètre retenu.
Une trace d’agent peut aider à comprendre l’ordre des appels à des outils ou services. Elle ne constitue pas à elle seule une preuve que l’action était autorisée ou que le contenu observé est complet. Évitez le suivi individuel des salariés comme finalité implicite. Définissez plutôt des événements utiles à l’exploitation — erreurs d’accès, interruptions, échecs d’export — et limitez les personnes autorisées à consulter les données.
| Contrôle | Question de qualification | Exemple de preuve à conserver |
|---|---|---|
| Sandbox | Les limites fichiers, réseau et identifiants effectives sont-elles connues ? | Configuration expurgée et résultat de tests inoffensifs |
| Échec fermé | Que se passe-t-il si la politique ne peut pas être appliquée ? | Message d’échec observé dans l’environnement de test |
| Télémétrie | Quels champs sont exportés et où ? | Configuration expurgée, destination et schéma des événements |
| Gouvernance | Qui consulte et supprime ces traces ? | Rôles, finalité et durée de conservation définis |
Qualifier avant le déploiement
Testez une action autorisée, une action refusée, un redémarrage après changement de réglage et un cas où la protection n’est pas disponible. Dans un environnement contrôlé, vérifiez ensuite que l’export atteint le collecteur prévu sans utiliser de conversation réelle. Si les traces synthétiques contiennent le texte du prompt ou de la réponse alors que cette capture est censée être désactivée, arrêtez l’essai et examinez la configuration effective avant tout élargissement.
Le tableau est un protocole proposé, non le compte rendu d’un test exécuté. Il faut conserver la version de Copilot app, la plateforme, les réglages gérés qui s’appliquent et la date de qualification. Revoyez le protocole quand le client ou la préversion évolue.
Les deux annonces de septembre donnent un cadre de travail concret : la sandbox borne ce que le processus peut faire, et les traces peuvent aider à comprendre son exécution. L’une ne remplace pas l’autre. À la date du 1er octobre 2026, vérifiez leur disponibilité et leur état de préversion pour votre environnement, puis déployez par périmètre après avoir confirmé les règles effectives, l’échec fermé et la destination des données.
Sources vérifiées le 1er octobre 2026
- GitHub Changelog, « OpenTelemetry in the GitHub Copilot app », publié le 22 septembre 2026 : configuration gérée de l’export et exclusion par défaut du contenu de prompts et réponses.
- GitHub Changelog, « Local sandboxing in the GitHub Copilot app », publié le 23 septembre 2026 : périmètre local, politiques fichiers/réseau/identifiants, activation et préversion publique.
Le dépôt, les demandes et les traces décrits sont fictifs. Aucun paramètre d’entreprise n’a été modifié et aucune télémétrie n’a été collectée pour cet article.