Como auditar um servidor MCP antes de instalar na empresa

Como auditar um servidor MCP antes de instalar na empresa

Para auditar um servidor MCP de terceiros, confirme quem o mantém e de onde vem o código, liste o que ele pode ler e executar, descubra quais dados saem do seu ambiente e defina quem revisa cada atualização. Só então instale, primeiro em ambiente isolado e com credenciais de menor privilégio. Um servidor MCP dá a um agente de IA a capacidade de agir em sistemas reais, por isso a revisão se parece mais com a de um software que acessa dados da empresa do que com a de um plugin comum.

Principais pontos

• Origem: prefira mantenedores identificáveis, código aberto para leitura e histórico público de manutenção.
• Permissões: cada ferramenta exposta é uma ação possível. Mantenha só as que o fluxo precisa, com acesso somente leitura quando bastar.
• Dados: mapeie o que entra no contexto do modelo e o que o servidor envia a serviços externos, inclusive logs e telemetria.
• Atualizações: fixe versões, leia as mudanças antes de aprovar e tenha um caminho de reversão.
• Piloto: teste um fluxo real, com registro de chamadas e critério de parada, antes de ampliar o uso.

O que é um servidor MCP e por que ele pede uma auditoria própria?

O Model Context Protocol (MCP) é um padrão aberto para conectar aplicações de IA a ferramentas e fontes de dados. Na prática, um servidor MCP é um programa que expõe ferramentas (ações que o agente pode chamar), recursos (dados que ele pode ler) e, às vezes, prompts prontos. O cliente de IA lê as descrições dessas ferramentas e o modelo decide quando usá-las.

Isso muda o risco. Um conector tradicional faz apenas o que foi programado, na ordem programada. Com MCP, quem decide a chamada é um modelo, a partir de texto que pode vir de fontes não confiáveis: um e-mail recebido, uma página web, uma mensagem de cliente no WhatsApp. Além disso, o servidor roda com as credenciais que você entregar. Se roda na máquina de um colaborador, herda o acesso dessa máquina. Se roda em outro ambiente, recebe seus dados lá.

Por isso a auditoria cobre quatro frentes: origem, permissões, dados e atualizações. Ajuda também separar três coisas no relatório: o que o projeto documenta, o que você verificou (leu no código ou testou) e o que é apenas hipótese. Quem decide a instalação precisa saber a diferença entre afirmação do fornecedor e evidência própria.

Origem: quem mantém e de onde vem o código?

A revisão começa antes de baixar qualquer coisa. Responda a estas perguntas e guarde as respostas:

• Quem é o mantenedor? Prefira uma empresa ou pessoa identificável, com histórico em outros projetos e um canal para reportar falhas de segurança.
• O repositório é aberto e o pacote publicado corresponde a ele? Compare o que o gerenciador de pacotes instala com o código que você leu.
• Há manutenção contínua, problemas abertos sendo tratados e versões com notas de mudança?
• O nome do pacote é o oficial? Nomes parecidos com os de projetos conhecidos são uma forma comum de distribuir código malicioso.
• Quais dependências ele traz? Um servidor pequeno com muitas dependências amplia a superfície de ataque.
• A licença permite uso comercial na sua empresa?

Se o servidor é fornecido pelo próprio fabricante do sistema que você quer conectar, a confiança tende a ser maior, mas as demais etapas continuam valendo. Se é um projeto individual sem manutenção, trate como código não confiável: ou você lê o que importa, ou não instala.

Não é preciso revisar cada linha. Concentre-se em quatro pontos: como a autenticação é tratada, onde os segredos ficam, quais chamadas de rede o código faz e se há execução de comandos do sistema operacional. Chamadas para domínios que a documentação não menciona e leitura de variáveis de ambiente além das necessárias são sinais para parar e perguntar.

Permissões: o que o servidor pode fazer com o acesso que você entrega?

Faça um inventário de ferramentas. Para cada uma, anote nome, descrição, parâmetros e efeito: leitura, escrita, exclusão ou envio para fora. Depois classifique com um guia simples de decisão:

• Leitura de dado não sensível: pode ser liberada após o piloto.
• Leitura de dado pessoal ou financeiro: libere só com finalidade definida e registro de cada acesso.
• Escrita reversível, como criar rascunho ou abrir chamado: libere com log e possibilidade de desfazer.
• Escrita irreversível ou com efeito externo, como enviar mensagem, pagar ou apagar: exija aprovação humana a cada chamada, ou não libere.
• Execução de comandos ou acesso amplo ao sistema de arquivos: negue por padrão e permita apenas dentro de um sandbox.

O princípio de autorização é o mesmo de qualquer sistema: negar por padrão e conceder o menor privilégio possível, como descrevem as boas práticas de autorização do OWASP. Na prática, crie uma conta de serviço dedicada ao servidor, nunca a conta pessoal de um colaborador. Se o servidor usa OAuth, revise os escopos solicitados e recuse os que não correspondem às ferramentas que você realmente vai usar.

Desative as ferramentas que o fluxo não precisa, quando o cliente permitir restringir a lista. No lado do cliente, as regras de permissão e isolamento são a segunda camada de defesa. Vale ler o guia sobre segurança no Claude Code: permissões, sandbox e segredos e definir uma política de aprovação para agentes de IA para as ações que não podem acontecer sem uma pessoa.

Que dados trafegam e para onde eles vão?

Desenhe o caminho dos dados em três trechos: do seu sistema para o servidor, do servidor para o modelo (o que entra no contexto) e do servidor para terceiros (APIs externas, telemetria, logs, serviços de análise). O segundo trecho costuma ser esquecido: tudo o que uma ferramenta devolve passa a fazer parte do que o modelo lê e, dependendo do cliente, pode seguir para um provedor de IA.

Para verificar em vez de supor, rode o servidor em ambiente de teste com monitoramento de rede e compare os destinos contatados com o que a documentação declara. Qualquer destino não explicado é um item aberto na auditoria.

No caso de servidor hospedado por terceiros, o fornecedor passa a receber os dados. Leia a política de privacidade e pergunte por escrito sobre retenção, subprocessadores, local de armazenamento e se os dados são usados para outros fins. Registre as respostas.

Se houver dado pessoal, a LGPD entra na conta: finalidade definida, base legal, minimização e registro de quem acessou o quê. Dados de clientes que chegam por WhatsApp, como nome, telefone e conteúdo das conversas, são um exemplo comum. O artigo sobre LGPD no WhatsApp com IA: consentimento, base legal e registro detalha essa parte. A regra prática é enviar ao servidor apenas os campos necessários, por exemplo uma visão do banco sem documentos pessoais, em vez da tabela completa.

Como testar sem arriscar: ambiente isolado e injeção de prompt

Com origem, permissões e dados mapeados, monte o teste. Este é um plano de execução em ordem:

• Crie um ambiente separado, sem dados reais, com dados fictícios parecidos com os verdadeiros.
• Use credenciais descartáveis, com o menor escopo possível.
• Ative o registro de todas as chamadas: ferramenta, parâmetros, resposta e quem aprovou.
• Leia as descrições das ferramentas como se fossem instruções ao modelo. Procure texto que mande ignorar regras, chamar outra ferramenta ou enviar informação para algum lugar.
• Simule conteúdo hostil: coloque em um documento ou mensagem de teste uma instrução escondida e observe se o agente tenta agir fora do escopo combinado.
• Provoque erros de propósito e verifique se as mensagens devolvidas expõem segredos, caminhos internos ou detalhes de infraestrutura.
• Ao final, revogue as credenciais de teste e guarde os registros como evidência.

O motivo do quinto passo está na injeção de prompt. O OWASP descreve que texto de entrada pode alterar o comportamento de um modelo, e o resultado de uma ferramenta também é entrada. Filtros ajudam, mas não resolvem sozinhos. A defesa mais confiável é limitar o que o agente consegue fazer quando é enganado: poucas ferramentas, acesso somente leitura quando possível e aprovação humana para efeitos externos.

Atualizações: como evitar que uma nova versão mude o risco?

Um servidor aprovado hoje pode ser diferente na próxima versão. Trate a atualização como uma nova mudança de risco:

• Fixe a versão exata e, quando possível, o identificador do commit ou o hash do pacote. Evite instalar sempre a versão mais recente de forma automática.
• Leia as notas de mudança e o diff antes de atualizar. Foque em ferramentas novas, escopos novos, dependências novas e destinos de rede novos.
• Reaprove sempre que mudar uma ferramenta, um escopo ou um destino de dados, mesmo em uma versão pequena.
• Nomeie um responsável e uma rotina de revisão periódica. Sem dono, o servidor fica esquecido com acesso ativo.
• Tenha um plano de reversão e de desligamento rápido, incluindo a revogação das credenciais.
• Para servidor hospedado pelo fornecedor, você não controla a versão. Exija aviso prévio de mudanças ou aceite que o risco é contínuo e compense com monitoramento das chamadas.

Esse é também o ponto em que o monitoramento paga seu custo. Os registros do período de teste viram a linha de base: se uma atualização começar a chamar ferramentas ou destinos que antes não apareciam, a diferença fica visível.

Cenário ilustrativo e como aplicamos o método

Cenário ilustrativo: uma distribuidora quer que um agente consulte o status de pedidos no ERP por meio de um servidor MCP de código aberto, encontrado em um repositório público. O mantenedor é uma pessoa sem outros projetos conhecidos e o repositório está sem atualizações há bastante tempo. A leitura do código mostra duas ferramentas de consulta de pedidos e uma terceira que executa SQL livre. A equipe decide não usar o servidor como está: remove a ferramenta de SQL livre em uma cópia própria, fixa a versão, cria um usuário de banco somente leitura sobre uma visão que omite documentos pessoais e roda o piloto com registro de chamadas. Se a manutenção da cópia parecer pesada, a alternativa é escrever um servidor pequeno e próprio, com apenas as duas consultas.

O método que aplicamos nesse tipo de trabalho segue quatro movimentos. Mapear: inventariar ferramentas, dados e o processo atual, com a linha de base de como o trabalho é feito hoje. Limitar: reduzir permissões, campos e ações ao mínimo do fluxo. Pilotar: rodar um fluxo real, com logs e uma métrica de sucesso combinada antes, como descreve o texto sobre como medir um piloto de automação com IA. Transferir: documentar o que foi decidido, nomear o responsável e decidir se o uso será ampliado, ajustado ou encerrado.

Perguntas frequentes

Um servidor MCP oficial do fornecedor dispensa a auditoria? Não dispensa, mas simplifica. A origem tende a ser mais clara, porém você ainda precisa revisar permissões, dados enviados e política de atualização. Um servidor oficial pode expor mais ferramentas do que o seu fluxo precisa.

Servidor MCP local é mais seguro do que remoto? Depende do que cada um faz. O local mantém os dados na sua máquina ou rede, mas roda com o acesso de quem o executou e pode contatar a internet por conta própria. O remoto entrega dados a outro ambiente, o que exige revisão de contrato, retenção e privacidade. Em ambos, a revisão de permissões e de destinos de rede continua necessária.

Quem na empresa deve aprovar a instalação? O ideal é a decisão ser compartilhada entre quem é dono do processo, quem responde por segurança e, se houver dado pessoal, quem cuida da LGPD. Uma pessoa deve ficar como responsável nomeado pelo servidor depois da liberação. Sem essa nomeação, atualizações e revogações ficam sem dono.

Com que frequência devo reauditar? Reaudite sempre que houver mudança de ferramenta, escopo, dependência ou destino de dados, e em uma rotina periódica definida pela empresa. Se o servidor é hospedado pelo fornecedor e muda sem aviso, compense com revisão mais frequente dos registros de chamadas.

Fontes

• Model Context Protocol: introdução
• OWASP Top 10 for LLM Applications
• OWASP: prevenção de prompt injection
• OWASP: guia de autorização