Seu Banco de Dados Está Prestes a Se Tornar uma Ferramenta de IA. Ele Está Pronto?

Uma Cartilha de Segurança para Integração de Banco de Dados MCP

Parte 1: Construindo a Fundação de Segurança

[Uma versão deste artigo apareceu em The New Stack]

Por 25 anos, observei o banco de dados se sentar atrás de camadas de proteção: firewalls, VPNs, poolers de conexão, acesso baseado em função e até mesmo conselhos de revisão de mudanças. Construímos décadas de ferramentas para garantir que a query errada nunca chegasse à produção. E agora? Estamos prestes a entregar a um agente de IA uma string de conexão, e esse agente alucina nomes de colunas. Isso não é uma crítica à IA. É um choque de realidade.

O Model Context Protocol (MCP) oferece aos LLMs uma maneira estruturada de descobrir e invocar ferramentas externas. O acesso a bancos de dados é o próximo passo natural, mas também é o mais perigoso. Aqui está a tensão: a adoção do MCP está acelerando. Milhares de servidores apareceram no GitHub e em registros públicos em 2025, e grandes fornecedores começaram a experimentar integrações. Mas as implementações são iniciais, a postura de segurança é inconsistente, e a maioria das equipes que conectam bancos de dados a agentes de IA não lidou com o modelo de ameaças.

Este artigo é uma cartilha de servidor MCP de banco de dados para DBAs e arquitetos de plataforma. Vou mostrar por que eles são uma fera diferente, o que a especificação realmente protege e como são os controles não negociáveis na prática. Os exemplos são extraídos do gp-mcp-server, um protótipo open-source em Spring Boot que construí para explorar padrões de segurança para Greenplum e PostgreSQL. Ele cobre muito do terreno comum e nos dá um código concreto para discutir. Sem fumaça e espelhos, apenas código real, controles de segurança reais e decisões de arquitetura reais.

Por Que o Acesso a Banco de Dados É o Problema MCP Mais Difícil

A maioria das ferramentas MCP tem um limite natural para o que pode dar errado. Um leitor de arquivos lê arquivos, e uma ferramenta de calendário gerencia eventos. O raio de explosão é previsível. Bancos de dados não têm um. SQL é expressivo, combinável e, nas mãos erradas, destrutivo. Uma única query válida pode despejar tabelas sensíveis, bloquear recursos de produção ou exfiltrar dados em escala. Agora, combine isso com um LLM que alucina com confiança, cai em prompt injection e otimiza para utilidade em vez de segurança. O acesso tradicional a bancos de dados pressupõe que o chamador entende o que está fazendo. Quando um agente de IA é esse chamador, essa suposição se quebra. O servidor MCP não é apenas um adaptador. É a fundação sobre a qual todo o resto é construído. Se a fundação estiver errada, toda a casa desmorona.

O Que a Especificação Cobre (E o Que Não Cobre)

Você precisa entender o que a especificação trata e o que ela deixa para você. Essa lacuna é onde seu esforço de engenharia reside.

A Evolução da Segurança da Especificação

A especificação MCP evoluiu rapidamente, elevando o nível de segurança a cada revisão:

• 2024-11-05: Desenvolvedores criaram sua própria autenticação. Um pesadelo.
• 2025-03-26: Autenticação padronizada com OAuth 2.1 e PKCE.
• 2025-06-18: Indicadores de Recurso Obrigatórios para interromper ataques de passagem de token.
• 2025-11-25: Integração de IdP corporativo e autenticação máquina a máquina.

A direção é clara: autenticação mais rigorosa, melhores controles corporativos. Essa é a boa notícia.

A Lacuna Que Realmente Importa

Aqui está a má notícia: a especificação não governa a autorização de servidor para banco de dados. Ela define como um cliente de IA se autentica em seu servidor MCP. Ela não aborda como seu servidor se autentica no banco de dados. Ela não define quais queries são permitidas. A especificação trata o servidor como um intermediário, não como um proxy transparente de encaminhamento de tokens. Um proxy encaminha a identidade. Um intermediário impõe políticas. Ele toma suas próprias decisões. A especificação lhe dá a fundação, mas você constrói as paredes.

Então, como as equipes estão realmente construindo essas paredes? A resposta depende de quem você pergunta.

O Estado Atual

O espaço de servidores MCP de banco de dados está crescendo. A maturidade varia muito, e algumas das coisas que existem são genuinamente alarmantes.

A Implementação de Referência Que Errou

A Anthropic projetou seu servidor MCP PostgreSQL original como somente leitura. Ele envolvia queries em uma transação e as revertia. Razoável na superfície. Mas o Datadog Security Labs encontrou uma falha crítica: o servidor aceitava queries multi-statement delimitadas por ponto e vírgula. Um invasor poderia enviar COMMIT; DROP SCHEMA public CASCADE;. O COMMIT sai da transação wrapper, e o DROP é executado fora do mecanismo de segurança.

A lição: Envolver queries em uma transação somente leitura não é um limite de segurança. É como tentar aprisionar o Magneto em uma gaiola de aço. A própria defesa é o que o invasor usa contra você.

Como impedir isso: O ataque nunca deveria chegar ao banco de dados. Um servidor MCP de produção precisa impor o modo somente leitura por padrão e usar controles baseados em políticas para restringir quais tipos de instruções SQL são permitidos por função. O DROP deve falhar contra o usuário de banco de dados somente leitura no nível da conexão. No gp-mcp-server, construí uma salvaguarda adicional: cada query é analisada em uma Abstract Syntax Tree (AST) usando JSQLParser antes da execução, rejeitando queries multi-statement de imediato. O ataque morre no parser antes mesmo de chegar ao banco de dados. Esse tipo de camadas é como a defesa em profundidade funciona na prática.

A Prompt Injection Que Ninguém Vê Chegando

Este é mais sutil. Um pesquisador demonstrou um ataque onde um ticket de suporte continha instruções para ler uma tabela sensível. Quando um agente de IA com credenciais elevadas revisou o ticket, ele seguiu as instruções e exfiltrou os dados. Chamo isso de Condições Snap. Três pedras que precisam estar na manopla para o ataque funcionar:

• A Pedra do Acesso: O agente pode alcançar dados privados.
• A Pedra da Exposição: Conteúdo não confiável entra no contexto do agente.
• A Pedra da Exfiltração: O agente tem um caminho para enviar dados para fora.

Todas as três precisam estar presentes. Remova qualquer uma, e o snap falha.

Como impedir isso: Você não pode corrigir a prompt injection com um único controle. Mas você pode remover as pedras da manopla:

• Controles de Política: Um servidor MCP maduro precisa de uma camada de política que defina tipos de instruções SQL permitidas e negadas por função, restringindo o que um agente pode alcançar. No gp-mcp-server, construí allowlists de esquema e tabela na camada de aplicação para o mesmo propósito.
• Redação de PII: Mascare dados sensíveis antes que eles entrem no contexto do LLM. O mascaramento em nível de coluna baseado em função é o ideal, mas mesmo a redação baseada em regex faz a diferença. No gp-mcp-server, construí um motor de redação que escaneia conjuntos de resultados em busca de padrões como e-mails, SSNs e tokens personalizados antes que a resposta seja enviada.
• Escopo de Credenciais: Implementações corporativas devem mapear funções de IdP diretamente para usuários de banco de dados, de modo que uma função de somente leitura obtenha credenciais de readonly_user e um analista obtenha analyst_user. Para ambientes onde a infraestrutura OAuth ainda não está implementada, o gp-mcp-server usa pools de conexão por chave de API com instâncias HikariCP dedicadas para fornecer isolamento de carga de trabalho.

Centenas de Servidores. Zero Autenticação.

Scans de segurança em 2025 pintaram um quadro sombrio. Pesquisadores encontraram centenas de servidores MCP públicos expostos à internet sem autenticação ou criptografia. Não eram casos extremos ou projetos de hobby. Eram servidores de nível de produção com acesso direto a bancos de dados e sem trilha de auditoria.

Como impedir isso: A autenticação deve ser um recurso de primeira classe, não uma reflexão tardia. Um servidor de produção deve suportar múltiplos modos de autenticação: acesso aberto apenas para desenvolvimento, Basic Auth para implantações simples e OAuth 2.1 com integração IdP corporativa para ambientes reais. TLS e mTLS devem ser totalmente suportados. No gp-mcp-server, construí chaves de API estruturadas (gpmcp_live_{id}.{secret}) com o ID visível nos logs para trilhas de auditoria, o segredo armazenado como um hash bcrypt e o gating @PreAuthorize em nível de método em cada execução de ferramenta._

Os Não Negociáveis

Os cenários de ataque acima mostram o que dá errado. Aqui está o que deve dar certo. Nenhum servidor MCP de banco de dados deve tocar dados de produção sem esses controles. Sem exceções.

• Princípio Zero: O Agente Não É Confiável Trate cada query como entrada hostil. O LLM não entende seu modelo de dados ou obrigações de conformidade. Não confie em nada. Valide tudo.
• Conexões Somente Leitura: Limite de privilégio não negociável no nível do banco de dados. Todo outro controle assume que este existe.
• Validação SQL: Filtragem baseada em política, análise em nível de AST e, idealmente, ambos. Queries malformadas ou maliciosas morrem antes de chegar ao banco de dados.
• Restrições de Resultado: Limites de linha, limites de bytes, timeouts. A truncagem consciente de tokens importa. 50.000 tokens de volta não dão ao LLM respostas melhores. Isso desperdiça dinheiro e degrada o raciocínio.
• Redação de PII: No lado do servidor, antes que os resultados entrem no contexto do LLM. Uma vez que os dados chegam ao modelo, eles são ingovernáveis. Não há "desfazer".
• Isolamento de Credenciais: Credenciais de banco de dados nunca aparecem em um payload MCP. Seja por escopo de token OAuth ou criptografia em repouso, um invasor que comprometa a camada de transporte não obtém nada útil.
• Autenticação: Obrigatória. Não opcional. Não "adicionaremos depois". Sem chave, sem token, sem query.

A Pilha Montada

Nenhum desses controles funciona sozinho. Conexões somente leitura não impedem a exfiltração de dados. A validação SQL não redige PII. Eles funcionam como um sistema. Cada controle sozinho é um Vingador solo. Capaz, mas vulnerável. Empilhe-os juntos e você terá a equipe montada. A ameaça tem que vencê-los todos simultaneamente.

O Design da Ferramenta É Uma Decisão de Segurança

Os controles o levam à mesa. Mas a forma como você estrutura as próprias ferramentas molda se os agentes se comportam de forma segura ou imprudente. A tentação é expor uma única ferramenta execute_query e deixar o LLM descobrir. Isso é uma falha de segurança disfarçada de simplicidade. Um agente com apenas uma ferramenta de query bruta gerará qualquer SQL que ele julgar útil. Sem grades de proteção. Sem fluxo de trabalho guiado. Sem restrições sobre o que ele explora primeiro.

A melhor abordagem são ferramentas construídas para fins específicos, organizadas em torno de um fluxo de trabalho deliberado:

• Descobrir o Esquema.
• Restringir a Query.
• Conter os Dados.
• Instrumentar o Sistema.

Ferramentas de descoberta permitem que o agente entenda o esquema antes de escrever SQL. Ferramentas de diagnóstico retornam resultados pré-computados e estruturados em vez de saída de query bruta. Essa abordagem pode gerar economias significativas de tokens, potencialmente reduzindo o uso em uma ordem de magnitude ou mais. Isso não é apenas uma vitória de custo. Menos tokens na janela de contexto significam menos área de superfície para alucinações e menos espaço para conteúdo injetado se esconder.

Essa decomposição é, em si, um padrão de segurança. Um agente com ferramentas separadas de descoberta, query e diagnóstico explorará naturalmente o esquema antes de tentar SQL ad-hoc. Um agente com ferramentas de análise integradas tem menos motivos para criar queries complexas que desafiam os limites da política. O design da ferramenta é engenharia de prompt com outro nome. A maioria das equipes ainda não está usando essa alavanca. No gp-mcp-server, apliquei esse princípio com 12 ferramentas focadas em descoberta de esquema, execução de query validada e perfil de dados, além de suporte a cursor no lado do servidor para grandes conjuntos de resultados. Aprofundei-me em segurança e observabilidade em vez de abranger amplamente o kit de ferramentas do DBA. Uma implementação de produção poderia expandir essa superfície significativamente com dezenas de ferramentas construídas para fins específicos, cobrindo diagnósticos, análises e administração, mas o princípio permanece: como você define o escopo das ferramentas determina quão seguramente o agente opera.

O Recurso de Segurança Mais Subestimado

Um padrão que merece mais atenção são as ferramentas definidas pelo usuário via configuração. Ferramentas personalizadas com suporte SQL, definidas em tempo de execução, sem necessidade de alterações de código. Pense no que isso significa. Uma equipe de banco de dados pode definir ferramentas com escopo preciso. Queries específicas contra tabelas específicas com parâmetros específicos. Eles as entregam aos usuários do agente de IA em vez de acesso a queries abertas. O agente obtém a capacidade de que precisa. A equipe do banco de dados mantém controle total sobre o SQL que realmente é executado. Essa é a intersecção de flexibilidade e governança que a maioria das implementações MCP está perdendo completamente.

Mas mesmo com todos esses controles em vigor, o panorama geral importa mais do que qualquer recurso individual. A integração de banco de dados MCP chegou. O protocolo está amadurecendo. O caso de uso é convincente. Os padrões que explorei no gp-mcp-server mostram que a segurança por design é alcançável: padrões somente leitura, controles de acesso baseados em políticas, autenticação em camadas e ferramentas construídas para fins específicos que restringem o comportamento do agente desde o início. Mas o espaço mais amplo ainda varia de "experimento interessante" a "ativamente perigoso".

O servidor entre o agente de IA e seus dados é o limite de segurança. Não os próprios controles de acesso do banco de dados. Não o treinamento do LLM. O servidor MCP. Os padrões existem, e a especificação está pronta. As implementações são open source e testáveis. A questão não é se os agentes de IA se conectarão aos seus bancos de dados. É se o limite de segurança estará em vigor quando o fizerem.

Descobrir o Esquema. Restringir a Query. Conter os Dados. Instrumentar o Sistema. Esse é o projeto.

Próximo nesta série: Na Parte 2, veremos como esses padrões de segurança escalam para uma implementação corporativa de nível de produção com ferramentas construídas para fins específicos, controles de acesso baseados em políticas e integração IdP completa. O protótipo lançou as bases. A versão corporativa monta a equipe.

Recursos gp-mcp-server: github.com/dbbaskette/gp-mcp-server Especificação MCP: modelcontextprotocol.io Vulnerabilidade MCP do Datadog: securitylabs.datadoghq.com OWASP Top 10 para LLMs: owasp.org

Dan Baskette | Head of Technical Marketing | 25+ anos construindo na intersecção de plataformas de dados e experiência do desenvolvedor (Sun Microsystems, EMC, Pivotal, VMware, Broadcom). Quando não estou conectando agentes de IA a bancos de dados ou caminhando pelas Smokies, insisto que todos deveriam experimentar a codificação de IA.

"Com grandes poderes vêm grandes responsabilidades." Especialmente com SQL. GitHub: dbbaskette

Como parceira certificada, a VirtuAllIT pode auxiliar sua empresa na avaliação, implementação e otimização de soluções de segurança para integração de bancos de dados com agentes de IA, garantindo que sua infraestrutura esteja protegida e em conformidade com as melhores práticas de mercado.