Passei dez anos fazendo Cloud Security Posture Management. O trabalho, resumido de forma honesta, consiste em encontrar coisas que ninguém decidiu conscientemente expor. Um bucket público porque o default era público. Uma porta aberta porque o módulo de Terraform que a equipe copiou já vinha assim. Uma role com permissão ampla porque restringir daria trabalho e a entrega era na sexta.
Nada disso é desleixo. É o comportamento previsível de um ecossistema que cresceu mais rápido que a própria disciplina de configuração. E é exatamente o que estou vendo acontecer de novo com MCP — o Model Context Protocol, a camada que conecta modelos de linguagem a ferramentas, arquivos e bancos de dados.
O padrão é velho, o componente é novo
Um servidor MCP é, na prática, um endpoint que executa ações em nome de um modelo. Ele lê arquivos, consulta bancos, chama APIs. Em muitas implantações que analisei, ele sobe num container, escuta numa porta e fica ali — sem autenticação, sem segmentação de rede, sem log de quem chamou o quê.
A pergunta que eu faria num assessment de nuvem é a mesma aqui: quem pode alcançar esse endpoint? Se a resposta for “qualquer coisa dentro da VPC”, você acabou de dar a um invasor com um foothold qualquer uma ferramenta de execução remota com credenciais embutidas.
O agravante é que servidores MCP frequentemente rodam em instâncias que têm acesso ao endpoint de metadados do provedor de nuvem. Um servidor que aceita URL arbitrária de um usuário e faz a requisição do lado do servidor é um SSRF clássico. Apontado para o metadata service, ele devolve credencial de IAM. Isso não é uma vulnerabilidade nova de IA — é OWASP de 2017 num componente de 2025.
Por que está acontecendo mais rápido
Quando a nuvem pública virou default corporativo, levamos anos para construir o ferramental de postura: os scanners, os benchmarks CIS, os controles de admissão, os módulos de infraestrutura com defaults seguros. O mercado de CSPM existe porque o problema era grande demais para revisão manual.
Com MCP não temos nada disso ainda. Não há baseline compartilhado, não há benchmark de referência, não há scanner que diga “este servidor expõe 14 ferramentas, 3 delas escrevem em disco e nenhuma exige autenticação”. A adoção, por outro lado, está indo mais rápido do que a da nuvem foi.
A velocidade de adoção sem baseline correspondente é a definição operacional de dívida de segurança.
O que dá para fazer hoje
- Inventário primeiro. Você não consegue proteger servidores MCP que não sabe que existem. Comece mapeando quais estão rodando, em que hosts e com quais ferramentas expostas.
- Trate o endpoint como carga de trabalho, não como plugin. Autenticação mútua, escuta em loopback ou rede interna dedicada, nunca exposição direta à internet.
- Bloqueie o metadata service. Em GCP e AWS, negue o acesso ao endpoint de metadados a partir de qualquer processo que aceite entrada não confiável. Isso corta a classe inteira de SSRF-para-credencial.
- Logue a chamada de ferramenta, não só o prompt. O evento de auditoria relevante é “ferramenta X foi invocada com argumento Y”, e ele precisa ir para o mesmo SIEM que recebe o resto.
- Escreva a política antes da próxima integração. Um documento de uma página dizendo quais ferramentas podem ser expostas e sob quais condições vale mais que um scanner que você ainda não tem.
A parte inconveniente
Nenhuma dessas recomendações é sofisticada. São os mesmos controles que aplicamos a qualquer serviço interno há quinze anos. É justamente esse o ponto: o risco em MCP hoje não vem de ataques exóticos contra modelos, vem de higiene básica de infraestrutura que ninguém aplicou porque o componente parecia ser “coisa de IA” e não “coisa de produção”.
Ele é coisa de produção. Trate como tal.
