Protegendo o GitLab MCP para Desenvolvimento Empresarial: Por Que Estou Construindo um V2 Mais Restritivo

Conectar um LLM ao GitLab através do Protocolo de Contexto do Modelo é extremamente útil.

Um assistente pode inspecionar um repositório, entender uma base de código, criar branches, preparar alterações e ajudar um desenvolvedor a avançar muito mais rápido do que apenas com uma interface de chat.

Mas no momento em que um assistente de IA é permitido agir em uma plataforma de controle de código-fonte, a questão de segurança muda.

A questão não é mais apenas:

O modelo pode gerar um bom código?

Ela se torna:

O que pode acontecer se o modelo cometer um erro, entender mal um pedido, for influenciado por conteúdo de repositório não confiável ou receber uma instrução maliciosa?

Este artigo explica os trade-offs de segurança que identifiquei ao operar GitLab MCP Symfony, e por que atualmente estou testando uma variante mais restritiva, GitLab MCP Symfony Enterprise, para equipes que trabalham em software crítico para os negócios.

O objetivo não é fazer o servidor original parecer inseguro.

O objetivo é reconhecer que uma ferramenta projetada para flexibilidade e produtividade individual do desenvolvedor tem um modelo de ameaça diferente de uma projetada para desenvolvimento empresarial.

O modelo original do GitLab MCP Symfony

A primeira versão do GitLab MCP Symfony é um servidor MCP de propósito geral para o GitLab.

Suas capacidades incluem, dependendo da configuração:

• listar projetos;
• ler árvores e arquivos de repositórios;
• listar branches;
• criar branches;
• criar e atualizar arquivos;
• criar commits atômicos de múltiplos arquivos;
• criar e atualizar projetos;
• arquivar e desarquivar projetos;
• operações destrutivas opcionais;
• autenticação OAuth e escopos;
• listas de permissão de projetos e namespaces;
• limitação de taxa;
• sanitização de campos de resposta da API que parecem sensíveis.

O acesso de escrita é desativado por padrão, e operações destrutivas requerem uma configuração explícita adicional.

Este é um design sensato para uma ferramenta de desenvolvedor flexível.

Para um único desenvolvedor, um projeto pessoal ou um repositório de código aberto, essa flexibilidade é muitas vezes exatamente o que você deseja.

O problema aparece quando o mesmo modelo de capacidade é usado com:

• uma equipe de desenvolvimento;
• código proprietário;
• credenciais sensíveis;
• infraestrutura de CI/CD;
• branches protegidos;
• processos de liberação;
• risco para clientes ou negócios;
• requisitos de segurança contratuais ou regulatórios.

Nesse ponto, a configuração sozinha nem sempre é a barreira de segurança que eu quero.

A suposição chave de segurança: tratar o LLM como um cliente não confiável

A decisão de design mais importante na versão empresarial é simples:

O servidor MCP deve permanecer seguro mesmo se o LLM se comportar incorretamente.

Isso pode parecer pessimista, mas é uma arquitetura muito mais robusta.

Um LLM pode:

• entender mal um pedido do usuário;
• executar excessivamente uma tarefa;
• seguir instruções encontradas dentro do conteúdo do repositório;
• ser exposto a injeção de prompt;
• realizar muitas ações individualmente legítimas que se tornam perigosas quando combinadas;
• gerar código contendo um segredo;
• tentar uma operação que é tecnicamente possível, mas inadequada no contexto de negócios atual.

Se o modelo de segurança for:

LLM
 |
 | "por favor, comporte-se com segurança"
 v
GitLab

então o modelo em si faz parte da barreira de segurança.

Para uso empresarial, eu prefiro:

LLM
 |
 v
política de segurança MCP
 |
 +--> permitir
 +--> negar
 +--> limitar taxa
 +--> auditar
 |
 v
GitLab

A IA ainda pode tomar uma má decisão.

A infraestrutura impede que essa decisão se torne uma ação de alto impacto.

Risco 1: acesso excessivo ao repositório

Uma tarefa de codificação normal pode exigir a leitura de cinco ou dez arquivos.

Uma exportação de repositório pode exigir a leitura de milhares.

A operação individual do GitLab pode ser a mesma em ambos os casos:

ler arquivo
ler arquivo
ler arquivo
ler arquivo
...

Este é um ponto importante porque simplesmente remover uma hipotética ferramenta download_repository.zip não é suficiente.

Um cliente ainda poderia reconstruir a maior parte de um repositório progressivamente.

Para software proprietário, isso cria um risco de confidencialidade.

Abordagem V1

O servidor original fornece capacidades normais de leitura de repositório e limitação de taxa global de ferramentas.

Isso é prático e apropriado para desenvolvimento geral.

Abordagem Empresarial

A variante empresarial adiciona limites progressivos por usuário e projeto para:

• número de arquivos lidos;
• número de bytes lidos;
• enumeração de árvore de repositório;
• padrões de travessia incomumente grandes.

A enumeração recursiva de repositórios é desativada por padrão.

A funcionalidade de arquivamento/exportação de repositório não é exposta de forma alguma.

O objetivo não é impedir que uma IA leia código.

O objetivo é fazer essa distinção:

Entender o código necessário para a tarefa   -> permitido
Percorrer ou extrair a maior parte do repositório -> negado / detectado

Isso realmente reduz a conveniência.

Isso é intencional.

Risco 2: segredos armazenados no código fonte

Nenhuma organização pretende cometer credenciais.

As organizações ainda cometem credenciais.

Exemplos incluem:

• chaves de API;
• segredos de cliente OAuth;
• chaves de acesso à nuvem;
• JWTs;
• chaves privadas;
• senhas de banco de dados;
• .env arquivos;
• keystores;
• estado do Terraform;
• credenciais de depuração temporárias.

Se um MCP conectado ao LLM puder ler o arquivo, a credencial pode deixar a barreira de confiança do GitLab antes que alguém perceba o erro.

O mesmo problema existe na direção oposta: o código gerado pela IA poderia acidentalmente incluir uma credencial em um commit.

V2: a varredura de segredos se torna parte da barreira

A variante empresarial integra Gitleaks diretamente no caminho do MCP.

Antes que o conteúdo do repositório seja retornado à IA:

Arquivo GitLab
   |
   v
política de caminho sensível
   |
   v
Gitleaks
   |
   +--> segredo detectado -> NEGAR
   |
   v
LLM

E antes que um plano de commit seja aceito:

Conteúdo gerado pela IA
   |
   v
Gitleaks
   |
   +--> segredo detectado -> NEGAR
   |
   v
preparação do commit

A propriedade importante é comportamento de falha fechada.

Se o scanner falhar, o conteúdo não é retornado.

Isso é muito diferente de:

"Escanear se possível, caso contrário, continuar."

Para controles de segurança, a falha do scanner não deve se tornar silenciosamente uma permissão.

Risco 3: arquivos sensíveis que nunca deveriam chegar ao modelo

A detecção de segredos é útil, mas não é perfeita.

Um controle mais forte é prevenir