LLM que escreve bom SQL não garante SQL seguro: permissões precisam estar no código

O texto parte de uma experiência com uma ferramenta de analytics em linguagem natural sobre Snowflake Cortex, usada com dados de engajamento e desempenho de campo na área de saúde. O ponto central: testar text-to-SQL só por "a query roda e o resultado bate" não pega o caso em que a resposta está certa para a pessoa errada. Um representante que pede "vendas trimestrais dos meus hospitais" e recebe a região inteira é o exemplo.

A proposta tem camadas. Antes da geração, busca-se o contexto do usuário (papel, unidade de negócio, território, contas atribuídas) e o modelo só enxerga tabelas e colunas permitidas, com campos sensíveis marcados no catálogo de metadados. Depois, o SQL gerado é parseado e reescrito antes de executar. Nos 900 testes sintéticos, as intervenções mais comuns foram filtro de linha no WHERE (285), mascaramento de coluna (240) e restrição de escopo (165). Do total, 40% rodaram sem mudança, 20% precisaram de filtro de linha, 15% de mascaramento, 11,7% de reescrita de join, 6,7% foram para revisão humana e 6,7% foram bloqueadas.

A validação também rejeita SELECT *, consultas que cruzam escopos, resultados enormes e joins de risco, e tudo passa por um gateway com conta de banco estreita. O texto diz que o text-to-SQL simples chegou a retornar cerca de 80 linhas não autorizadas em algumas consultas, que o RBAC estático ainda vazou por não enxergar contexto, e que a abordagem com políticas não vazou nada, com cerca de 6,5 ms extras por consulta. Os resultados vêm de um benchmark sintético e desidentificado, baseado em um trabalho aceito no IEEE ICICNIS 2026.

A cobertura anterior do CEVIU ajuda a situar o tema, sem tratar do mesmo estudo. Em 27 de março de 2026, o CEVIU noticiou "Manipulação Insegura de Saída: SQL Injection Através de LLM", sobre prompt injection usada para contornar proteções e executar consultas não autorizadas. Em 7 de setembro de 2026, veio "Desafios e Estratégias na Análise de Dados com IA Agentiva: Do Texto Livre ao SQL Governamental", sobre metadados inconsistentes em agentes que geram SQL. Agora o foco passa do diagnóstico do risco para uma contramedida medida: validação e reescrita em código, com números de vazamento e latência.

Para quem opera text-to-SQL em produção, a leitura é que acurácia sozinha é métrica incompleta. Vale medir linhas não autorizadas retornadas, como o texto faz. Os 6,5 ms por consulta sugerem que a camada de política não é o gargalo, mas o número vem de benchmark sintético e precisa ser reverificado no seu ambiente. Também reforça que prompt não substitui controle de acesso: a regra deve morar no parser, no catálogo e na conta do banco.