MCP não resolve segurança: protocolo não é arquitetura de agentes

MCP ganhou uma comparação conveniente: o USB-C dos agentes. A analogia ajuda a explicar o valor do protocolo, porque ele reduz o atrito para conectar LLMs a ferramentas, dados e sistemas internos. Mas ela também cria uma confusão perigosa. MCP Model Context Protocol segurança arquitetura não é uma coisa só. Protocolo resolve integração. Segurança em produção continua sendo desenho de sistema.

O que o MCP padroniza

O MCP define como clientes, servidores e ferramentas conversam. Ele descreve tools, resources e prompts, além do formato de descoberta e chamada. Isso tem valor prático: menos bridges customizadas, menos cola improvisada, menos integração feita uma vez para cada ferramenta.

Só que padronizar chamada não decide política. A própria especificação trata autorização como algo que depende da implementação e do transporte usado. Em HTTP existe um caminho baseado em OAuth. Em STDIO, comum em servidores locais, o modelo operacional é outro. Em ambos os casos, continuam fora do protocolo as perguntas mais difíceis: quem pode chamar qual ferramenta, com qual escopo, em nome de qual usuário, sobre qual dado e com qual consequência.

Esse ponto não diminui o MCP. Ele só coloca o protocolo na camada correta.

Onde a segurança ainda quebra

O primeiro vetor é tool poisoning. Quando um agente se conecta a um servidor MCP, ele recebe nomes, descrições e schemas das ferramentas. Esse texto entra no contexto do modelo. Se uma descrição for maliciosa ou manipulada, ela pode tentar induzir o agente a ignorar regras, chamar outra ferramenta ou exfiltrar dados. A OWASP descreve esse problema como prompt injection indireto no contexto do MCP.

Existem variações relevantes. No rug pull, a ferramenta parece segura quando é aprovada, mas a descrição muda depois. No tool shadowing, ferramentas com nomes parecidos confundem seleção e intenção. No confused deputy, um componente age com privilégio maior do que o usuário realmente deveria ter.

O segundo vetor é supply chain. Servidor MCP é dependência de software. Pode vir de npm, PyPI, Docker, repositório público ou URL remota. O registry oficial hospeda metadata e aponta para pacotes, mas não substitui revisão de segurança. Se a organização não instala uma biblioteca aleatória sem revisão, também não deveria conectar um servidor MCP aleatório a dados internos.

O terceiro ponto é execução local. Disclosures recentes sobre servidores STDIO reforçam uma realidade simples: configuração local, processo filho, permissões de sistema e origem do pacote precisam entrar no threat model. Não basta olhar para o JSON da ferramenta.

Arquitetura mínima para agentes com MCP

O primeiro princípio é tratar resultado de ferramenta como input não confiável. O modelo pode ler, resumir e reagir ao que a ferramenta devolve, mas o sistema host precisa validar o que será executado depois.

O segundo é separar privilégio por servidor e por ferramenta. Uma ferramenta read-only não deveria compartilhar credencial com outra que escreve em banco transacional. Consulta e escrita são escopos diferentes. Ação irreversível precisa de confirmação humana com contexto suficiente para decisão, não um popup sem informação.

Também é preciso ter allowlist, pinning de versão e processo de remoção para servidores MCP. Essa é a parte menos glamourosa da arquitetura, mas é onde muita exposição nasce.

Por fim, logs precisam permitir investigação. Prompt, tool call, parâmetros, resultado e ação executada devem ser correlacionáveis. Sem esse rastro, o postmortem vira tentativa de reconstrução.

O protocolo não define o blast radius

Uma equipe pequena usando tools internas somente leitura tem um risco. Uma plataforma com dados regulados, escrita em sistemas transacionais e execução local de servidores tem outro. O MCP pode ser o mesmo nos dois casos. O blast radius não é.

É por isso que a pergunta certa não é “MCP é seguro?”. A pergunta é: qual arquitetura você colocou ao redor dele?

Referências

Assista ao vídeo completo no YouTube →

Leia também