Consultas SQL geradas por IA devem passar por um serviço que limita tempo de execução, quantidade de resultados e permissões no PostgreSQL. O modelo propõe a consulta; a aplicação decide se ela pode ser executada. A proteção precisa existir no código e no banco, independentemente das instruções escritas no prompt.
Uma implantação prudente começa com perguntas restritas, dados selecionados e uma função de acesso exclusiva para o agente. Depois, acrescenta validação da estrutura da consulta, orçamento de execução e tratamento de resultados incompletos. Um comando que apenas lê dados ainda pode expor informações indevidas ou ocupar recursos demais.
Resumo rápido
- Use credenciais próprias para o agente e conceda somente o acesso necessário.
- Aplique prazo de execução no banco, além do prazo de espera da aplicação.
- Limite linhas e tamanho da resposta, sem presumir que isso limita todo o trabalho.
- Valide a consulta com um analisador de SQL e uma política explícita.
- Teste acesso entre clientes, funções permitidas e falhas antes de liberar a ferramenta.
1. Separe geração, autorização e execução
Uma pergunta como “quais produtos venderam mais no trimestre?” parece simples, mas deixa decisões em aberto. O período considera emissão ou pagamento? Devoluções entram no cálculo? O usuário pode consultar todas as filiais? Resolva essas regras antes de entregar um esquema de banco ao modelo.
O fluxo recomendado tem três partes. Primeiro, o modelo transforma a pergunta em uma proposta estruturada. Depois, um serviço verifica se a proposta respeita as regras de acesso e de consulta. Por fim, um executor aplica limites e busca os dados. Não entregue ao modelo uma conexão administrativa para que ele mesmo decida como se restringir.
Para começar, prefira um catálogo de consultas parametrizadas. O modelo escolhe uma intenção, como vendas por categoria, e informa parâmetros como período e filial. A aplicação preenche um comando previamente revisado. Isso reduz a flexibilidade, mas facilita demonstrar quais perguntas são suportadas e quais dados podem sair.
Se houver necessidade real de SQL livre, exponha somente um esquema analítico preparado para esse uso. O guia sobre conexão de agentes ao PostgreSQL por MCP descreve a integração. O transporte da ferramenta não define a autorização: as regras precisam continuar válidas seja qual for a forma de conexão.
2. Restrinja o acesso no próprio banco
Crie uma função de acesso, chamada role no PostgreSQL, exclusiva para o executor. Ela não deve ser superusuária, proprietária das tabelas ou herdar permissões administrativas. Faça um inventário das associações a outras roles antes de concluir que uma concessão pequena representa acesso pequeno.
Use GRANT apenas para os objetos necessários e revise privilégios já concedidos. A documentação de privilégios do PostgreSQL explica que um acesso concedido à tabela continua valendo mesmo que se tente retirar o mesmo privilégio de uma coluna. Por isso, prefira uma concessão cuidadosamente desenhada, em vez de liberar tudo e bloquear exceções depois.
Uma camada de visões analíticas pode apresentar somente campos úteis, como categoria, valor agregado e período. A equipe responsável pelo banco deve revisar como essas visões avaliam permissões e políticas de linha. Não presuma que criar uma visão aplica automaticamente a mesma separação de acesso da aplicação.
Quando o banco atende vários clientes, avalie políticas de segurança por linha, conhecidas como RLS. A documentação oficial de RLS registra exceções relevantes: superusuários e roles com BYPASSRLS ultrapassam essas políticas, e o proprietário da tabela normalmente também. Teste com a role efetiva do executor, não com a conta administrativa usada na configuração.
O identificador do cliente precisa vir da sessão autenticada, não da interpretação do modelo. Não aceite que um pedido em linguagem natural altere esse contexto. Para separar os problemas, trate “qual dado posso acessar?” como uma decisão de autorização e “qual consulta responde à pergunta?” como uma tarefa de geração.
3. Combine limites diferentes
Não existe um único controle que resolva duração, volume e exposição. Defina limites por classe de consulta e registre o motivo de cada um. Os valores do quadro são decisões de projeto a preencher conforme os testes, e não recomendações universais de configuração.
| Controle | O que restringe | O que ainda exige cuidado |
|---|---|---|
| statement_timeout | Duração de uma instrução no servidor | Acúmulo de várias consultas dentro de uma tarefa |
| lock_timeout | Espera para adquirir bloqueios | Trabalho executado depois da espera |
| LIMIT | Quantidade de linhas retornadas | Custo para calcular e ordenar essas linhas |
| Limite de bytes | Volume aceito pela aplicação | Dados já processados no banco |
| Privilégios e RLS | Objetos e linhas acessíveis | Resultados autorizados que ainda são sensíveis |
| Controle de concorrência | Consultas simultâneas | Uma consulta individual custosa |
O PostgreSQL documenta statement_timeout e lock_timeout nos parâmetros de conexão do cliente. O primeiro interrompe instruções que ultrapassam o prazo; o segundo trata espera por bloqueios. Configure o orçamento no contexto do executor e confirme o valor efetivo, evitando impor uma política do agente a todas as aplicações do banco.
Use uma transação controlada pela aplicação e, quando adequado, SET LOCAL para configurações que devem durar somente naquele contexto. Em pools de conexão, nos quais uma conexão física atende vários pedidos, isso ajuda a evitar vazamento de configuração entre usuários. O executor precisa garantir limpeza e desfazer a transação após erro.
Defina também um orçamento total por pergunta. Se o agente puder corrigir a consulta indefinidamente, cada tentativa respeitará seu prazo individual enquanto a tarefa completa continua gastando recursos. Restrinja número de tentativas, tempo acumulado e concorrência por conta. Mostre ao usuário quando o orçamento foi encerrado.
4. Valide o SQL antes de executar
Bloquear palavras com expressões regulares é uma barreira frágil. Comentários, funções e construções aninhadas tornam a linguagem mais complexa do que uma lista de termos. Use um analisador compatível com o dialeto PostgreSQL para examinar a árvore de sintaxe, que representa a estrutura do comando.
A política pode exigir uma única instrução, permitir apenas relações aprovadas, rejeitar bloqueios explícitos e restringir funções. Trate expressões de tabela comuns e subconsultas com o mesmo rigor do comando principal. O fato de o texto começar com SELECT não demonstra que ele é aceitável para o seu ambiente.
Parâmetros devem carregar valores, como datas e códigos. Nomes de tabela, coluna e direção de ordenação precisam ser escolhidos em uma lista controlada pela aplicação. Não use concatenação do texto fornecido pelo usuário para construir partes estruturais da consulta.
Considere uma transação somente para leitura como mais uma camada. A referência de SET TRANSACTION descreve suas restrições, inclusive diferenças para objetos temporários. Não a apresente como isolamento completo: ela não substitui privilégios, controle de funções ou proteção do conteúdo retornado.
O comando EXPLAIN pode apoiar uma revisão de plano, mas custo estimado não é uma promessa de duração. E EXPLAIN ANALYZE executa a instrução, conforme a documentação oficial. Não use essa opção como uma validação supostamente inofensiva de consultas desconhecidas em produção.
5. Exemplo: rede de lojas em Curitiba
Imagine uma rede de lojas de materiais esportivos em Curitiba que quer responder perguntas sobre vendas. O cenário é ilustrativo. A gerente regional pode consultar suas lojas, mas não precisa ver nomes, documentos ou endereços dos consumidores. A equipe prepara um conjunto de dados analíticos com essa finalidade.
Na primeira versão, o agente recebe um catálogo de métricas: receita faturada, quantidade vendida e devoluções registradas. Cada métrica tem uma definição aprovada. A ferramenta aceita período, agrupamento e filial autorizada. Quando a gerente pede “melhores produtos”, o agente esclarece se o critério é quantidade ou receita antes de executar.
O serviço obtém as filiais permitidas a partir da identidade da gerente. O modelo não recebe a possibilidade de substituir essa lista por outra. A consulta passa pela validação estrutural, inicia uma transação com as configurações escolhidas e retorna uma tabela limitada. A resposta informa período, métrica e eventual truncamento.
Se a consulta ultrapassar o prazo, o sistema informa que ela não terminou dentro do orçamento. Pode oferecer um período menor ou um agrupamento já aprovado. Não informa vendas iguais a zero e não inventa uma conclusão com base no erro. Uma falha de execução tem significado diferente de ausência de registros.
Antes de liberar a função, a equipe usa contas de duas regiões e perguntas idênticas. Confere que cada conta vê somente o conjunto autorizado. Também testa campos proibidos, consultas com múltiplas instruções, intervalos muito amplos e repetição automática. Os resultados esperados fazem parte do teste, sem depender do julgamento do próprio modelo.
6. Erros comuns
Acreditar que LIMIT torna qualquer consulta barata. Uma agregação ou ordenação pode exigir trabalho considerável antes de entregar poucas linhas. A referência de SELECT descreve a limitação das linhas retornadas e recomenda ordenação previsível quando a seleção precisa ser consistente. Limite de saída e limite de processamento são decisões diferentes.
Cortar a resposta sem avisar. Se a aplicação aceita somente parte das linhas ou dos bytes, marque o resultado como parcial. A síntese deve dizer que representa uma amostra ou uma lista limitada. Caso contrário, o usuário pode interpretar uma fração dos dados como o conjunto completo.
Encerrar a espera da aplicação e deixar a consulta ativa. Confirme o comportamento do driver ao cancelar e ao fechar a conexão. Teste se o trabalho para no servidor e se a conexão volta ao pool em condições de uso. O prazo da interface não é evidência suficiente.
Registrar dados sensíveis no histórico. Guarde identificador da tarefa, versão da política, duração e motivo de rejeição. A necessidade de armazenar perguntas, SQL ou resultados completos deve ser avaliada separadamente. Para vincular a análise a uma fonte identificável, veja o guia de registro de versões das fontes usadas pela IA.
Concluir que boa consulta significa boa resposta. Uma tabela correta ainda pode ser interpretada de forma errada. Confira unidade, período, filtros e definição da métrica na síntese. Quando faltam dados, aplique o tratamento descrito em fontes ausentes e contraditórias em respostas de IA, em vez de preencher a lacuna com suposições.
7. Perguntas frequentes
Basta pedir SQL seguro no prompt?
Não. O prompt pode orientar o modelo, mas a autorização e os limites precisam ser aplicados por componentes que ele não controla. Faça a execução falhar quando a consulta violar a política, mesmo que o modelo apresente uma justificativa convincente.
Uma réplica de leitura resolve todos os riscos?
Ela pode separar parte da carga do banco principal, mas continua contendo dados e consumindo recursos. Além disso, o produto precisa considerar a atualização dos dados da réplica. Mantenha restrições de acesso, orçamento e uma indicação adequada da referência temporal usada na resposta.
Qual limite de linhas devo escolher?
Escolha pelo uso da resposta. Uma lista exibida na tela, uma síntese textual e uma exportação têm necessidades diferentes. Teste também o tamanho das colunas e a utilidade do resultado truncado. Não trate uma contagem pequena como garantia de resposta pequena em bytes.
Posso liberar funções do banco?
Somente após revisar o que cada função faz, seus privilégios e os dados que pode acessar. Permitir uma chamada pelo nome não equivale a compreender seu efeito. Comece por uma lista pequena e documentada, com testes executados usando a mesma role da ferramenta.
O agente pode corrigir consultas que falharam?
Pode, dentro de um orçamento definido e com nova validação completa. O erro enviado ao modelo deve conter somente informações necessárias à correção. Não revele detalhes internos, credenciais ou dados de outros clientes. Ao esgotar as tentativas, devolva uma explicação acionável ao usuário.
