Falhas estruturais nos SDKs oficiais do Model Context Protocol (MCP) permitem exposição de ferramentas privilegiadas
Um levantamento sistemático dos seis SDKs oficiais do Model Context Protocol (Python, TypeScript, Go, Rust, C#, Swift) encontrou três lacunas de autorização que impedem um modelo zero-trust corporativo, entre elas a ausência de controle de visibilidade de ferramentas por permissão. Em testes com quatro LLMs de fronteira, um servidor que só valida a permissão dentro do corpo da chamada expôs ferramentas proibidas em 21,1% das tentativas, enquanto a extensão proposta pelos autores zerou essa taxa.
O MCP se tornou a interface padrão para conectar agentes LLM a ferramentas e sistemas corporativos, mas os pesquisadores mostram que os SDKs oficiais — nas seis linguagens mais usadas — ainda não sustentam requisitos básicos de zero-trust empresarial. O gap mais citado é o cenário "dual persona": um mesmo servidor MCP precisa atender tanto usuários humanos, autenticados via SSO corporativo, quanto agentes automatizados, autenticados via credencial de serviço em um header diferente — algo que os SDKs base não suportam sem middleware customizado.
Os outros dois problemas estruturais identificados são a ausência de descoberta de ferramentas pré-autenticação (não dá para um cliente saber o que um servidor oferece antes de já ter credencial) e, mais grave, a falta de autorização granular por ferramenta na camada base do SDK — ou seja, qualquer cliente autenticado, por padrão, enxerga e pode tentar invocar todas as ferramentas do servidor, não só as que lhe cabem. Isso é particularmente sensível porque agentes LLM traduzem instruções em linguagem natural, potencialmente manipuladas por prompt injection, em chamadas de ferramenta reais — a autorização precisa continuar valendo mesmo quando o agente já foi enganado.
O experimento reforça esse ponto: quando a única defesa é checar permissão dentro do corpo da requisição (sem esconder a ferramenta da listagem), servidores expuseram ferramentas proibidas em 152 de 720 tentativas (21,1%) através de quatro modelos de fronteira. Mas os autores também mostram que simplesmente ocultar a ferramenta da listagem não resolve sozinho: em até 94% dos casos em que a existência da ferramenta era inferível pelo contexto da conversa, o modelo a referenciou pelo nome mesmo sem tê-la visto listada — provando que o controle de descoberta não substitui o enforcement no momento da invocação.
A correção prática proposta são extensões componíveis ao framework FastMCP — normalização de credencial entre headers, cache de verificação de token entre múltiplos provedores de identidade, um endpoint de metadados sem autenticação para descoberta segura, e uma anotação declarativa que mantém visibilidade e permissão de invocação sempre sincronizadas — sem exigir mudança no protocolo MCP nem nos SDKs internos. Com essas extensões, a exposição de ferramentas proibidas caiu de 21,1% para 0% nos testes, um caminho que qualquer time que já rode MCP em produção pode adotar hoje sem esperar por uma revisão do protocolo.