O ponto fraco que toda integração MCP compartilha — e como resolvê-lo

O alerta que começou no Slack

Um engenheiro backend de uma fintech de médio porte enviou uma mensagem ao autor do artigo que começava com “então, isso é ruim”. Sua equipe havia acabado de lançar um agente de IA que usava o Model Context Protocol (MCP) para conectar-se às ferramentas internas: CRM, sistema de cobrança e workspace do Slack. Funcionou perfeitamente na demonstração.

Durante uma revisão de segurança de rotina, alguém notou que o agente ainda tinha acesso total de leitura e escrita a uma ferramenta que não usava havia três semanas — acesso que nunca foi explicitamente revogado, porque ninguém havia construído uma forma de revogá-lo.

Nada foi violado. Nenhum dado foi roubado. Mas a falha era real, e não era um bug no código: a camada de autorização é uma reflexão tardia, não uma fundação.

O que é MCP e por que isso importa

O Model Context Protocol (MCP) é um padrão que permite que modelos de IA conversem com ferramentas e fontes de dados externas — bancos de dados, APIs, sistemas de arquivos, plataformas SaaS — através de uma interface comum. Em vez de cada aplicativo de IA escrever código de integração personalizado para cada ferramenta, o MCP oferece uma linguagem compartilhada.

Pense no MCP como o USB-C dos agentes de IA. Antes do USB-C, cada dispositivo tinha seu próprio carregador e cabo. O MCP tenta fazer o mesmo para “como um agente de IA se conecta a uma ferramenta”. É genuinamente útil — e é por isso que a adoção do MCP avançou tão rápido.

Mas aqui está o problema: USB-C não pede permissão antes de começar a mover dados. E muitos servidores MCP também não — ou pedem, mas de uma forma muito mais fraca do que a maioria das equipes imagina.

Os três problemas que aparecem juntos

O problema não está na ideia central do MCP. Está na camada de autorização — na conexão entre o agente de IA e as ferramentas que ele pode tocar. Três coisas tendem a dar errado simultaneamente:

1. Permissões granulares demais (na verdade, de menos)

Quando um usuário conecta um servidor MCP ao seu agente, geralmente vê uma única tela de consentimento: “Permitir que este agente acesse [Ferramenta]”. Só isso. Não “ler seu calendário”, “enviar e-mails em seu nome” e “excluir arquivos” como permissões separadas — apenas um sim generalizado.

Este é o mesmo erro que os primeiros aplicativos móveis cometeram antes de Android e iOS forçarem permissões granulares. Ninguém quer reaprender essa lição da maneira difícil, mas é exatamente essa a trajetória que o MCP está seguindo.

2. Escopo que nunca expira

Uma vez que um agente obtém um token para acessar uma ferramenta, esse token frequentemente persiste muito além da tarefa que o justificou. O acesso ao sistema de cobrança que o engenheiro da fintech descobriu é o exemplo clássico: o agente precisava dele para um projeto de duas semanas, e o token continuou funcionando silenciosamente por meses porque nada na arquitetura alertava ninguém para verificar.

3. Delegação sem revalidação

Em teoria, um agente só deveria agir dentro do escopo que um humano concedeu explicitamente. Na prática, muitas implementações MCP passam tokens para ferramentas secundárias ou agentes encadeados sem reverificar o escopo a cada salto. Um token destinado a “ler registros de clientes” pode acabar sendo usado por um processo downstream para algo muito mais amplo, simplesmente porque ninguém o revalidou ao longo do caminho.

O perigo real: escala

Junte esses três fatores e você obtém um padrão que equipes de segurança já estão sinalizando nas primeiras auditorias: agentes que têm mais acesso do que ninguém pretendia, por mais tempo do que ninguém pretendia, com menos supervisão do que ninguém assumiu.

É tentador classificar isso como “caso de borda” — até você observar a velocidade com que a adoção de agentes está escalando. Empresas estão passando de um punhado de agentes piloto para dezenas de agentes específicos conectados a sistemas reais: CRMs, plataformas de RH, ferramentas financeiras, wikis internas. Cada uma dessas conexões é um novo handshake estilo OAuth, e a maioria das equipes está copiando e colando o mesmo padrão leve de autorização em todas elas porque foi o que o MCP tornou fácil.

O perigo real não é que uma única integração seja catastroficamente insegura. É que o mesmo atalho está sendo replicado em escala, em milhares de empresas, mais rápido do que os processos de revisão de segurança conseguem acompanhar.

Como resolver: quatro abordagens

Abordagem 1: Confiar na plataforma

Algumas equipes simplesmente usam o fluxo de autorização padrão que o servidor MCP ou a biblioteca cliente oferece. Rápido de implementar, mas herda todas as fraquezas descritas acima. Aceitável para protótipo. Arriscado em produção.

Abordagem 2: Revisão manual de escopo

Equipes conscientes de segurança auditam manualmente as permissões de cada conexão MCP em uma programação. Funciona, mas não escala — com dezenas de agentes e integrações, a revisão manual vira o gargalo.

Abordagem 3: Tokens de curta duração com refresh explícito

Este é o padrão mais forte. Em vez de um token de longa duração, o agente recebe um token com escopo limitado a uma tarefa específica e expiração curta, e precisa solicitar explicitamente a renovação para qualquer coisa além desse escopo.

// Padrão fraco: token amplo e duradouro
const token = await mcpClient.authorize({
  scope: "full-access",
  expiresIn: "90d"
});

// Padrão forte: token com escopo de tarefa e curta duração
const token = await mcpClient.authorize({
  scope: ["read:customer_records"],
  purpose: "campaign-analysis-q3",
  expiresIn: "24h",
  revokeOnTaskComplete: true
});

A diferença parece pequena no código, mas muda completamente o perfil de risco. Um token que expira em 24 horas e tem escopo limitado a um propósito não pode se tornar o acesso esquecido de seis meses que o engenheiro da fintech encontrou.

Abordagem 4: Validação de escopo por salto

Para sistemas multiagente ou encadeados, as equipes mais maduras estão começando a revalidar o escopo em cada ponto de delegação — não apenas na conexão inicial. É mais trabalho de engenharia, mas é a única abordagem que realmente fecha a brecha da “delegação que não é tão limitada assim”.

Checklist para quem está construindo com MCP

Se você está enviando ou mantendo integrações MCP, não espere por uma auditoria programada. Puxe suas conexões MCP atuais esta semana e faça três perguntas para cada uma:

1. Qual escopo este token realmente tem?
2. Por quanto tempo ele vive?
3. Quem perceberia se ele fosse usado de forma inadequada?

Se você não consegue responder às três rapidamente, esse é seu ponto de partida.

A economia dos agentes está se movendo rápido, e o encanamento é genuinamente útil. Mas encanamento que vaza não fica quieto para sempre — só espera o momento em que você não está olhando. Melhor encontrar o ponto fraco você mesmo do que deixar que encontrem por você.