Donner aux sessions cloud GitHub Copilot l’accès aux ressources de votre organisation

Si vous avez activé Copilot in the cloud, vous devez configurer les paramètres de votre organisation afin que les agents Copilot puissent se connecter aux serveurs MCP, utiliser des packages privés et accéder aux services externes lorsqu’ils fonctionnent de manière autonome sur GitHub.

Une partie de la configuration ci-dessous est effectuée au niveau du dépôt. Toutefois, les propriétaires de l’organisation contrôlent les ressources qui se trouvent dans l’étendue et déterminent qui peut configurer l’accès à celles-ci.

À propos des environnements de session

Les sessions d’agent sur GitHub peuvent s’exécuter dans un bac à sable cloud ou sur GitHub Actions. Les coûts de calcul des deux environnements sont imputés sur la même allocation mensuelle.

• Un sandbox cloud est un environnement plus rapide et léger qui permet aux utilisateurs de reprendre des sessions dans l’interface de chat de GitHub ou dans d’autres clients.
• GitHub Actions vous permet de contrôler davantage l’environnement, comme les secrets et les variables, les étapes de configuration pour installer les dépendances et l’accès aux exécuteurs auto-hébergés ou à la mise en réseau privée.

Pour obtenir une comparaison détaillée, consultez GitHub Copilot sur GitHub.com et GitHub Mobile.

Ce guide suppose que vous utilisez GitHub Actions comme environnement de calcul. Les sandboxes cloud ont actuellement moins d’options pour configurer l’accès aux ressources de l’organisation.

Exemple de scénario

Votre organisation utilise Sentry pour suivre les bogues dans votre application Node. De nouvelles exceptions sont soulevées en tant que problèmes sur GitHub, et vos développeurs souhaitent attribuer ces derniers à Copilot.

Vous souhaitez Copilot :

• Connectez-vous au serveur MCP Sentry afin qu’il puisse accéder aux détails de votre instance Sentry
• Installer des dépendances, y compris des packages privés hébergés sur GitHub, pour générer votre application et exécuter des tests
• Suivez les conventions de votre organisation pour la gestion des erreurs

Stockage sécurisé des secrets

Par défaut, l’étendue du Copilotjeton d’authentification est limitée au référentiel où il est en cours d’exécution. Cela signifie que Copilot ne pourra pas s’authentifier auprès de systèmes externes ni accéder à des packages privés dans le périmètre de l'organisation.

Les propriétaires d’organisations peuvent ajouter des secrets Agents au niveau de l’organisation pour partager la configuration entre plusieurs dépôts. Copilot peut accéder à ces données pendant son installation et son exécution de tâche. Il ne pourra pas accéder aux secrets et variables pour GitHub Actions, Codespacesou Dependabot. Pour plus d’informations, consultez « Configurer des secrets et des variables pour Copilot agent cloud ».

Exemple : Enregistrer un secret

Un propriétaire de l’organisation enregistre un jeton d’authentification pour l’instance Sentry de l’organisation.

1. Accédez à la section Secrets et variables > Agents des paramètres de l’organisation.
2. Enregistrez un jeton d’accès pour votre instance Sentry dans un secret appelé COPILOT_MCP_SENTRY_ACCESS_TOKEN.

Configuration de l’accès aux serveurs MCP

Les propriétaires d’entreprise et d’organisation peuvent définir une stratégie pour permettre aux utilisateurs de configurer l’accès aux serveurs MCP. Si cette stratégie est activée, les utilisateurs peuvent configurer des serveurs MCP pour Copilot dans les paramètres du référentiel ou dans des profils d'agent personnalisés. Pour une cohérence à l’échelle de l’organisation, nous vous recommandons de créer des profils d’agent personnalisés au niveau de l’organisation ou de l’entreprise.

Une session utilisant un agent personnalisé a accès aux serveurs MCP configurés dans les paramètres du référentiel et dans le profil de l’agent. Toutefois, plus vous couvrez les cas d’usage avec des agents personnalisés à l’échelle de l’organisation, moins les utilisateurs devront configurer l’accès ad hoc aux serveurs MCP dans les paramètres du référentiel.

Vous pouvez également utiliser le fichier managed-settings.json d’une entreprise pour créer une liste verte de serveurs MCP approuvés. Consultez « Configuration d’une liste d’autorisation pour un serveur MCP de votre entreprise ». allowedMcpServers et deniedMcpServers s’appliquent aux serveurs MCP définis dans les paramètres utilisateur et les paramètres de référentiel, mais ne s’appliquent pas aux serveurs MCP définis dans les profils d’agent personnalisés du référentiel. Toutefois, vous pouvez empêcher l’utilisation de serveurs MCP configurés dans des profils d’agent personnalisés en veillant à ce que tous les domaines requis pour les démarrer ne soient pas autorisés par le pare-feu personnalisé au niveau de l’organisation ou du référentiel. Consultez « Personnalisation ou désactivation du pare-feu pour GitHub Copilot ».

Nous vous recommandons de parcourir le GitHub Registre MCP pour trouver des options approuvées et hautement évaluées.

Exemple : Créer un agent personnalisé

Un propriétaire de l’organisation crée un profil d’agent personnalisé pour l’agent Sentry. Il a accès au serveur MCP Sentry et aux instructions personnalisées pour les conventions de gestion des erreurs de l’organisation.

1. Créez un référentiel appelé .github-private dans votre organisation. Si vous le souhaitez, un propriétaire d’entreprise peut définir ce référentiel comme source pour tous les agents personnalisés de l’entreprise.

2. Dans le référentiel, ajoutez un agent.md fichier avec un profil comme suit. Cela inclut la configuration du serveur MCP, qui fait référence au secret que nous avons enregistré.

   ---
   name: sentry-error-fixer
   description: Proposed fixes for exception issues raised from Sentry
   mcp-servers:
     sentry:
       type: 'local'
       command: 'npx'
       args: ['@sentry/mcp-server@latest']
       env:
         SENTRY_ACCESS_TOKEN: ${{ secrets.COPILOT_MCP_SENTRY_ACCESS_TOKEN }}
   ---
   
   You are an error resolution specialist. When you're assigned an issue created by our Sentry integration, check for error details and stack traces using the MCP server, then propose a fix.
   
   Make sure you check that your proposed fix works by building the site with `npm run build` and running the test suite in `npm test`.
   

3. Lorsque les développeurs attribuent un problème Copilot, ils peuvent sélectionner l’agent personnalisé dans une liste déroulante.

Installation de packages privés

La meilleure façon de donner Copilot accès aux dépendances d’un projet consiste à les installer dans un copilot-setup-steps.yml fichier de flux de travail. Ce fichier définit la configuration de l’environnement avant Copilot de commencer à fonctionner.

Pour permettre au workflow de récupérer vos packages privés à l'échelle de l'organisation, vous allez mettre à jour les paramètres du package afin de vous assurer que le GITHUB_TOKEN du référentiel a accès au package. Cette méthode est plus sûre que l'utilisation d'un personal access token à longue durée de vie doté d'autorisations au niveau de l'organisation.

Exemple : Installer les dépendances de Node.js

Un développeur crée un flux de travail pour installer les dépendances node définies dans le fichier d’un package-lock.json dépôt. Cela inclut des paquets privés à l'échelle de l'organisation hébergés sur GitHub.

1. Le développeur crée un copilot-setup-steps.yml fichier dans le référentiel.

2. Ils ajoutent des étapes pour installer les dépendances du projet. Par exemple:

   # ...
   
   jobs:
     copilot-setup-steps:
       # ...
   
       # You can define any steps you want, and they will run before the agent starts.
       # If you do not check out your code, Copilot will do this for you.
       steps:
         - name: Checkout code
           uses: actions/checkout@v6
   
         - name: Set up Node.js
           uses: actions/setup-node@v7
           with:
             node-version: "20"
             cache: "npm"
   
         - name: Install JavaScript dependencies
           run: npm ci
   

3. Un administrateur d’organisation garantit que le référentiel a accès aux packages privés de l’organisation en lui accordant l’accès au référentiel dans les paramètres de chaque package. Consultez « Configuration du contrôle d’accès et de la visibilité d’un package ».

Contrôler qui peut configurer ces paramètres

Vous avez maintenant vu comment l’accès aux ressources est contrôlé au niveau du référentiel et de l’organisation, tenez compte de l’étendue que vous souhaitez donner aux utilisateurs pour gérer ces paramètres.

1. Choisissez les référentiels auxquelsCopilot in the cloudils ont accès. Si vous êtes préoccupé par un référentiel spécifique, vous pouvez le bloquer pour tous les utilisateurs.
2. Considérez qui obtient l’accès administrateur à ces référentiels. Vous pouvez contrôler cela au niveau de l’organisation en créant une équipe avec le rôle personnalisé administrateur de tous les référentiels . Ces utilisateurs pourront gérer les paramètres de configuration, tels que la configuration MCP et les secrets et variables Agents, dans chaque référentiel.
3. Utilisez des ensembles de règles et des fichiers CODEOWNERS pour contrôler les modifications des fichiers de configuration, tels que copilot-setup-steps.yml, que toute personne disposant d’un accès en écriture peut modifier par défaut.
4. Passez en revue le pare-feu par défaut. Le pare-feu n’affecte pas les connexions aux serveurs MCP ou les étapes de configuration, copilot-setup-steps.ymlmais il limite Copilotl’accès à Internet pendant l’exécution de la tâche. Consultez « Personnalisation ou désactivation du pare-feu pour GitHub Copilot ».
5. Définir des normes de plug-in. Les plugins sont des packages installables qui s’étendent Copilot avec des agents, compétences, accroches et intégrations réutilisables. Vous pouvez définir quels plug-ins et places de marché sont autorisés dans le fichier managed-settings.json d’une entreprise. Consultez « À propos des normes de plug-in gérés par l’entreprise ».