Diga sim ao MCP com segurança: um guia para governar agentes de programação com IA com Evo ADS

Quando anunciamos que a Governança de MCP está disponível para todos no Evo Agentic Development Security (ADS), a pergunta prática que mais ouvimos foi: "Ótimo. Por onde começo na segunda-feira?"

É uma pergunta justa: em 10.000 ambientes de desenvolvimento, a Snyk identificou 4.524 servidores MCP exclusivos em uso ativo, e 1 em cada 12 desenvolvedores com um servidor MCP instalado tinha uma descoberta confirmada de gravidade alta ou crítica. A maioria desses servidores foi adicionada em segundos por um desenvolvedor que queria fazer o agente realizar algo útil, sem nenhuma análise prévia.

Esta é a nossa resposta: quatro etapas levam você do inventário inicial a políticas que bloqueiam apenas os servidores arriscados. Agora, o Evo ADS atribui uma pontuação de risco aos servidores MCP para que você possa governar com base no risco, com ou sem uma lista de permissões, em vez de analisar cada servidor manualmente ou bloquear tudo e desacelerar os desenvolvedores. Tudo é executado no endpoint onde os agentes já trabalham, por meio de hooks leves, sem proxy no caminho. Descubra o que existe, defina o que é aceitável, observe o que sua política identifica e aplique-a com confiança.

Etapa 1: descubra o que já está em execução

Os servidores MCP não passam por revisões de CI nem de dependências. Um desenvolvedor edita um arquivo de configuração e o agente ganha um novo conjunto de ferramentas. Portanto, o primeiro passo é descobrir o que já existe. Não é possível governar o que não se consegue ver, então o Evo ADS oferece duas visualizações:

• Servidores MCP nas máquinas dos desenvolvedores: implante o instalador do Evo ADS em toda a sua frota. Ele mostra os servidores MCP aos quais os agentes realmente se conectam, inclusive instalações locais pontuais que nunca tocaram em um repositório.

• Servidores MCP em repositórios de código: o Evo AI-SPM, configurado pela integração de SCM da Snyk, encontra servidores MCP referenciados no seu código.

Juntas, essas visualizações respondem a duas perguntas diferentes: o que está configurado no código e o que está em execução nos laptops. Ambas aparecem na interface do Evo, em Inventário → Servidores MCP.

Você também pode usar o Evo MCP Server para acessar esses dados pelo seu próprio fluxo de trabalho agentivo. Assim, você tem uma única visão do seu ambiente MCP, sem nada bloqueado e sem interromper o trabalho dos desenvolvedores. Com essa etapa, você já consegue responder a uma pergunta que a maioria das equipes de segurança não consegue: a que nossos agentes estão conectados?

Etapa 2: defina o que significa "aceitável"

Decidir se o servidor número 47 é aceitável não deveria exigir uma conversa no Slack e uma pesquisa na web. O Evo ADS coloca as evidências ao lado de cada servidor para que você possa aprovar ou rejeitar mais rápido e com confiança.

Analise o inventário

Um servidor não oficial, de alto risco e instalado amplamente representa um problema muito diferente de um servidor de alto risco em uma única máquina. Cada linha responde às perguntas que você teria de investigar manualmente: quem criou o servidor, onde está instalado, se alguém o aprovou e qual é o nível de risco:

• Servidor: nome, origem (por exemplo, NPM), transporte (SSE ou STDIO) e se é local.

• Origem do fornecedor: se o servidor é oficial. Ser desconhecido também é um sinal.

• Origem: quantas vezes aparece no código, nas máquinas e em tempo de execução.

• Status da lista de permissões: permitido ou não permitido.

• Pontuação de risco: uma pontuação unificada por servidor, que pode ser ordenada e filtrada.

• Problemas por gravidade: contagens de problemas críticos, altos, médios e baixos.

Ordene pela pontuação de risco e depois confira os resultados.

Abra o perfil de risco

Clique em um servidor para ver os detalhes. O cabeçalho inclui os métodos de autenticação, e três cartões mostram onde ele está: declarado no código, em quantas máquinas está instalado e quando foi a última verificação, além da frequência com que os agentes o chamaram nos últimos sete dias.

Em seguida, abra a aba Perfil de risco. É ela que substitui a conversa no Slack e a pesquisa na web.

Em um dos servidores que analisamos, o Evo encontrou descrições de ferramentas com a expressão “ignore as instruções anteriores” em 8 de 12 ocorrências. Isso é uma injeção de prompt que você só identificaria lendo cada descrição de ferramenta por conta própria.

As pontuações vão de 0 a 1.000:

• Baixo (0 a 249)

• Médio (250 a 499)

• Alto (500 a 749)

• Crítico (750 a 1.000)

A aba divide a pontuação em atributos como injeção de prompt na descrição da ferramenta, recursos destrutivos e conteúdo não confiável, cada um com pontuação de até 1.000. Expanda um atributo para ver uma descrição e a explicação "Por que esse risco?", com as evidências.

Esse servidor já estava na lista de permissões. Alguém o aprovou, mas ele ainda tem pontuação 931, claramente na faixa crítica. Uma lista de permissões registra uma decisão tomada em determinado momento; a pontuação de risco mostra quando é hora de reavaliá-la. Você pode mudar o status para “Não permitido” nesta página ou bloquear o servidor em tempo de execução.

Como os servidores recebem pontuações

A pontuação de risco de MCP combina três sinais: o comportamento do servidor (as instruções e descrições de ferramentas que ele envia aos agentes), a confiabilidade (a reputação dos URLs e a identidade dos responsáveis pela manutenção) e, para servidores locais com código-fonte disponível, a implementação, a manutenção e as dependências. Uma limitação é que o Evo não consegue identificar com confiança servidores sem assinatura. Eles representam menos de 20% dos servidores e não recebem pontuação. Inclua-os no seu processo de análise.

Defina sua linha de base

A lista de permissões registra os servidores MCP que você aprovou. Cada servidor tem uma opção: aprovado ou não. Altere-a, e a decisão aparecerá na coluna Status da lista de permissões do inventário (Permitido ou Não permitido), para que todas as pessoas que consultarem o inventário vejam o mesmo status. Veja a lista de permissões na visualização de detalhes de um servidor para consultar a lista completa.

Comece pelo que você já considera confiável; não é preciso criar a lista do zero. Use como base um inventário existente, uma lista selecionada ou os servidores que o Evo ADS já descobriu. Altere manualmente o status dos servidores no inventário ou simplesmente peça ao Evo pelo chat.

Para cada candidato, confira o que você descobriu acima: a faixa de pontuação, se o fornecedor é oficial, como ocorre a autenticação e, para tudo que tiver risco alto ou crítico, as evidências em "Por que esse risco?". Um servidor oficial, autenticado e com pontuação baixa é fácil de aprovar. Um servidor crítico merece uma justificativa antes da aprovação — e rejeitá-lo é perfeitamente válido.

Lembre-se: a lista de permissões registra decisões. Ela não bloqueia nada por si só. As políticas são aplicadas com base nessas decisões — é aí que entram as próximas etapas.

Etapa 3: monitore antes de bloquear

Ativar o bloqueio logo no primeiro dia pode interromper fluxos de trabalho dos desenvolvedores que você ainda nem conhece. O modo de monitoramento mostra exatamente o que sua política bloquearia, antes de bloquear qualquer coisa. Crie sua primeira política usando o modelo Monitorar servidores MCP não permitidos na página de políticas (Políticas → Problemas → Criar política). Ela sinaliza cada servidor arriscado como um problema para análise, sem bloquear nada. Assim, desenvolvedores e agentes continuam trabalhando, e você cria uma lista atualizada de tudo que a política identificaria.

Depois, trabalhe com essa lista em Inventário → Servidores MCP, usando as informações da linha e do Perfil de risco que você conheceu na Etapa 2. Para cada servidor sinalizado, confira a pontuação, se é oficial, como ocorre a autenticação e quais atributos contribuíram para a pontuação. Então, decida: aprove-o e inclua-o na lista de permissões ou rejeite-o. Faça isso por uma ou duas semanas e observe os padrões. Um servidor que aparece uma vez pode ser apenas uma curiosidade, mas um que aparece em cinquenta máquinas exige uma decisão deliberada.

Ao final da segunda semana, você terá uma política alinhada à sua tolerância a riscos, testada no seu ambiente real e já conhecida pela equipe de segurança e pelos desenvolvedores antes de começar a bloqueá-los.

Etapa 4: aplique a política, começando pelo que é arriscado

Quando confiar no que a política identifica, ative a aplicação. O modelo de política Bloquear servidores MCP não permitidos (Políticas → Políticas → Criar política) impede que agentes de programação chamem, em tempo de execução no endpoint, servidores que não estejam na sua lista de permissões e tenham risco alto ou crítico. Se o modelo não corresponder à sua tolerância a riscos, use Começar do zero e crie uma política personalizada com seus próprios critérios.

A política só bloqueia um servidor quando ele está fora da sua lista de permissões e tem risco alto ou crítico. Todo o resto continua funcionando em modo de registro, então um servidor de baixo risco que ainda não foi aprovado não interrompe o trabalho de um desenvolvedor, e você mantém um registro de auditoria. Além disso, a aplicação ocorre localmente, em tempo de execução, na máquina do desenvolvedor, por meio de hooks leves que funcionam junto ao agente, e não como proxy ou gateway no caminho. Você define a política uma única vez, de forma centralizada. Os hooks a aplicam em cada máquina no momento em que o agente chama o servidor, seja no Claude Code, Cursor, Codex ou GitHub Copilot.

Diga sim ao MCP, com controle

Na segunda-feira, você implanta o instalador e conecta seu SCM; na sexta-feira, já tem um inventário e uma lista de permissões inicial. Com o Evo ADS, você pode dizer sim ao MCP e ainda saber a que seus agentes estão conectados, tomar decisões rápidas e bloquear o que é arriscado. Este é o primeiro caso de uso de Governar o comportamento dos agentes, e estamos só começando: ao longo do ano, o mesmo modelo de descoberta, classificação e aplicação será estendido a habilidades de agentes, acesso a dados confidenciais, proteção contra injeção de prompt e exposição de segredos.

Quer saber a que seus agentes estão conectados? Agende uma demonstração ou conheça o Evo Agentic Development Security.