O Center for Internet Security (CIS) anunciou, em 16 de setembro de 2026, o CIS MCP Server Benchmark, um padrão de configuração segura para servidores que implementam o Model Context Protocol (MCP) — a camada que conecta assistentes e agentes de IA a dados, aplicativos e serviços externos. Para a equipe defensiva, a decisão prática é imediata: inventariar todos os servidores MCP em operação, locais e remotos, e adotar o benchmark como critério de aceite antes de ampliar o uso de agentes em processos com acesso a dados corporativos. Sem esse controle, cada conector novo amplia a superfície de identidade, acesso e execução sem auditoria equivalente.
O documento é um conjunto desenvolvido por consenso, no mesmo modelo dos demais benchmarks do CIS, e se apresenta como padrão neutro de fornecedor para proteger dados sensíveis, controlar acesso a recursos e reduzir riscos em implantações de MCP. O download é gratuito no site da organização, o que remove a desculpa do custo para começar a avaliação ainda nesta semana.
Por que MCP virou superfície crítica
O MCP padronizou a integração entre modelos de IA e ferramentas externas. Em vez de uma integração proprietária para cada par modelo-ferramenta, um único protocolo descreve como um agente descobre capacidades, chama ferramentas, lê documentos estruturados e interage com sistemas internos. A comodidade tem custo: quando um agente pode invocar ferramentas privilegiadas, cada servidor MCP passa a ser um ponto de decisão sobre identidade, escopo e privilégio — e uma configuração descuidada converte conveniência em vetor de ataque.
O risco não é teórico. Segundo o próprio CIS, servidores MCP frequentemente dão acesso a bancos de dados, sistemas de arquivos, serviços de nuvem e navegadores; uma configuração equivocada cria oportunidades de acesso não autorizado, exposição de dados, manipulação de ferramentas e execução de código não confiável. São quatro modos de falha que misturam vazamento de informação com execução arbitrária — a combinação que qualquer equipe de resposta teme encontrar consolidada em ambiente de produção. Há ainda um fator de cadeia de suprimentos: boa parte dos servidores MCP usados em empresas vem de repositórios de terceiros, sem processo formal de aprovação, o que torna o domínio de supply chain do benchmark tão relevante quanto o de autenticação.
O que o benchmark exige
O novo documento reúne 55 recomendações prescritivas organizadas em 10 domínios de segurança: governança e versionamento; transporte e conectividade; autenticação e autorização; configuração de cliente (host); configuração de servidor; proteção de dados e privacidade; observabilidade e auditoria; segurança da cadeia de suprimentos; isolamento e segurança de execução; e limites de recursos com cache. A estrutura cobre o ciclo completo, da decisão de governança sobre qual versão do protocolo adotar até a cota de recursos por sessão.
Para quem já audita sistemas com outros benchmarks do CIS, o formato é familiar: cada item traz justificativa, procedimento de auditoria e orientação de remediação. Isso significa que o documento serve tanto para fortalecer a configuração de implantações novas quanto como roteiro de avaliação para auditores internos e fornecedores — uma recomendação que falha na auditoria vira item de plano de correção, não opinião.
O escopo inclui implantações locais e remotas, com atenção explícita a gateways e proxies usados para intermediar conexões entre sistemas de IA e recursos externos — justamente a topologia que empresas adotam quando precisam centralizar o controle sobre agentes de múltiplos fornecedores. O domínio de governança e versionamento merece leitura atenta: fixar a versão da especificação em uso e formalizar o processo de aprovação de novos servidores são exigências que a maioria das empresas ainda não tem escrita em lugar algum.
Tokens: a falha mais comum
Entre os domínios do benchmark, autenticação e autorização concentram o erro que mais compromete implantações reais: o tratamento de tokens de acesso. As considerações de segurança da especificação oficial do protocolo são categóricas sobre o dever do servidor: rejeitar tokens sem vínculo de audiência. Um servidor MCP deve aceitar somente tokens emitidos especificamente para ele e recusar qualquer token que não o inclua na declaração de audiência — caso contrário, um token válido para outra API vira passe livre para as ferramentas do agente.
A regra complementar proíbe o repasse: quando o servidor MCP chama APIs de montante, ele atua como cliente OAuth e deve usar um token próprio, emitido pelo servidor de autorização daquela API. Repassar o token recebido do cliente — o chamado token passthrough — é expressamente vedado pela especificação. A mesma disciplina de audiência e vida curta de token aparece no guia do NIST e da CISA contra roubo de tokens em nuvem; quem já aplicou aquele roteiro reutiliza aqui a maior parte do trabalho.
A especificação também trata do ciclo de vida: servidores de autorização devem emitir tokens de acesso de vida curta para reduzir o impacto de vazamento, e clientes precisam implementar PKCE nos fluxos de código. Para a equipe defensiva, o teste prático é curto: apresentar a um servidor MCP um token válido emitido para outro recurso e verificar se a chamada é recusada. Se passar, a correção é P1.
Como auditar em duas semanas
O formato do benchmark — recomendação, auditoria, remediação — permite um ciclo curto e verificável. Um plano mínimo para uma operação de porte médio:
| Etapa | Dias | Foco | Resultado esperado |
|---|---|---|---|
| 1 | 1 a 3 | Inventário de servidores MCP, locais e remotos, e dos gateways em uso | Lista completa com dono, transporte e exposição |
| 2 | 4 a 7 | Autenticação e autorização: audiência de token, repasse e escopos por ferramenta | Todos validam audiência; nenhum repassa token |
| 3 | 8 a 10 | Transporte, isolamento e limites de execução | HTTPS obrigatório; execução confinada; cotas por sessão |
| 4 | 11 a 13 | Observabilidade: correlação entre identidade, sessão e ferramenta invocada | Log pesquisável por chamada, sem segredos em claro |
| 5 | 14 | Relatório com lacunas classificadas e plano P1/P2 | Roteiro aprovado pela governança |
Sobre a etapa 4: o benchmark trata observabilidade e auditoria como domínio próprio, não como item opcional. O padrão mínimo de visibilidade do ENISA oferece a referência prática de quais eventos precisam existir antes que qualquer investigação se torne possível.
Sinais de exposição no ambiente
Quatro sinais indicam que a implantação merece prioridade máxima: o servidor aceita qualquer token assinado pelo provedor de identidade, sem checar audiência; nenhum log correlaciona identidade, sessão e ferramenta invocada; o agente recebe um escopo único e amplo para todas as ferramentas; e o gateway repassa tokens entre cliente e APIs externas. Qualquer um deles, isolado, já justifica abrir correção antes de adicionar novos conectores ao ambiente.
Prioridades P1 e P2
P1, nesta semana: inventário completo dos servidores MCP em produção; validação de audiência em todos eles; bloqueio definitivo do repasse de token; e HTTPS em todo transporte remoto. São correções baratas, de efeito imediato sobre os quatro modos de falha descritos pelo CIS e verificáveis com testes simples de token inválido.
P2, no trimestre: limites de recursos e política de cache por sessão; fixação de versões e verificação de integridade na cadeia de suprimentos dos servidores adotados; segregação de execução para ferramentas que manipulam arquivos ou executam comandos; e revisão de escopos por ferramenta, eliminando permissões agregadas. A meta é que o próximo agente aprovado na empresa já nasça dentro do benchmark — e não como exceção a ser corrigida depois.