Evo ADS Govern Agent Behavior já está disponível: controle o uso de MCP

Hoje, anunciamos que o Govern Agent Behavior, recurso do Evo Agentic Development Security (ADS) que controla o que os agentes de programação com IA podem fazer em tempo de execução, está disponível para todos, começando pelo MCP Governance.

Desde que apresentamos o Evo ADS em junho, temos desenvolvido uma ideia simples: o desenvolvimento agentivo apresenta riscos em três frentes, e cada uma exige uma forma própria de controle:

1. O que os agentes usam: servidores MCP, habilidades e ferramentas que incorporam e que precisam ser descobertos e avaliados.

2. O que os agentes geram, que precisa ser validado no momento da criação.

3. E o que os agentes fazem: as ações que executam depois de decidir agir e que precisam ser controladas em tempo real.

O Govern Agent Behavior é a resposta do Evo ADS a essa terceira questão, e o MCP Governance é o primeiro caso de uso disponibilizado.

Na prática, o MCP Governance permite que as equipes de segurança e plataforma descubram todos os servidores MCP em seu ambiente, definam quais podem ser usados, identifiquem quando um agente sai da política estabelecida e registrem ou bloqueiem o uso de MCP no momento da execução, em tempo real, no Claude Code, Cursor, Codex e GitHub Copilot.

Controlar quais ferramentas um agente autônomo pode usar é fundamental: é o tipo de controle que a maioria das equipes de segurança presumia já existir, até procurar por ele e não encontrar nada. O MCP Governance preenche essa lacuna de forma nativa, no mesmo fluxo de trabalho em que a cadeia de suprimentos dos agentes é descoberta e o código gerado por IA é validado, em vez de ser uma ferramenta separada, adicionada à parte.

Por que é importante governar o MCP agora

O Model Context Protocol (MCP) é o padrão que permite que agentes de programação com IA se conectem a ferramentas externas, fontes de dados e sistemas — incluindo repositórios, bancos de dados, infraestrutura em nuvem e APIs internas — por meio de uma interface comum. Esse é um dos principais motivos pelos quais os agentes estão deixando de parecer um recurso de preenchimento automático e se assemelhando cada vez mais a colegas de trabalho: um agente com acesso ao MCP não apenas sugere uma linha de código; ele pode consultar um sistema de chamados, buscar registros em um banco de dados de produção ou chamar um serviço interno, tudo na mesma sessão.

Esse poder também é o problema. O MCP padroniza como os agentes se conectam às ferramentas, mas não define quais ferramentas devem ser confiáveis nem o que um agente pode fazer com aquelas às quais tem acesso. Cada servidor MCP ao qual um agente se conecta é, na prática, um novo componente da cadeia de suprimentos de software. Só que, ao contrário de uma dependência fixada em um manifesto, ele costuma ser introduzido dinamicamente, quando um desenvolvedor o instala em poucos segundos, sem nenhum processo de revisão.

Essa exposição não é hipotética nem recente; é o mesmo problema de pacotes maliciosos, agora por outra porta. Um servidor MCP comprometido pode ler arquivos locais, exfiltrar credenciais ou acessar sistemas internos assim que é executado, antes mesmo de a equipe de segurança saber que ele existe — muito menos ter a chance de analisá-lo. O risco se concretiza na máquina do desenvolvedor, no momento em que o servidor é chamado. É nesse ponto que precisa ser detectado.

A escala é maior do que a maioria das equipes de segurança imagina. Dados das próprias análises da Snyk, coletados em quase 10 mil ambientes de desenvolvimento, identificaram 4.524 servidores MCP exclusivos em uso ativo. Nas máquinas com mais instrumentação, havia 13 ou mais em execução simultânea. Mais da metade dos desenvolvedores já tem conexões MCP ativas com ferramentas e sistemas de produção. E, ao analisarmos a postura de segurança dessas conexões, constatamos que 1 em cada 12 desenvolvedores com um servidor MCP instalado tinha uma vulnerabilidade confirmada de gravidade alta ou crítica.

Nada disso aparece em um pipeline tradicional de AppSec, porque servidores MCP não são artefatos analisados em CI nem dependências revisadas antes do merge. Em vez disso, são introduzidos em tempo real, durante a execução, muitas vezes fora de qualquer processo que a equipe de segurança consiga acompanhar. Sem uma forma de definir quais servidores MCP são aceitáveis e aplicar essa política quando um agente tenta usar um deles, “adotar agentes de IA” e “ampliar a superfície de ataque não gerenciada” acabam sendo a mesma coisa.

Como o MCP Governance funciona no Evo ADS

O MCP Governance é a resposta do Evo ADS a essa lacuna e amplia diretamente a visibilidade que o Evo ADS já oferece sobre a cadeia de suprimentos dos agentes. Ele faz três coisas:

1. Envie sua lista para a Snyk

As equipes de segurança e plataforma definem quais servidores MCP são aprovados com base em um inventário existente, uma lista organizada manualmente ou nos servidores que o Evo ADS já identificou durante a descoberta. Essa lista se torna a política de referência usada para avaliar todos os agentes do ambiente. Você pode fazer isso manualmente ou simplesmente pedir ao Evo pelo chat!

2. Identifica o uso fora da política

Com a política definida, o Evo ADS monitora continuamente a atividade MCP nos computadores dos desenvolvedores e identifica cada vez que um agente tenta acessar um servidor que não está na lista de aprovados — seja uma instalação local pontual ou um padrão que apareça em todo o ambiente. Não é preciso bloquear nada para que essa visibilidade seja útil; para muitas equipes, saber a que os agentes realmente se conectam já representa o primeiro inventário de verdade.

3. Controla o uso em tempo de execução

É aqui que a visibilidade se transforma em controle. O Evo ADS pode registrar o uso não autorizado de MCP para fins de auditoria ou bloqueá-lo diretamente no endpoint, no momento em que o agente tenta se conectar — sem esperar que aconteça e sem depender da decisão do agente de cumprir a política.

O MCP Governance funciona onde seus agentes já são executados. Ele está disponível hoje no Claude Code, Cursor, Codex e GitHub Copilot, com aplicação por meio de hooks leves que operam junto ao agente, sem direcionar o tráfego por um proxy ou gateway separado. Essa é a mesma abordagem que o Evo ADS usa para analisar o código com segurança desde o início. Assim, as equipes não precisam mudar a forma como os agentes se conectam às ferramentas, implementar uma nova infraestrutura nem aceitar um novo ponto de falha no fluxo de execução do agente. A política é definida centralmente; a aplicação acontece localmente, no ponto em que se decide usar um servidor MCP.

O que vem por aí na governança do comportamento dos agentes

Estamos chamando isso deliberadamente de primeiro caso de uso, não de história completa. O MCP Governance responde à pergunta: “Este agente pode acessar esta ferramenta?” É uma pergunta necessária, mas não é a única. Mesmo trabalhando apenas com um servidor MCP aprovado, um agente ainda pode executar um comando de shell destrutivo ou enviar dados confidenciais para onde não deveria — e o MCP Governance, sozinho, não detectará isso.

É aí que o Evo ADS avança. Nas próximas semanas, vamos ampliar a aplicação das políticas para além da lista de permissões MCP, para abranger e bloquear ações realizadas por agentes. Também vamos deixar de usar uma lista estática como política MCP: as equipes poderão alimentá-la diretamente de um repositório Git ou de uma página do Confluence usando o Evo MCP. E vamos avançar para a aplicação de políticas baseada em risco, para que elas reflitam o risco real de cada servidor, em vez de se limitarem a permitir ou negar o acesso.

Além disso, ao longo do ano, vamos ampliar a cobertura do ADS para controlar o acesso não autorizado a dados confidenciais, oferecer proteção contra injeção de prompt e evitar a exposição de segredos em agentes. Também vamos levar o mesmo modelo de descoberta, classificação e aplicação de políticas apresentado pelo MCP Governance para Agent Skills.

Controlar o que os agentes usam é necessário. Controlar o que fazem, no momento em que fazem, é o que torna essa governança real. O MCP Governance é a primeira prova disso — e já está disponível.

Quer ver o MCP Governance em ação? Agende uma demonstração ou conheça o Evo Agentic Development Security para saber como o Evo ADS protege o que os agentes usam, fazem e geram ao longo do ciclo de vida do desenvolvimento com IA.