Dando ao agente de nuvem do GitHub Copilot acesso aos recursos em sua organização

          agente de nuvem Copilot pode se conectar a servidores MCP, usar pacotes privados e acessar serviços externos, mas somente se os repositórios da sua organização estiverem configurados para permitir isso.

Embora grande parte da configuração abaixo seja feita no nível do repositório, os proprietários da organização têm controle sobre quais recursos estão no escopo e quem pode configurar o acesso a eles.

Cenário de exemplo

Sua organização usa o Sentry para rastrear bugs em seu aplicativo Node. Novas exceções são geradas como problemas em GitHub, e seus desenvolvedores desejam atribuir esses problemas a Copilot.

Você deseja Copilot :

• Conecte-se ao servidor do MCP do Sentry para que ele possa acessar os detalhes sobre sua instância Sentry.
• Instalar dependências, incluindo pacotes privados hospedados GitHub, para criar seu aplicativo e executar testes
• Siga as convenções da sua organização para tratamento de erros

Armazenando segredos com segurança

Por padrão, o escopo do token de Copilotautenticação é limitado ao repositório em que ele está em execução. Isso significa que Copilot não conseguirá se autenticar em sistemas externos ou acessar pacotes privados com escopo de organização.

Os administradores do repositório devem adicionar variáveis e segredos em um ambiente dedicado copilotGitHub Actions que Copilot exija. Copilot pode acessar esses dados em sua configuração e execução de tarefas. Ele não poderá acessar variáveis ou segredos fora desse ambiente, como segredos em toda a GitHub Actions organização.

Exemplo: salvar um segredo

Um administrador de repositório salva um token de autenticação para a instância do Sentry da organização.

1. Vá para a seção Ambientes das configurações do repositório.
2. Criar um novo ambiente chamado copilot.
3. Salve um token de acesso para sua instância do Sentry em um segredo de ambiente chamado COPILOT_MCP_SENTRY_ACCESS_TOKEN.

Configurando o acesso aos servidores MCP

Os proprietários da organização e da empresa podem definir uma política para permitir que os usuários configurem o acesso aos servidores MCP. Se essa política estiver habilitada, os usuários poderão configurar servidores MCP nas configurações do repositório ou nos perfis de agente personalizados. Para consistência em toda a organização, recomendamos a criação de perfis de agente personalizados no nível da organização ou da empresa.

Uma sessão usando um agente personalizado tem acesso a servidores MCP configurados nas configurações do repositório e no perfil do agente. No entanto, quanto mais casos de uso você abordar com agentes personalizados de toda a organização, menos usuários precisarão configurar o acesso ad hoc aos servidores MCP nas configurações do repositório.

Recomendamos navegar pelo GitHub Registro MCP para encontrar opções confiáveis e altamente avaliadas.

Exemplo: criar um agente personalizado

Um proprietário da organização cria um perfil de agente personalizado para o agente Sentry. Ele tem acesso ao servidor SENTRY MCP e instruções personalizadas para as convenções de tratamento de erros da organização.

1. Crie um repositório chamado .github-private em sua organização. Opcionalmente, um proprietário da empresa pode definir esse repositório como a origem para todos os agentes personalizados na empresa.

2. No repositório, adicione um agent.md arquivo com um perfil como o seguinte. Isso inclui a configuração para o servidor MCP, que faz referência ao segredo que salvamos.

   ---
   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. Quando os desenvolvedores atribuem um problema a Copilot, eles podem selecionar o agente personalizado de uma lista suspensa.

Instalando pacotes privados

A melhor maneira de dar Copilot acesso às dependências de um projeto é instalá-las em um copilot-setup-steps.yml arquivo de fluxo de trabalho. Esse arquivo define como o ambiente é configurado antes Copilot de começar a funcionar.

Para permitir que o fluxo de trabalho extraia seus pacotes privados limitados ao escopo da organização, você atualizará as configurações do pacote para garantir que o repositório GITHUB_TOKEN tenha acesso ao pacote. Isso é mais seguro do que usar um personal access token de longa duração com permissões da organização.

Exemplo: Instalar dependências do Node.js

Um desenvolvedor cria um fluxo de trabalho para instalar as dependências do Nó definidas no arquivo de package-lock.json um repositório. Isso inclui pacotes privados no escopo da organização hospedados em GitHub.

1. O desenvolvedor cria um copilot-setup-steps.yml arquivo no repositório.

2. Eles adicionam etapas para instalar as dependências do projeto. Por exemplo:

   # ...
   
   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@v5
   
         - name: Set up Node.js
           uses: actions/setup-node@v4
           with:
             node-version: "20"
             cache: "npm"
   
         - name: Install JavaScript dependencies
           run: npm ci
   

3. Um administrador da organização garante que o repositório tenha acesso aos pacotes privados da organização concedendo acesso ao repositório nas configurações de cada pacote. Consulte Configurando o controle de acesso e visibilidade de um pacote.

Controlando quem pode definir essas configurações

Agora você viu como o acesso aos recursos é controlado nos níveis do repositório e da organização, considere quanto escopo você deseja dar aos usuários para gerenciar essas configurações.

1.        **Escolha a quais repositórios têm acesso**agente de nuvem Copilot. Se você estiver preocupado com um repositório específico, poderá bloqueá-lo para todos os usuários.
   

2.        **Considere quem obtém acesso de administrador** a esses repositórios. Você pode controlar isso no nível da organização criando uma equipe com a função personalizada **de administrador de todos os repositórios** . Esses usuários poderão gerenciar _as configurações_, como configuração do MCP e `copilot` ambientes, em todos os repositórios.
   

3.        **Use regras e arquivos CODEOWNERS** para controlar as edições de _arquivos_ de configuração, como `copilot-setup-steps.yml`, que qualquer pessoa com acesso de gravação pode editar por padrão.
   

4.        **Examine o firewall padrão**. O firewall não afeta as conexões com servidores MCP nem as etapas de instalação, `copilot-setup-steps.yml`mas limita Copiloto acesso à Internet durante a execução da tarefa. Consulte [AUTOTITLE](/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-firewall).