Give Them an Inch and They Will Take a Mile:Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems

Este artigo revela que a falta de autenticação da identidade do chamador em sistemas baseados no Protocolo de Contexto de Modelo (MCP) cria vulnerabilidades críticas de segurança, permitindo que servidores confiem implicitamente em múltiplos chamadores após uma única autorização e expondo operações sensíveis a acessos não autorizados.

O essencial

Imagine que você construiu um robô assistente superinteligente (uma IA) que pode fazer coisas pelo seu computador, como ler seus arquivos, enviar e-mails ou até controlar a tela do seu monitor. Para que esse robô funcione, ele precisa de uma "ponte" ou um "tradutor" que conecte a mente da IA às ferramentas do seu computador. Essa ponte é chamada de MCP (Protocolo de Contexto do Modelo).

O problema que este artigo descobre é que essa ponte foi construída de uma maneira perigosa: ela não verifica quem está pedindo para fazer o que.

Aqui está a explicação simples, usando analogias do dia a dia:

1. O Problema: "Dê um polegada, eles tomam uma milha"

A frase do título significa: se você der uma pequena permissão a alguém, eles podem acabar usando isso para fazer coisas muito maiores do que você imaginou.

A Analogia do Chaveiro do Hotel:
Imagine que você é o gerente de um hotel (o Servidor MCP). Você tem um chaveiro mestre que abre todas as portas do hotel.

• O Cenário Ideal: Quando um hóspede (o Agente de IA) chega, você verifica o ID dele, dá a chave do quarto dele e diz: "Só use esta chave no quarto 101".
• O Cenário Real (descoberto no artigo): Você dá a chave mestre ao primeiro hóspede para ele abrir a porta da cozinha. O hóspede diz "Obrigado" e sai.
  • Acontece que o sistema do hotel não verifica quem está usando a chave depois disso.
  • Se um ladrão (um Agente Malicioso) aparecer na cozinha 10 minutos depois e disser "Abra a porta", o sistema, que já está "confiante" porque a chave foi usada antes, abre a porta do cofre, da sala do tesouro e do quarto do hóspede, sem perguntar quem é o ladrão.

O servidor MCP acredita que, uma vez que a "autorização" foi dada, ela vale para qualquer pessoa que venha usar o sistema depois, não importa quem seja.

2. O Que é "Confusão de Identidade do Chamador"?

Esse é o nome técnico do problema. Significa que o sistema esquece quem pediu a ação.

• Como deveria ser: "O Sr. João pediu para abrir o arquivo X. Vamos verificar se o Sr. João tem permissão."
• Como está sendo: "Alguém pediu para abrir o arquivo X. Como o sistema já foi autorizado antes, vamos abrir!"

Isso é perigoso porque a IA (o robô) pode ser enganada ou controlada por um hacker. O hacker não precisa roubar senhas; ele apenas precisa "falar a língua" do robô e pedir para fazer algo. Como o robô não pergunta "Quem é você?", ele faz o que é pedido usando as permissões que o dono legítimo deu anteriormente.

3. O Que os Pesquisadores Fizeram?

Eles criaram uma ferramenta chamada MCPAuthChecker (o "Detetive de Segurança").

• O que o Detetive faz: Ele entra em milhares de servidores MCP (mais de 6.000!) e simula situações onde um estranho tenta usar as ferramentas.
• O que ele descobriu:
  • 46% dos servidores são inseguros. Isso significa que quase metade deles deixam qualquer um usar as ferramentas se alguém já tiver autorizado uma vez.
  • Isso acontece em ferramentas de desenvolvedores, bancos de dados, e até em sistemas de nuvem.
  • Não importa se o projeto é famoso (tem muitas "estrelas" no GitHub) ou novo; o problema está em todos os lugares.

4. Exemplos Reais do Perigo (O que um hacker pode fazer?)

O artigo mostra três cenários assustadores que podem acontecer sem roubar senhas:

1. Comando Remoto (RCE): Um hacker pode pedir para o servidor executar um comando no computador do usuário (como apagar arquivos ou instalar vírus), usando a permissão que o usuário legítimo deu para a IA.
2. Controle de Tela e Mouse: Imagine um hacker controlando o mouse e o teclado do seu computador à distância, apenas pedindo para a IA "clicar aqui" ou "tirar uma foto da tela". O servidor MCP faz isso porque já foi autorizado a controlar o computador.
3. Abuso de APIs: Se você autorizou a IA a acessar sua conta do Slack ou da AWS (nuvem), um hacker pode usar essa mesma autorização para ler seus e-mails corporativos ou gastar seu dinheiro na nuvem, sem que o sistema perceba que não é você quem está pedindo.

5. A Solução Proposta

Os autores dizem que precisamos mudar a mentalidade de segurança:

• Não basta confiar no "sistema": O servidor não pode confiar cegamente no fato de que "algo foi autorizado antes".
• Verificação por Ação: A cada vez que uma ferramenta é usada, o sistema deve perguntar: "Quem está pedindo isso agora? Essa pessoa específica tem permissão para fazer esta ação específica?"

Resumo Final

Este artigo é um alerta de que, ao conectar IAs poderosas ao nosso mundo real, estamos criando "portas traseiras" invisíveis. A segurança atual é como deixar a porta da frente aberta porque "o porteiro já deixou entrar o dono". O artigo mostra que, se um estranho passar pela porta aberta, ele pode entrar e fazer o que quiser. A solução é colocar um porteiro que verifica o ID de cada pessoa que chega, não apenas do primeiro visitante.

Resumo técnico

Título: Entendendo e Medindo a Confusão de Identidade do Chamador em Sistemas de IA Baseados em MCP

1. O Problema: Confusão de Identidade do Chamador (Caller Identity Confusion)

O Model Context Protocol (MCP) é uma interface padronizada que permite que Agentes de Grandes Modelos de Linguagem (LLMs) interajam com ferramentas e serviços externos. No entanto, o artigo identifica uma vulnerabilidade fundamental e amplamente negligenciada: a Confusão de Identidade do Chamador.

• Contexto: Em arquiteturas tradicionais, o cliente (usuário) gerencia a identidade e a sessão. No MCP, o agente (LLM) atua como um intermediário. Para suportar a execução contínua de ferramentas, os servidores MCP frequentemente mantêm estados de autorização persistentes (ex: tokens OAuth, credenciais de sessão) após uma autorização inicial bem-sucedida.
• A Falha: Muitos servidores MCP tratam a autorização como um estado global do servidor, não vinculado à identidade específica do chamador (agente) que iniciou a requisição.
• O Risco: Uma vez que um agente legítimo autoriza o servidor, qualquer outro agente (malicioso ou não) capaz de invocar o servidor MCP pode herdar silenciosamente esse estado de autorização. O servidor não distingue quem está fazendo a chamada subsequente.
• Consequência: Isso permite que atacantes executem comandos remotos, acessem dados sensíveis ou controlem interfaces gráficas (GUI) sem roubar credenciais ou burlar mecanismos de autenticação diretamente, apenas explorando a reutilização do estado de autorização existente.

2. Metodologia: MCPAuthChecker

Os autores desenvolveram uma ferramenta de análise chamada MCPAuthChecker para detectar essa vulnerabilidade em escala. O desafio principal era que os servidores MCP não possuem pontos de entrada padronizados e a lógica de autorização é descentralizada e dependente da implementação.

A ferramenta opera em três fases principais:

1. Resolução de Pontos de Entrada de Ferramentas (Execution-Triggered Tool Entry Resolution):

   • Utiliza análise estática (baseada em CodeQL) para reconstruir o fluxo de dependências do programa.
   • Identifica onde as requisições de nível de protocolo (tools/call) se traduzem em execução concreta, mapeando padrões de registro dinâmico de ferramentas (decoradores, APIs de adição, enumeração em tempo de execução).

2. Análise de Autorização Sensível ao Caminho (Path-Sensitive Authorization Analysis):

   • Rastreia o fluxo de controle desde a entrada da ferramenta até operações sensíveis (sistema de arquivos, rede, execução de comandos).
   • Verifica se a autorização é: (i) inexistente, (ii) cacheada no nível do servidor (reutilizada), ou (iii) estritamente vinculada à identidade do chamador atual.
   • Diferencia entre autorização global (servidor) e autorização por invocação.

3. Validação Dinâmica Seletiva (Selective Dynamic Validation):

   • Como a análise estática não consegue prever o estado de cache em tempo de execução, a ferramenta executa validações dinâmicas controladas.
   • Usa um proxy unificado (mcp-remote) para invocar ferramentas e monitorar se a execução ocorre com sucesso sem novos prompts de autorização, confirmando a reutilização indevida do estado.

3. Contribuições Principais

• Identificação Formal de uma Nova Vulnerabilidade: O artigo define e formaliza a "Confusão de Identidade do Chamador" como uma falha de design específica em sistemas de agentes baseados em middleware, distinta de falhas tradicionais de injeção ou quebra de criptografia.
• Ferramenta de Análise Prática: Desenvolvimento do MCPAuthChecker, capaz de lidar com a natureza dinâmica e heterogênea dos servidores MCP para detectar reutilização de autorização.
• Estudo Empírico em Grande Escala: A primeira medição abrangente da segurança do ecossistema MCP, analisando milhares de servidores reais.
• Demonstração de Exploração Real: Validação prática de que essa vulnerabilidade permite ataques reais (RCE, controle de GUI, abuso de APIs) sem necessidade de roubo de credenciais.

4. Resultados do Estudo Empírico

Os autores analisaram 6.137 servidores MCP reais (Python e JavaScript) coletados de repositórios públicos e diretórios de ferramentas.

• Taxa de Vulnerabilidade: 46,4% dos servidores analisados (2.846 servidores) exibem comportamento de autorização inseguro.
• Tipos de Falhas:
  • AuthNone: Nenhuma verificação de autorização (23,6% a 29,5% dependendo da categoria).
  • AuthCache: Autorização realizada uma vez e cacheada para reutilização sem revalidação (3,9% a 7,8%).
  • AuthRuntime: Autorização em tempo de execução, mas baseada em estado compartilhado ou verificações parciais que falham ao isolar chamadores (24,1% a 37,2%).
• Impacto por Categoria:
  • Ferramentas para Desenvolvedores (Developer Tools) são as mais afetadas (52% inseguras), o que é crítico pois dominam o ecossistema e expõem interfaces densas.
  • A vulnerabilidade persiste mesmo em projetos com alto número de estrelas (>1000), indicando que a popularidade não garante segurança.
• Capacidades de Ataque Habilitadas: Servidores vulneráveis permitem:
  • Execução de comandos no sistema operacional.
  • Acesso e modificação de dados persistentes (arquivos, logs, configurações).
  • Comunicação de rede autenticada em nome do usuário legítimo.
  • Interação com dispositivos físicos e interfaces humanas (mouse, teclado, câmera).

5. Casos de Uso e Impacto de Segurança (Ataques Reais)

O artigo descreve três cenários de ataque concretos explorados durante a pesquisa:

1. RCE Originado pelo Agente: Um servidor MCP que executa comandos git sem sanitização ou verificação de chamador. Um atacante pode injetar comandos arbitrários através de extensões do Git, assumindo os privilégios do processo do servidor.
2. Controle de GUI e Navegador Não Autenticado: Servidores que controlam navegadores (ex: Puppeteer) permitem que um agente remoto navegue, tire capturas de tela ou preencha formulários, contornando verificações de segurança baseadas em UI (como CAPTCHAs) ou workflows de confirmação.
3. Abuso de API de Terceiros Persistente: Servidores que autenticam uma vez com tokens de alto privilégio (ex: Slack, AWS) e reutilizam esse estado. Um atacante pode enviar mensagens ou consultar dados financeiros sob a identidade legítima do usuário, sem que o serviço externo perceba a anomalia.

6. Significado e Conclusão

O estudo conclui que a segurança dos sistemas de IA baseados em MCP está comprometida por um modelo de confiança excessivo no servidor, onde a autorização é tratada como um estado global em vez de ser estritamente vinculada à identidade do chamador em cada invocação.

• Implicação de Design: A comunidade de IA precisa adotar a autorização vinculada ao chamador (caller-bound authorization) como um princípio de design de primeira classe, garantindo que cada chamada de ferramenta seja reavaliada quanto à identidade do agente que a originou.
• Ação Responsável: Os autores reportaram vulnerabilidades a 87 projetos populares no GitHub. Vários mantenedores confirmaram o problema, atribuíram CVEs e corrigiram as falhas, validando a criticidade da descoberta.

Em resumo, o artigo alerta que "dar uma polegada" (autorização inicial) ao servidor MCP pode levar a "uma milha" (execução arbitrária e não autorizada) se a identidade do chamador não for verificada continuamente.