A nova spec MCP desloca a segurança para os desenvolvedores. Checklist concreto para securizar seu servidor MCP sem bloquear seus agentes IA.
A nova especificação do Model Context Protocol, publicada no final de junho de 2026, desloca uma parte crítica da responsabilidade de segurança do protocolo para os desenvolvedores que o implementam. Concretamente: se seu servidor MCP expõe uma ferramenta sensível sem validação rigorosa de tokens OAuth, a falha vem do seu código, não do protocolo projetado pela Anthropic.
Trata-se de uma mudança de filosofia, não apenas de um patch simples. Até agora, MCP permanecia relativamente permissivo quanto à forma como os servidores gerenciavam a autenticação. A nova versão pronta para empresas, documentada pela SecurityWeek no final de junho, fecha essa margem de manobra e força as equipes a endurecerem suas próprias implementações. Já tínhamos falado disso em Comércio agentificado no Shopify: MCP torna-se a interface padrão entre agentes IA e sistemas de negócios. Mas conectar um agente ao seu CRM ou base de pedidos sem proteção é abrir uma porta que ninguém está monitorando.
O que mudou na spec MCP de junho de 2026
O protocolo MCP funciona como uma interface unificada: um agente IA, Claude, Cursor ou qualquer cliente compatível, se conecta para chamar ferramentas externas sem código específico por integração. X (antigo Twitter) lançou seu próprio servidor MCP no final de junho para permitir que agentes como Claude ou Grok Build acessem diretamente sua plataforma, segundo o TechCrunch. HiBob fez o mesmo alguns dias depois com uma integração MCP conectando Slack ao seu SIRH.
Essa adoção rápida tem um lado negativo. Quanto mais servidores MCP expostos publicamente, maior é a superfície de ataque. A nova spec responde a isso formalizando requisitos mais rigorosos na gestão de tokens e scopes OAuth. Mas não os impõe tecnicamente, ela documenta o que um servidor "pronto para empresas" deve fazer. Fica a cargo de cada desenvolvedor seguir ou ignorar.
É aí que fica o ponto contra-intuitivo: uma spec mais segura no papel pode deixar o ecossistema menos seguro no curto prazo, porque dá a ilusão de que o protocolo já está resolvendo o problema. Não está. Ele documenta o problema e joga a batata quente para você.
As falhas que já vemos nos deployments de MCP
Tool poisoning: quando um servidor mente sobre o que faz
Um servidor MCP declara suas ferramentas via um manifesto em linguagem natural, uma descrição que o agente lê para decidir quando chamá-la. Nada impede um servidor malicioso, ou comprometido, de declarar uma ferramenta "somente leitura" que na verdade escreve em seu banco de dados. O agente confia na descrição, não no código real. Este é o vetor mais documentado pela comunidade de segurança MCP desde o início de 2026.
OAuth mal configurado, o vetor número um
A maioria dos incidentes vêm de uma confusão clássica: scopes muito amplos, tokens que nunca expiram, ou pior, tokens compartilhados entre vários agentes no mesmo servidor. Um token MCP comprometido dá acesso a tudo que o scope autoriza, não apenas à requisição em questão.
Ausência de sandboxing entre o agente e o sistema de arquivos
Muitos servidores MCP ainda rodam localmente, com acesso quase total ao disco para simplificar o dev. Funciona muito bem até o dia em que o agente recebe um prompt malicioso injetado via um documento externo e executa um comando shell que nunca deveria ter tido permissão para lançar.
Como securizar um servidor MCP em produção
Aqui está o que recomendamos concretamente, por ordem de prioridade:
- Scopes OAuth granulares, um scope por ferramenta, nunca um scope global "admin".
- Expiração curta de tokens, 15 a 60 minutos, com refresh explícito em vez de tokens que vivem por semanas.
- Validação do manifesto de ferramentas a cada chamada, não apenas no momento do handshake inicial.
- Sandboxing sistemático, container isolado, sistema de arquivos somente leitura exceto diretório dedicado.
- Logs de auditoria por chamada de ferramenta, com alertas sobre padrões anormais (frequência, horários, scopes incomuns).
- Rate limiting no lado do servidor MCP, independente do rate limiting da API subjacente.
Esta lista não tem nada de revolucionário. É essencialmente uma higiene API clássica, aplicada a um protocolo mais jovem que a maioria dos padrões REST. A diferença é que ninguém tem ainda os reflexos automáticos, porque MCP tem pouco mais de um ano de existência pública.
Uma limitação honesta a mencionar: essas medidas desaceleram o desenvolvimento. Um scope por ferramenta significa mais configuração a cada nova ferramenta adicionada. Se sua equipe faz deploy rápido e itera em um MVP interno não exposto publicamente, esse nível de rigor pode ser desproporcional. Reserve-o para servidores realmente expostos a terceiros ou que manipulam dados sensíveis.
MCP vs API REST clássica: segurança em comparação
| Critério | API REST clássica | Servidor MCP |
|---|---|---|
| Autenticação | OAuth 2.0 / API keys, padrão maduro | OAuth integrado na spec, mas implementação variável |
| Descoberta de capacidades | Documentação estática (OpenAPI) | Manifesto dinâmico lido pelo agente em tempo de execução |
| Superfície de ataque | Endpoints conhecidos, fixos | Ferramentas declaradas dinamicamente, logo mais difíceis de auditar |
| Controle de acesso | Funções e permissões bem estabelecidas | Scopes ainda pouco granulares na prática |
| Maturidade do ecossistema | 15+ anos de padrões comprovados | Menos de dois anos, melhores práticas ainda em movimento |
A tabela fala por si: MCP não é menos securizável que uma API REST, mas o ecossistema de ferramentas, scanners e boas práticas ainda não recuperou seu atraso. Isso virá. Enquanto isso, cabe a você compensar.
O que os grandes players já fazem
Anthropic evoluiu seu modelo Claude para Sonnet 5 no final de junho de 2026, em substituição ao Sonnet 4.6 lançado em fevereiro, segundo 9to5Mac. Um modelo mais capaz coloca mecanicamente mais riscos do lado agentificado: quanto mais autônomo o agente é em suas decisões, mais consequências uma falha MCP a montante pode ter a jusante. X optou por expor um servidor MCP público para deixar agentes como Claude ou Cursor interagirem diretamente com sua plataforma, uma escolha que pressupõe uma governança de tokens particularmente rigorosa dada a escala. HiBob, por sua vez, optou por uma integração mais fechada, conectando seu SIRH ao Slack via MCP em vez de expor um servidor aberto para qualquer cliente.
Duas filosofias, dois níveis de risco. Se sua loja Shopify ou SaaS interno está pensando em expor um servidor MCP, a pergunta a fazer primeiro é: você realmente precisa de um acesso aberto, ou um acesso fechado aos seus próprios agentes é suficiente?
Conclusão
Três pontos para reter. Primeiro, a nova spec MCP não securiza automaticamente seus deployments, ela documenta requisitos que você deve implementar você mesmo. Segundo, as falhas mais frequentes continuam sendo clássicas: scopes muito amplos, tokens que não expiram, sandboxing ausente. Finalmente, o rigor tem um custo em velocidade, reserve-o para servidores realmente expostos.
Se você já está expondo um agente IA conectado a sua stack via MCP, ou se ainda está em dúvida entre uma solução no-code e uma implementação customizada, detalhamos os trade-offs em No-code vs código para construir um agente IA. Precisa de uma auditoria de segurança no seu servidor MCP antes de ir para produção? Entre em contato conosco em fstck.co.
Perguntas frequentes
Como saber se meu servidor MCP é vulnerável ao tool poisoning?
Verifique se o manifesto declarado por cada ferramenta corresponde exatamente ao seu comportamento real em produção, não apenas à documentação. Uma auditoria simples: registre cada chamada de ferramenta e compare a ação real (escrita, leitura, chamada externa) com a descrição anunciada no manifesto.
Devo esperar que MCP amadureça antes de implantá-lo em produção?
Não, mas você deve adaptar o nível de rigor à exposição real do servidor. Um servidor MCP interno, acessível apenas pelos seus próprios agentes em uma rede privada, tolera menos restrições que um servidor exposto publicamente a clientes terceirizados.
Qual é a diferença entre os scopes OAuth de uma API REST e os de um servidor MCP?
O princípio é idêntico, limitar o acesso ao estritamente necessário, mas a spec MCP encoraja um scope por ferramenta em vez de um scope por recurso. Na prática, muitas implementações atuais permanecem muito permissivas pela falta de ferramentas maduras para gerenciar essa granularidade facilmente.
Um token MCP comprometido dá acesso a todas as ferramentas do servidor?
Isso depende inteiramente da configuração dos scopes. Se o token tem um scope global, sim, o atacante recupera tudo que este scope autoriza. É por isso que a granularidade dos scopes não é um detalhe opcional, mas a primeira linha de defesa.
MCP é mais arriscado que uma integração API clássica?
Não intrinsecamente mais arriscado, mas menos maduro em termos de ferramentas de auditoria e boas práticas padronizadas. A descoberta dinâmica de capacidades, que é a força do MCP, também complica a análise estática de segurança que fazemos facilmente em uma API REST documentada em OpenAPI.
