A string de conexão colada na variável de ambiente
Um desenvolvedor sobe um servidor MCP num sábado à tarde, cola a connection string do banco de produção numa variável de ambiente e em quinze minutos o agente já responde perguntas sobre pedidos, clientes e estoque direto do Postgres. Funciona bem, a demonstração impressiona o time e ninguém testou o que acontece se o agente decidir montar um DELETE em vez de um SELECT.
Essa mesma cena se repete em boa parte dos projetos que conectam IA a dado real, e é por isso que o anúncio que a Google fez em 1 de junho de 2026 vale a leitura com calma. Nesse dia a empresa colocou em disponibilidade geral o AlloyDB Remote MCP Server, um servidor MCP gerenciado para o banco AlloyDB. O texto do anúncio detalha o que a Google considerou necessário para liberar um agente de IA a tocar num banco de produção: autenticação por IAM no lugar de senha ou chave de API compartilhada, uma ferramenta SQL que roda em modo somente leitura por padrão, filtro de prompt injection via Model Armor, e registro de toda consulta, ação e chamada de ferramenta no Cloud Audit Logs.
Reparar no que a Google decidiu blindar diz mais sobre o problema do que qualquer relatório de mercado. Ninguém constrói quatro camadas de proteção em cima de um recurso que já era seguro por padrão. Cada item da lista é resposta direta a um jeito específico de dar errado, e esse jeito de dar errado é exatamente o que a gente vê em servidor MCP montado às pressas: uma credencial única, sem escopo, sem separação entre leitura e escrita, sem log de nada.
O padrão que já está em produção em algum lugar
A maioria dos servidores MCP que aparece em projeto de cliente segue outro caminho. Alguém clona um servidor da comunidade, cola a connection string num arquivo .env, e o processo roda com a mesma permissão que o desenvolvedor tem no banco. Não existe escopo por ferramenta, não existe log de qual query o agente decidiu rodar, e não existe separação entre a ferramenta que lê pedido e a que consegue apagar linha.
A diferença fica clara lado a lado:
# servidor MCP "rápido", comum em prototipo
DATABASE_URL=postgres://admin:senha@prod-db:5432/app
# a ferramenta MCP herda a permissão inteira dessa conta
# padrão que a Google descreve no anúncio de junho
role: mcp-agente-leitura
grants: SELECT em pedidos, clientes
escrita: bloqueada por padrao
auditoria: cada chamada vai pro Cloud Audit Logs
A primeira versão sobe em quinze minutos. A segunda exige que alguém pare e decida o que o agente pode e não pode fazer, o que é exatamente o trabalho que costuma ficar pra depois.
Quatro perguntas antes de conectar qualquer servidor MCP a dado real
| Pergunta | Servidor MCP típico de protótipo | Padrão que o mercado está adotando |
|---|---|---|
| Quem detém a credencial | Uma string de conexão com permissão total, num .env | Conta de serviço com escopo próprio para a ferramenta |
| O que a ferramenta escreve | Mesmo endpoint aceita SELECT, INSERT, UPDATE e DELETE | Ferramenta de leitura separada da de escrita, escrita off por padrão |
| Onde fica o log | Stdout do processo, se sobrar alguém olhando | Sistema de auditoria centralizado, consultável depois do fato |
| O que filtra o prompt malicioso | Nada entre o texto que chega e a query que sai | Camada de filtro antes da execução da ferramenta |
Nenhuma dessas quatro perguntas exige trocar de banco ou de fornecedor. Dá pra aplicar o mesmo raciocínio num servidor MCP caseiro, apertando escopo de usuário, criando uma role só de leitura no Postgres e mandando log de cada chamada de ferramenta pra algum lugar que alguém realmente olha.
O que muda de segunda de manhã
Antes de plugar o próximo servidor MCP num banco com dado real, faça o inventário do que já está rodando. Pergunte, projeto por projeto: essa credencial tem escopo próprio ou é reaproveitada de outra coisa? A ferramenta que o agente usa consegue escrever, mesmo que ninguém tenha pedido pra ela escrever? Existe algum lugar onde dá pra ver, depois do fato, qual query o agente rodou às três da manhã?
Se a resposta for não em qualquer uma dessas, o conserto costuma caber numa tarde: criar uma role de leitura dedicada, separar a ferramenta de escrita num servidor à parte com aprovação manual, e mandar o log da ferramenta MCP pro mesmo lugar onde já vai o log da aplicação. Não precisa esperar o fornecedor lançar a versão gerenciada. É esse tipo de decisão de arquitetura que a Overflow revisa quando monta agentes de IA em produção para cliente: https://overflow.codes/ai.
