GitHub cria allowlist de servidores MCP para o Copilot

O GitHub tornou disponível de forma geral, em 6 de agosto, um novo controle para empresas que usam o Copilot: listas de permissão, ou allowlists, para servidores MCP (Model Context Protocol). Com as chaves allowedMcpServers e deniedMcpServers, adicionadas ao arquivo copilot/managed-settings.json, administradores de organizações e enterprises no GitHub passam a decidir centralmente quais integrações externas o Copilot pode acessar — bloqueando, por padrão, qualquer servidor que não tenha sido explicitamente autorizado.

O MCP é o protocolo aberto que permite a assistentes de IA, como o Copilot, o Claude e outros agentes, se conectarem a ferramentas externas — bancos de dados, sistemas internos, APIs de terceiros — por meio de uma interface padronizada. Desde que ganhou tração em 2025, o ecossistema de servidores MCP cresceu rapidamente, e cresceu junto dele uma superfície de ataque nova: qualquer integração mal configurada, maliciosa ou desatualizada passa a ter, potencialmente, acesso às mesmas credenciais e ao mesmo contexto que o assistente de IA usa para o trabalho do desenvolvedor.

Como funciona o allowlist

A nova política funciona por meio de duas chaves configuráveis no repositório privado .github-private da organização de origem. Cada mudança na lista fica registrada como um commit revisável, não como um botão de configuração isolado em um painel administrativo — o que dá rastreabilidade a decisões de segurança que antes dependiam de confiança implícita nos desenvolvedores.

• serverUrl identifica servidores remotos, via HTTP ou SSE, por endereço. Aceita curingas com asterisco e passa por canonicalização, para evitar que alguém contorne a regra variando a grafia da URL.
• serverCommand identifica servidores locais, do tipo stdio, pelo comando e pelos argumentos exatos usados para iniciá-los.
• serverName reconhece o rótulo definido pelo próprio usuário para o servidor — mas o GitHub avisa que esse campo é apenas uma conveniência, não um controle de segurança, já que qualquer pessoa pode renomear um servidor à vontade.

O comportamento padrão é fail closed: uma entrada malformada, ou que não possa ser validada, é bloqueada, não liberada. Quando políticas de níveis diferentes — enterprise e organização, por exemplo — se aplicam ao mesmo usuário, um servidor MCP só passa se for aprovado em todos os níveis simultaneamente.

Onde a política já vale

Segundo o changelog oficial do GitHub, o allowlist de MCP em managed settings está em disponibilidade geral e já é aplicado no aplicativo do GitHub Copilot, no Copilot CLI e no VS Code. O recurso é exclusivo de clientes Copilot Business e Copilot Enterprise, e não está disponível em contas individuais nem no plano gratuito. Ele complementa um controle mais antigo, de outubro de 2025, que já permitia restringir servidores MCP por meio de um registro interno em JetBrains, Eclipse e Xcode; a novidade de agosto adiciona correspondência granular por URL, comando ou nome, em vez de depender só de uma lista fixa de servidores pré-aprovados no registro.

Na prática, a organização escolhe entre dois modos de política, segundo a documentação do GitHub: "allow all", o padrão, em que qualquer servidor MCP pode rodar e os servidores cadastrados em um registro interno aparecem apenas como recomendados; ou "registry only", em que só servidores do registro da organização são permitidos, e qualquer outro é bloqueado em tempo de execução com um aviso explícito para quem tentou usá-lo. As chaves allowedMcpServers e deniedMcpServers da atualização de agosto se somam a esse modelo, permitindo exceções e bloqueios pontuais sem reescrever todo o registro.

Por que o GitHub agiu agora

A mudança acompanha uma sequência concreta de incidentes de segurança ligados ao MCP nos últimos meses. Em julho de 2025, a equipe de pesquisa da JFrog divulgou a CVE-2025-6514, uma falha crítica, com nota 9.6 na escala CVSS, no pacote mcp-remote, usado por clientes MCP como o Claude Desktop para se conectar a servidores remotos. O problema permitia execução de comandos no sistema operacional quando o cliente se conectava a um servidor malicioso, e afetava versões já baixadas mais de 437 mil vezes antes da correção, lançada na versão 0.1.16.

Outros vetores de ataque documentados no próprio guia oficial de boas práticas de segurança do Model Context Protocol incluem o tool poisoning, quando instruções maliciosas ficam escondidas na descrição de uma ferramenta, invisíveis para o usuário mas lidas pelo modelo de IA; o confused deputy, quando um servidor MCP é enganado para usar sua própria autoridade em nome de um invasor; e o token passthrough, o repasse indevido de tokens de acesso do cliente diretamente para APIs de terceiros, sem validação. Fornecedores de segurança como Wiz e Checkmarx vêm descrevendo os mesmos riscos ao longo de 2026, o que indica que a preocupação não parte de um único fornecedor ou de um único incidente isolado.

O GitHub não é o único a reagir. A documentação oficial do Claude Code, da Anthropic — criadora do protocolo MCP —, também descreve um mecanismo equivalente: um arquivo managed-mcp.json, aplicado por administradores de TI em nível de sistema operacional, com suas próprias chaves allowedMcpServers e deniedMcpServers e suporte a padrões glob. Ou seja, o movimento de transformar o controle de servidores MCP em política central, e não em decisão individual do desenvolvedor, está se tornando padrão entre as principais plataformas de IA para código.

O que muda para desenvolvedores e empresas no Brasil

Para times que já usam Copilot Enterprise ou Business no Brasil, o allowlist não é automático: precisa ser configurado por um administrador da organização ou enterprise no GitHub. Equipes que dependem de servidores MCP internos, para acessar bancos de dados, sistemas de tickets ou pipelines de CI/CD, vão precisar mapear e declarar explicitamente cada integração antes que ela pare de funcionar sob uma política mais restritiva, especialmente se o padrão adotado pela organização for o de permitir apenas servidores de um registro interno.

• Levante quais servidores MCP já estão em uso na organização, incluindo os configurados localmente por desenvolvedores individuais em suas máquinas.
• Prefira servidores remotos com URL fixa e HTTPS a comandos locais arbitrários, que são mais difíceis de auditar em escala.
• Trate o serverName como identificador cosmético, nunca como controle de acesso, e valide entradas por URL ou comando.
• Mantenha o mcp-remote e outros clientes MCP atualizados; a versão vulnerável à CVE-2025-6514 já foi corrigida, mas ainda pode estar em uso em ambientes que não atualizam dependências com regularidade.

O movimento do GitHub reforça uma tendência maior: à medida que agentes de IA ganham permissão para executar ações e acessar sistemas reais, decidir quais integrações eles podem usar deixa de ser um detalhe operacional e passa a fazer parte do modelo de ameaças de qualquer empresa que adota Copilot, Claude ou ferramentas semelhantes no fluxo de desenvolvimento.