O contrato do MCP não limita sozinho o acesso ao sistema de arquivos

Um servidor MCP pode anunciar uma tarefa estreita e, ao mesmo tempo, executar em um processo que herda acesso muito mais amplo ao host. A diferença entre a função descrita e a capacidade efetiva é uma fronteira de segurança que não pode ser resolvida apenas pelo schema da ferramenta.

Estado: Evidence Brief aprovado para publicação. Série editorial: Papers que lemos por você. Este texto analisa o preprint *MCP Security at Scale*. Não expõe servidores vulneráveis, caminhos, credenciais, payloads ou instruções de exploração; também não afirma que todo servidor MCP é inseguro ou que o estudo mediu efeitos fora das respostas observadas.

O catálogo não é o denominador da confirmação dinâmica

Os autores consolidaram 21.097 servidores de nove registros. Identificaram 17.919 projetos open-source e conseguiram executar a medição de alcance local em 7.222 deles. Depois de triagem, 4.806 servidores seguiram para análise aprofundada e 4.292 tiveram análise estática.

Em 787 dos 4.806 servidores triados, ou 16,4%, apareceu um sinal de nível L1: a implementação possuía capacidade de sistema de arquivos, mas a descrição pública não declarava uma categoria explícita de FileSystem. Isso é um sinal de desalinhamento entre contrato e capacidade, não confirmação de exploração ou vazamento.

Foram confirmadas 150 instâncias, sem uma taxa universal

O pipeline confirmou dinamicamente 150 instâncias em um protocolo de três casos. Em 136, a resposta conteve o marcador exato de credencial usado pelos pesquisadores; em 14, houve outra evidência observável. O paper não fornece um denominador que autorize transformar as 150 confirmações em taxa de prevalência sobre os 21.097 servidores, os 17.919 projetos open-source ou os 7.222 alcançados.

A leitura correta é: houve casos reais confirmados dentro de uma seleção dirigida pelo pipeline. A leitura incorreta seria: uma porcentagem equivalente de todo o ecossistema é vulnerável.

Divulgação coordenada e correções upstream

Os autores prepararam 13 pacotes de divulgação. Duas falhas receberam CVEs e correções upstream:

1. CVE-2025-68143 / GHSA-5cgr-j3jf-jw3v, corrigida na versão indicada pelo advisory em 25/09/2025.
2. CVE-2026-27735 / GHSA-vjqx-cfc4-9h6v, corrigida na versão indicada pelo advisory em 14/01/2026.

Esses advisories corroboram duas ocorrências específicas. Eles não validam toda a metodologia nem transformam os demais achados em vulnerabilidades confirmadas por terceiros.

O contrato de ferramenta não é uma sandbox

Nome, descrição e schema ajudam o modelo a decidir quando chamar uma ferramenta. Eles não retiram permissões do processo que implementa o servidor. Se esse processo herda o diretório do usuário, variáveis de ambiente, sockets ou credenciais, a fronteira real é o conjunto de capacidades do runtime.

Um contrato executável mínimo deve separar:

1. Intenção declarada: o que a ferramenta promete fazer e quais dados espera.
2. Capacidade concedida: arquivos, rede, processos, segredos e identidades disponíveis ao runtime.
3. Política de chamada: quem pode invocar, em qual contexto e com quais argumentos.
4. Efeito observado: recursos realmente lidos, escritos, enviados ou alterados.
5. Aceite e revogação: evidência exigida para promover, limitar ou retirar a integração.

Controles proporcionais

• execute cada servidor com identidade e diretórios mínimos, preferencialmente em isolamento próprio;
• use allowlists de caminhos e destinos, negando acesso por padrão;
• injete segredos de curta duração somente na chamada que os exige;
• valide descrições e schemas contra comportamento observado em ambiente controlado;
• registre chamadas, capacidades concedidas e efeitos sem armazenar conteúdo sensível;
• teste atualização, revogação e rollback antes de permitir uso autônomo;
• trate mudança de dependência ou imagem como nova revisão de fronteira.

Limites e conflito de interesse

Somente 34,2% dos projetos open-source catalogados chegaram à medição de alcance local. Depois desse filtro, 97% da amostra executável ficou concentrada em Node e Python, e 84% dos servidores iniciados vieram de um único registro. Essa seleção limita generalização.

As fronteiras de capacidade foram inferidas por análise e experimentos; não são uma medição completa de todos os efeitos do sistema operacional. O protocolo cobriu ferramentas e sequências selecionadas, usou julgamentos de LLM em partes do pipeline e observou divulgação pela resposta, podendo perder efeitos laterais silenciosos. O sandbox macOS Seatbelt usado pelos pesquisadores não é prova de equivalência com outros sistemas operacionais ou ambientes de produção.

Os autores declaram afiliações à University of Illinois Urbana-Champaign, Santa Clara University, Auburn University at Montgomery e atuação independente. Não localizamos declaração explícita de financiamento ou conflito de interesse no texto consultado. Até o corte editorial, não localizamos reprodução independente completa do levantamento.

Regra de arquitetura

O Forge deve tratar o MCP como código de terceiro com capacidades, não como uma descrição confiável de intenções. A promoção exige que contrato, identidade, isolamento, telemetria e revogação sejam testados juntos. Se o processo pode alcançar um recurso, essa capacidade pertence ao modelo de ameaça mesmo quando não aparece no nome da ferramenta. [R2-C3]

Fontes diretas

1. MCP Security at Scale — arXiv. Preprint, autores, resumo, versão e data.
2. MCP Security at Scale — texto integral. Método, funil, resultados, limitações e divulgação coordenada.
3. GHSA-5cgr-j3jf-jw3v. Advisory público da ocorrência CVE-2025-68143.
4. GHSA-vjqx-cfc4-9h6v. Advisory público da ocorrência CVE-2026-27735.

Nota editorial e de responsabilidade

Este texto combina fatos atribuídos às fontes com análise e proposta técnica do autor. Pontos de vista pessoais e profissionais não são fatos comprovados; dados, denominadores, limites, afiliações e ausência de reprodução independente são indicados quando disponíveis. O conteúdo é informativo e não substitui avaliação técnica, jurídica, regulatória ou de segurança. MCP, projetos, produtos e instituições citados pertencem aos respectivos titulares; não há patrocínio ou endosso. Nenhum alvo, segredo ou procedimento ofensivo é reproduzido. Tech Human e Trustyu atuam comercialmente em desenvolvimento e governança de produtos digitais. Pesquisa, estrutura e redação tiveram assistência de IA; revisão factual, aprovação autoral e publicação foram autorizadas por Fernando Parreiras em 16/10/2026, sem revisão humana independente adicional.

Corte da pesquisa: 16/10/2026. Estado editorial: Evidence Brief especial autorizado para 17/10/2026 às 09h BRT.