2026-07-31 · PESQUISA · A equipe da Offensive Technology

Segurança de Servidores MCP Remotos: O que Mostra um Censo de 19,321 Servidores Publicados

Metade dos servidores no registro oficial do Model Context Protocol é remota. Coletamos a população publicada completa em 31 de julho de 2026, 19,321 servidores únicos, e analisamos como cada um é distribuído. 50.0% expõem um endpoint remoto, uma URL à qual seu agente de IA se conecta pela rede para que o código seja executado na máquina de outra pessoa e você veja apenas os resultados retornados. A outra metade, 48.3%, são pacotes locais que rodam na sua própria máquina onde você pode inspecioná-los. Essa única divisão é a questão de segurança embutida em cada instalação de MCP: você está adicionando uma biblioteca que controla ou conectando seu agente ao servidor de um desconhecido? Além disso, 30.5% dos servidores solicitam uma credencial antes de serem executados, e a metade remota aponta para 7,420 hosts de terceiros distintos. Nenhum desses números identifica um servidor, uma empresa ou uma pessoa. Eles são as taxas base de um ecossistema que a maioria das equipes está adotando mais rápido do que auditando.

O que um servidor MCP remoto realmente é

O Model Context Protocol é a infraestrutura de conexão que permite a um agente de IA chamar ferramentas externas: ler um ticket, consultar um banco de dados, abrir um pull request. Um servidor disponibiliza um conjunto de ferramentas, o agente escolhe uma, envia argumentos e lê a resposta de volta em seu contexto de trabalho. Existem duas maneiras pelas quais esse servidor pode chegar até você. Um local servidor é um pacote, no npm, PyPI ou uma imagem OCI, que você instala e executa; ele conversa com o agente via stdio na sua própria máquina. Um remoto servidor é uma URL. Seu agente abre uma conexão com ele, envia chamadas de ferramentas e recebe os resultados de volta via streaming.

A diferença é uma fronteira de confiança. Com um servidor local, o código, as dependências e as chamadas de rede de saída estão todos em hardware que você controla e pode inspecionar. Com um servidor remoto, o código fica na infraestrutura do operador. Você não o vê, não pode fixar sua versão exata por hash como faz com um pacote, e cada argumento enviado pelo seu agente, junto com o que ele escolheu incluir como contexto para a chamada, é transmitido para esse operador. Os resultados da ferramenta retornados são então aceitos pelo agente como se fossem seu próprio raciocínio. Esse caminho de retorno é exatamente onde residem o tool-poisoning e a injeção indireta de prompt.

Como os 19,321 servidores publicados são distribuídos

Aqui está toda a população, detalhada por como cada servidor alcança seu agente. A proporção remota é o destaque, porque é onde a fronteira de confiança sai da sua máquina.

Vale a pena declarar a divisão exata com clareza, pois as metades arredondadas escondem um detalhe. Dos 19,321 servidores, 8,642 (44.7%) são apenas remotos, sem nenhum pacote local que você possa executar em vez disso. Outros 1,014 (5.2%) oferecem ambos um endpoint remoto e um pacote local, para que você possa escolher. 9,323 (48.3%) são apenas pacotes locais, e uma parcela residual de 342 (1.8%) não declarou nem pacote nem endpoint funcional. Portanto, quando um servidor é remoto, na maioria das vezes ele é remoto sem alternativa: usá-lo significa aceitar o endpoint de terceiros, ou não usá-lo.

A solicitação de credenciais: um terço dos servidores quer suas chaves

Uma ferramenta que lê seus issues no GitHub ou consulta sua stack de observabilidade precisa se autenticar em algum lugar, portanto, solicitações de credenciais são esperadas. Ainda assim, vale destacar o número: 30.5% dos servidores publicados, 5,888 deles, declaram pelo menos uma credencial no formato de segredo, uma variável de ambiente ou cabeçalho de autenticação cujo nome contém um token como KEY, TOKEN, SECRET, PASSWORD, ou AUTH. Aproximadamente um em cada três servidores exige uma credencial ativa antes de fazer qualquer coisa.

Junte isso à proporção de servidores remotos e o risco se acentua. Quando você fornece uma credencial a um servidor local, o segredo permanece no seu ambiente e a ferramenta o utiliza a partir da sua máquina. Quando você fornece uma credencial a um servidor remoto, você a está transferindo para o operador ou autorizando o operador a agir em seu nome com ela. De qualquer forma, o operador se torna um detentor da sua chave. Se esse operador for descuidado com logs ou for comprometido, a credencial que você definiu para uma ferramenta se torna de um atacante. O privilégio mínimo não é opcional aqui: um servidor deve receber um token restrito exatamente ao que suas ferramentas precisam e nada mais.

Onde os endpoints remotos realmente estão hospedados

A metade remota não se resume a um punhado de nuvens de confiança. Os 9,656 servidores com endpoint remoto estão distribuídos por 7,420 hosts distintos. A cauda longa é real: 98.1% desses hosts servem exatamente um servidor, o que representa muitos operadores independentes, cada um sendo uma parte separada que você precisaria avaliar. Se seus agentes adotassem o registro integralmente, estariam abrindo conexões para milhares de endpoints diferentes, a maioria mantida por alguém de quem você nunca ouviu falar.

No outro extremo da distribuição está a concentração. O maior host de gateway individual responde por 13.5% de todos os servidores remotos, e os dez hosts mais movimentados respondem por 18.9% dos endpoints remotos somados. Cerca de um quarto dos servidores remotos utiliza um host compartilhado e multi-tenant em vez de um domínio próprio. Essa é a faca de dois gumes de qualquer marketplace: alguns agregadores concentram uma grande fatia do tráfego, o que é conveniente, mas também significa que um único operador ou uma única interrupção impacta uma grande fração do ecossistema. Não estamos nomeando esses hosts; o ponto é a estrutura, não o endereço.

O alarme falso: Unicode oculto

Um ataque de MCP bem demonstrado oculta instruções para o agente dentro dos campos de texto que um servidor publica, usando caracteres invisíveis: codepoints de tags Unicode, zero-width joiners, controles bidirecionais, sequências de escape ANSI. O agente os lê, um revisor humano não. Escaneamos todos os campos de texto visíveis pelo modelo de todos os 19,321 servidores em busca dessas classes de codepoints. O resultado é nulo: 0 de 19,321 servidores continham caracteres não imprimíveis ou da classe de injeção em seus metadados de registro.

Essa é uma boa notícia com limites, e esses limites importam. O registro publica o nome, título e descrição de um servidor, mas não as descrições das ferramentas individuais que ele expõe, que são os campos carregados no contexto do agente a cada chamada e o alvo mais rico para um ataque de instruções ocultas. Nosso resultado nulo indica que a própria camada de metadados do registro está limpa hoje. Ele não diz que as ferramentas por trás desses servidores estejam, porque o registro não disponibiliza essa superfície para leitura passiva. Portanto, o resumo honesto é restrito: na camada que podemos medir sem tocar no servidor de ninguém, o canal de caracteres invisíveis não está sendo utilizado.

A visão do atacante sobre este registro

Olhe para esses números sob a perspectiva de quem decide se um controle é relevante. Um atacante que deseja entrar em uma organização por meio de suas ferramentas de IA tem duas jogadas óbvias aqui, e o censo mostra que ambas são viáveis em escala. A primeira é operar um servidor: publicar algo útil, fazer com que seja instalado e, agora, você recebe legitimamente cada requisição que o agente envia e controla cada resultado que ele lê. Com metade do registro já sendo remoto, mais um servidor remoto não levanta suspeitas. A segunda é comprometer um operador que já possui a confiança de muitas equipes, e a concentração no topo da distribuição de hosts mostra onde está esse ponto de apoio.

O número de credenciais é o multiplicador. Um terço dos servidores já recebe a confiança de guardar um segredo, portanto, um servidor envenenado ou dominado não se limita a ler tráfego; ele pode deter chaves que alcançam os sistemas por trás das ferramentas. Essa é a mesma expansão de superfície que descrevemos em nosso guia sobre o que atacantes podem realmente ver sobre sua empresa, movida uma camada para dentro: a superfície não é mais apenas seu DNS e serviços públicos, é o conjunto de servidores externos com os quais seus agentes estão autorizados a se comunicar. Cada um deles é uma dependência, e dependências são como as intrusões modernas começam.

Como manter os servidores MCP remotos sob controle

Nada disso é um argumento contra servidores MCP remotos. É um argumento para tratá-los como as dependências de terceiros que são. Se você executa agentes contra ferramentas MCP, esta é a lista de recomendações.

• Mantenha uma lista de permissões (allow-list), não um registro aberto. Decida quais servidores específicos seus agentes podem usar e fixe-os. Com metade do registro sendo remoto, metade dele é um operador que você está escolhendo confiar, portanto escolha deliberadamente em vez de instalar assim que descobrir.
• Prefira o local quando ambos existirem. Para os 5.2% que fornecem tanto um pacote quanto um endpoint, o pacote local mantém o código e seu tráfego na sua máquina. Escolha-o quando a ferramenta não precisar genuinamente ser remota.
• Restrinja o escopo de cada credencial à ferramenta. Com 30.5% dos servidores solicitando um segredo, emita um token limitado exatamente ao que as ferramentas do servidor exigem, faça a rotação dele e nunca forneça uma chave abrangente a um servidor que você não tenha auditado.
• Trate a saída da ferramenta como entrada não confiável. Os resultados retornados por um servidor podem conter instruções direcionadas ao seu agente. Restrinja o que o agente tem permissão para fazer com eles e não permita que o resultado de uma ferramenta acione silenciosamente ações privilegiadas.
• Saiba quem está na outra ponta. Um endpoint remoto aponta para o host de alguém. Para os servidores dos quais você depende, conheça o operador e lembre-se de que a maioria dos hosts neste registro atende a um único servidor mantido por uma única parte.

Metodologia, para que um cético possa confiar nos números

O conjunto de dados é próprio, construído a partir de uma fonte pública, contendo apenas dados agregados. Consultamos a API pública do registro oficial do Model Context Protocol e navegamos por todo o catálogo em 31 de julho de 2026, armazenando 62,430 registros de versões. Reduzimos isso aos 19,321 servidores marcados como a versão atual e mais recente, que é a população ativa sem duplicatas e o denominador para cada porcentagem aqui. A implantação foi classificada a partir dos pacotes declarados e endpoints remotos de cada servidor; a contagem de credenciais considera qualquer variável de ambiente declarada ou cabeçalho de autenticação cujo nome contenha um token no formato de segredo; a concentração de hosts foi calculada resolvendo o hostname de cada endpoint remoto; e a verificação de caracteres ocultos testou cada campo de texto em relação ao bloco de tags Unicode, caracteres de formatação de largura zero e bidirecionais, sequências de escape ANSI e outros codepoints de controle e uso privado.

Lemos apenas a própria API pública do registro. Não nos conectamos a nenhum dos servidores que ele lista, não enviamos nenhuma requisição para o endpoint de nenhum operador e não coletamos nada sobre nenhum indivíduo. Ler um catálogo público é um ato passivo; acessar os hosts nele não seria, e não o fizemos.

O que isso não prova

Um número sem seus limites é apenas marketing, portanto aqui estão as restrições desses dados.

• Trata-se de apenas um registro. O registro oficial é o catálogo central, mas existem servidores que nunca são publicados nele, e outros diretórios listam os seus próprios. Isso mede a população publicada e identificável, não todos os servidores existentes.
• Declarado, não observado. A implantação e as credenciais vêm do que cada servidor declara em sua entrada no registro. Um servidor poderia exigir um segredo que não listou, ou fornecer um pacote que realmente não suporta. Medimos o manifesto, não uma instalação em execução.
• Remoto é uma superfície de risco, não um veredito. Um servidor remoto não é inseguro por ser remoto. Muitos são bem gerenciados por operadores sérios. Os 50.0% representam o tamanho da decisão de confiança, não a contagem de agentes maliciosos.
• O resultado nulo tem escopo definido. Zero ocorrências de caracteres ocultos cobre apenas os campos do registro no nível do servidor. As descrições por ferramenta que são carregadas em um agente a cada chamada não são publicadas para leitura passiva, portanto isso não é um atestado de segurança para as ferramentas em si.
• Trata-se de um panorama pontual. O registro cresce diariamente. Esses números descrevem o estado em 31 de julho de 2026, não uma tendência, e uma nova coleta no próximo mês alterará os valores.

Perguntas frequentes

É seguro usar servidores MCP remotos?

Um servidor MCP remoto é tão seguro quanto o operador que o executa, porque seu agente envia requisições e lê resultados do endpoint desse operador. Neste censo, 50.0% dos servidores eram remotos, e todos usavam HTTPS, portanto o transporte não é a lacuna. A lacuna é a confiança. Fixe os servidores que você avaliou e atribua a cada um credenciais de privilégio mínimo.

Qual é a diferença entre um servidor MCP local e um remoto?

Um servidor local roda como um pacote na sua própria máquina, para que seu código e chamadas de rede possam ser inspecionados por você. Um servidor remoto é uma URL à qual seu agente se conecta, de modo que o código roda na infraestrutura de outra pessoa e você vê apenas as respostas. No censo, 48.3% eram apenas locais, 44.7% apenas remotos e 5.2% ofereciam ambos.

Quantos servidores MCP existem?

O registro oficial listava 19,321 servidores publicados únicos quando coletamos a população completa em 31 de julho de 2026, contando apenas a versão mais recente de cada um. Ele está crescendo rapidamente, portanto trate isso como um retrato datado.

Servidores MCP exigem chaves de API ou credenciais?

Muitos exigem. No censo, 30.5% dos servidores declararam pelo menos uma credencial no formato de segredo, portanto aproximadamente um em cada três exige uma chave ou token antes de ser executado. Isso amplia o raio de impacto se o servidor ou seu operador for comprometido.

Um servidor MCP pode roubar seus dados?

Um servidor malicioso ou comprometido pode ler cada requisição que seu agente envia a ele e retornar resultados manipulados no contexto do agente, que é como funcionam o tool-poisoning e a injeção de prompt. Ele não pode ir além das ferramentas e credenciais que você concede a ele, portanto o privilégio mínimo e uma lista de permissões auditada são a defesa.

O registro do MCP é auditado?

Não. A listagem é apenas uma publicação, não uma auditoria de segurança. O registro armazena onde um servidor reside, não se seu operador é confiável. Servidores remotos apontaram para 7,420 hosts, dos quais 98.1% atendiam a um único servidor, portanto a maior parte da cadeia de suprimentos consiste em operadores que você precisaria avaliar individualmente.

Quais são os riscos de segurança dos servidores MCP?

Os principais são um servidor retornar saídas de ferramentas envenenadas para o seu agente, um operador remoto visualizar e registrar cada requisição, a exposição de credenciais quando um servidor exige chaves e o risco de concentração quando muitos servidores ficam atrás de um único gateway. Neste censo, truques exóticos como Unicode oculto estiveram ausentes dos metadados do registro, 0 de 19,321, portanto o risco de curto prazo é confiança e acesso, não codificação.

Leituras relacionadas

• O que atacantes podem realmente ver sobre sua empresa? A superfície que este artigo estende para dentro das suas ferramentas de agente.
• O p=none é suficiente? O mesmo método de medição passiva, aplicado à autenticação de e-mail.
• Autorização em primeiro lugar. Por que cada medição que publicamos se mantém do lado legal da linha.