Allowlist de MCP para agentes de código é o contrato que decide quais ferramentas Codex, Claude Code, Copilot e outros agentes podem descobrir, chamar e repetir. A fronteira importante não é o servidor inteiro. É cada ferramenta, com escopo, origem, segredo, log e regra de bloqueio.
Em 2026, uma pesquisa sobre MCP analisou 57 ameaças em componentes de host, cliente, LLM, servidor, fontes externas e autorização (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado em 2026-07-09). Se o agente ganha ferramentas autônomas, a configuração dessas ferramentas vira parte do pipeline de segurança.
Resumo prático
- Permita ferramentas específicas, não servidores inteiros por conveniência.
- Trate mudança de MCP como mudança de código revisável.
- Separe leitura, escrita e execução com políticas diferentes.
- Registre cada chamada para o PR carregar prova curta.
Por que allowlist de MCP virou assunto de pipeline?
Em 2026, o estudo de MCP identificou 57 ameaças e apontou tool poisoning como vulnerabilidade client-side prevalente (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado em 2026-07-09). O pipeline precisa tratar MCP como superfície de execução, porque uma ferramenta ruim pode influenciar patch, PR, segredo e deploy.
O erro comum é instalar um servidor MCP porque ele parece útil e deixar o agente decidir depois. Esse modelo mistura descoberta, permissão e execução no mesmo ponto. Para desenvolvimento real, a política deve nascer antes do prompt: quais ferramentas entram, em qual repositório, com qual segredo e sob qual log.
Esse post continua os textos sobre MCP de codebase RAG, agentjacking via Sentry MCP e hooks para agentes de código. A diferença aqui é governança de tool use. Não estamos falando do dado que volta. Estamos falando da porta que deixa a ferramenta existir.
Em fluxos longos, a allowlist também economiza contexto. O agente não precisa carregar um catálogo inteiro de capacidades se o harness entrega só o que a tarefa permite. Eu uso o RemoteCode como extensão de contexto para Claude Code e Codex em fluxos agentic longos quando quero manter continuidade sem despejar histórico e ferramentas demais no prompt principal; é uma ferramenta minha, então a menção aqui é editorial.
Cápsula citável: Allowlist de MCP é controle de execução para agentes de código. Como a pesquisa de 2026 mapeou 57 ameaças no ecossistema MCP (arXiv, consultado em 2026-07-09), a política deve limitar ferramentas antes da chamada.
O que entra em um registro privado de MCP?
Em 2026, GitHub anunciou suporte a registro próprio com allowlists de MCP no Copilot CLI, em prévia pública para clientes Copilot Business e Enterprise (GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", 2026, consultado em 2026-07-09). O registro privado vira a fonte permitida de descoberta.
Um registro privado não é só uma lista de nomes bonitos. Ele deve guardar origem do pacote, versão aprovada, hash quando fizer sentido, dono interno, ferramentas expostas, escopos de segredo, ambiente permitido e contato de revisão. Quando o agente procura uma capacidade, ele enxerga esse inventário, não a internet inteira.
O GitHub lançou o MCP Registry público em 2025 dizendo que servidores estavam espalhados por registros, repositórios e conversas de comunidade, um cenário com riscos de segurança (GitHub Changelog, "GitHub MCP Registry", 2025, consultado em 2026-07-09). Em empresa, o registro privado resolve o mesmo problema com uma decisão extra: descoberta não é autorização.
Cápsula citável: Registro privado de MCP separa descoberta de permissão. O GitHub levou allowlists baseadas em registro ao Copilot CLI em 2026 (GitHub Changelog, consultado em 2026-07-09); times devem negar servidores fora da fonte governada.
Como permitir ferramentas sem liberar o servidor inteiro?
Em 2026, a documentação do GitHub para MCP em repositórios recomenda permitir ferramentas read-only específicas, porque Copilot cloud agent e Copilot code review podem usar essas ferramentas autonomamente sem pedir aprovação (GitHub Docs, "Configure MCP servers", 2026, consultado em 2026-07-09). A unidade de controle deve ser a ferramenta.
Permitir * é prático, mas fraco. Uma ferramenta que lê issue não tem o mesmo risco de uma ferramenta que comenta PR. Uma ferramenta que consulta log não tem o mesmo risco de uma que executa comando. A allowlist boa deixa o servidor instalado, mas só expõe chamadas úteis para aquela tarefa.
{
"mcpServers": {
"observabilidade": {
"type": "http",
"url": "https://mcp.interno.example",
"tools": ["buscar_alerta", "ler_trace"]
}
}
}Use nomes estreitos. buscar_alerta é melhor que observabilidade_total. ler_trace é melhor que executar_consulta_livre. Quando a ferramenta precisa escrever, abra outro caminho: confirmação humana, segredo separado, branch temporária e log de PR.
Cápsula citável: A allowlist deve mirar a chamada, não a marca do servidor. GitHub Docs recomenda ferramentas read-only específicas porque o agente pode usá-las sem aprovação (GitHub Docs, consultado em 2026-07-09);
*deve ser exceção revisada.
Como o CI bloqueia mudança perigosa de MCP?
Em 2025, a especificação MCP descreveu ferramentas como model-controlled e recomendou humano no loop para negar invocações (Model Context Protocol, "Tools", 2025-06-18, consultado em 2026-07-09). Em repositório sério, esse humano começa no review da configuração, antes do agente executar.
Trate arquivos de MCP como infraestrutura. Mudou servidor, comando, argumento, segredo, URL, ferramenta ou wildcard? O CI deve abrir alerta. Se a mudança aumenta capacidade, peça code owner. Se adiciona escrita, peça revisão de segurança. Se toca segredo, bloqueie até o ambiente provar que o token é curto e restrito.
O mesmo vale para configuração em UI. GitHub Docs diz que a configuração de MCP do repositório é compartilhada por Copilot cloud agent e Copilot code review (GitHub Docs, "Configure MCP servers", 2026, consultado em 2026-07-09). Se dois fluxos usam a mesma superfície, a revisão precisa considerar ambos.
Cápsula citável: Configuração MCP deve passar por gate de CI como IaC. A especificação MCP recomenda humano no loop para ferramentas model-controlled (Model Context Protocol, consultado em 2026-07-09); no desenvolvimento, isso vira diff revisável e code owner.
Onde entram OAuth, escopo e segredos?
Em 2025, a especificação mais recente de autorização MCP tornou obrigatória a validação de audience em tokens e proibiu aceitar tokens emitidos para outro recurso (Model Context Protocol, "Authorization", 2025-11-25, consultado em 2026-07-09). Escopo não é detalhe de login. É limite operacional do agente.
Evite segredo permanente em config pessoal. Prefira variável de ambiente controlada, token de curta duração, escopo read-only por padrão e step-up quando a operação realmente exige escrita. Se uma ferramenta precisa de files:write, ela não deve dividir token com uma ferramenta de leitura.
A mesma especificação exige que o access token vá no cabeçalho Authorization e não na query string, e recomenda retry limits quando há erro de escopo insuficiente (Model Context Protocol, "Authorization", 2025-11-25, consultado em 2026-07-09). Isso importa para agentes: falha de permissão deve parar ou pedir escopo, não tentar caminho alternativo.
Cápsula citável: OAuth em MCP deve reduzir agência, não mascarar risco. A especificação de 2025 exige token com audience correta, proíbe token em query string e orienta limites de retry em step-up (Model Context Protocol, consultado em 2026-07-09).
Como testar contra tool poisoning?
Em 2026, a pesquisa de MCP avaliou sete clientes contra quatro tipos de tool poisoning e apontou que cinco não aplicavam validação estática de descrições de ferramenta (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado em 2026-07-09). Teste de MCP precisa simular ferramenta hostil, não só servidor fora do ar.
Monte um servidor falso em ambiente local com descrições suspeitas, parâmetros longos, retorno com instrução maliciosa e tentativa de acesso fora do escopo. O agente deve recusar, pedir confirmação ou ficar limitado pelo harness. Se ele executa sem fricção, a allowlist está só documentada.
OWASP lista prompt injection, insecure plugin design e excessive agency entre riscos de aplicações com LLMs (OWASP, "Top 10 for Large Language Model Applications", 2025, consultado em 2026-07-09). MCP cruza esses riscos porque a ferramenta vira ponte entre texto, sistema externo e ação.
Cápsula citável: Teste de tool poisoning valida a fronteira do agente. A pesquisa de 2026 mostrou cinco de sete clientes sem validação estática (arXiv, consultado em 2026-07-09); times devem testar descrições, parâmetros, saídas e chamadas fora de escopo.
O que implementar nesta semana?
Em 2026, GitHub lançou Agent Finder com descoberta a partir de registro escolhido e settings gerenciados que limitam quais recursos os agentes podem descobrir e usar (GitHub Changelog, "Agent finder for GitHub Copilot now available", 2026, consultado em 2026-07-09). O caminho prático é controlar descoberta, permissão e execução em camadas.
Comece com inventário. Liste os servidores MCP usados por Codex, Claude Code, Copilot, IDEs e automações de CI. Depois marque ferramentas de leitura, escrita e execução. Promova para allowlist só o que tem dono, fonte, versão e razão de uso no repositório.
Depois adicione gate. Qualquer mudança que amplia tools, troca URL, troca comando, adiciona variável sensível ou libera wildcard deve falhar até revisão. No PR, peça ao agente para registrar quais ferramentas chamou, com argumento resumido e resultado verificável. Sem esse rastro, o revisor não sabe se o patch nasceu de contexto confiável.
Por fim, conecte com seus evals de PR para agentes e com o loop self-correcting no CI. MCP não deve ser exceção ao harness. Ele é uma entrada operacional do harness.
Perguntas frequentes sobre allowlist de MCP
Allowlist de servidor MCP já basta?
Não. Em 2026, GitHub Docs recomendou allowlist de ferramentas read-only específicas porque Copilot pode usá-las autonomamente sem aprovação (GitHub Docs, "Configure MCP servers", 2026, consultado em 2026-07-09). Servidor aprovado ainda pode expor ferramenta ampla demais.
Registro privado substitui revisão de segurança?
Não. Em 2026, GitHub descreveu registro próprio como forma de impedir uso de servidores fora da lista em runtime (GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", 2026, consultado em 2026-07-09). A revisão decide o que entra no registro.
Tool poisoning é risco real em agente de código?
Sim. Em 2026, a pesquisa de MCP avaliou sete clientes contra quatro ataques de tool poisoning e encontrou lacunas de validação, visibilidade e logging (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado em 2026-07-09). Código amplia impacto porque ferramenta pode influenciar patch.
Devo bloquear toda ferramenta de escrita?
Não sempre. Em 2025, a especificação MCP recomendou confirmação humana para operações sensíveis e log de uso de ferramentas (Model Context Protocol, "Tools", 2025-06-18, consultado em 2026-07-09). Escrita pode existir, mas deve ter escopo, aprovação, token separado e evidência no PR.
Fechamento
MCP com allowlist não é burocracia. É a forma de transformar tool use em contrato de engenharia. O agente pode continuar rápido, mas só dentro das capacidades que o time aceitou revisar, auditar e revogar.
Comece pela menor superfície: leitura aprovada, escrita bloqueada e wildcard proibido. Quando o time tiver logs confiáveis, adicione ferramentas mais sensíveis com escopo e code owner. O objetivo não é reduzir MCP. É impedir que uma ferramenta útil vire permissão invisível.
Fontes consultadas
- arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", consultado em 2026-07-09, https://arxiv.org/html/2603.22489v1
- GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", consultado em 2026-07-09, https://github.blog/changelog/2026-04-16-copilot-cli-supports-custom-registry-based-mcp-allowlists/
- GitHub Changelog, "GitHub MCP Registry: The fastest way to discover AI tools", consultado em 2026-07-09, https://github.blog/changelog/2025-09-16-github-mcp-registry-the-fastest-way-to-discover-ai-tools/
- GitHub Changelog, "Agent finder for GitHub Copilot now available", consultado em 2026-07-09, https://github.blog/changelog/2026-06-17-agent-finder-for-github-copilot-now-available/
- GitHub Docs, "Configure MCP servers for your repository", consultado em 2026-07-09, https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
- Model Context Protocol, "Tools", consultado em 2026-07-09, https://modelcontextprotocol.io/specification/2025-06-18/server/tools
- Model Context Protocol, "Authorization", consultado em 2026-07-09, https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- NSA, "Model Context Protocol: Security Design Considerations", consultado em 2026-07-09, https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
- OWASP, "Top 10 for Large Language Model Applications", consultado em 2026-07-09, https://owasp.org/www-project-top-10-for-large-language-model-applications/
