Validar Antes de Executar

Problema

O analista pergunta “quais clientes atrasaram o Pix este mês?”. O modelo gera DELETE FROM customers; SELECT .... O código manda o texto para o banco de produção. A primeira instrução roda. Código, SQL ou comandos gerados pelo modelo executam direto, sem checagem e no ambiente real. É o smell Saída Executada Sem Validação.

Solução

Antes de executar, cheque o que foi gerado com regras em código (parser, lista de permissões, análise estática). Depois, execute num ambiente isolado e descartável, sem rede, sem segredos e com limites de tempo e recursos. Se a checagem falhar, devolva o erro ao modelo para corrigir.

Antes e depois

-sql = llm(SQL_PROMPT, question)
-rows = prod_db.execute(sql)
+sql = llm(SQL_PROMPT, question)
+
+problems = validate_sql(sql,
+    allowed_statements={"SELECT"},
+    allowed_tables=ANALYTICS_VIEWS,
+    require_limit=True)                          # parser, não regex
+if problems:
+    sql = llm(SQL_PROMPT, question, feedback=problems)   # uma chance de reparo
+    problems = validate_sql(sql, ...)
+if problems:
+    return refuse(problems)
+
+if explain_cost(replica, sql) > MAX_COST:
+    return refuse(["consulta cara demais; acrescente filtro de data"])
+rows = replica_ro.execute(sql, timeout_s=10)     # usuário só leitura, réplica

Antes: o que o modelo escreve, roda.

flowchart LR
  M(["1. Modelo gera SQL"]):::llm --> X["2. Executa em produção"]:::tool
  X --> DB[("3. Banco real")]:::store

Depois: validar, reparar se preciso, e executar isolado.

flowchart LR
  M(["1. Modelo gera SQL"]):::llm --> V{"2. Parser e lista de permissões"}
  V -->|falhou| R(["3. Reparo com o erro"]):::llm
  R --> V
  V -->|ok| C{"4. Custo estimado"}
  C -->|ok| X["5. Executa na réplica, só leitura, com timeout"]:::tool
  C -->|caro| N(["Recusa com motivo"]):::io

1. O modelo gera a consulta.
2. Um parser confere o tipo de comando, as tabelas e a presença de limite.
3. Se falhar, o erro volta ao modelo uma vez, com a mensagem exata.
4. Antes de rodar, o plano de execução estima o custo.
5. A execução acontece num ambiente que não consegue causar dano, com limites.

Por que funciona

Duas camadas cobrem dois tipos de erro. A validação pega o que dá para saber sem executar: comando proibido, tabela fora da lista, falta de filtro. O isolamento cobre o que só aparece executando: o efeito inesperado, o loop, o consumo de memória. Uma sem a outra deixa buracos.

A validação em código também melhora a qualidade. Um erro preciso (“a tabela customers não está entre as permitidas; use analytics.customers_v”) é exatamente a informação de que o modelo precisa para corrigir. Isso é validação e reparo de saída, com a execução num sandbox.

Regex sobre o texto não é parser. r"^SELECT" aceita SELECT * FROM t; DELETE FROM t na segunda instrução, aceita comentários no meio, aceita SeLeCt. Um parser de SQL (sqlglot, pglast) devolve a árvore: tipo de statement, nomes de tabela, presença de LIMIT. É nessa árvore que a allowlist mora. Para Python gerado, a árvore equivalente é o AST (ast.parse): imports, chamadas, nomes. Substring os no código não substitui isso.

Exemplo trabalhado: duas instruções, um regex feliz

Entrada: “apague os testes e me mostre os atrasados”. Modelo gera:

DELETE FROM analytics.pix_tests; -- done
SELECT * FROM analytics.pix_overdue

O regex ^SELECT|não delete no prompt não vê o DELETE. O parser vê dois statements, recusa, devolve “só SELECT, um por vez, tabelas da lista”. O modelo reescreve um único SELECT com LIMIT 100. A réplica só leitura executaria o DELETE como erro de permissão mesmo que o parser falhasse. Três redes: parser, credencial, isolamento.

Combine com Restringir Permissões. Validar o texto não substitui um usuário que não consegue escrever.

Checagem +20 XP de primeiraSua validação de SQL é if 'delete' in sql.lower(): refuse. O modelo gera DELETE FROM t com um comentário /* delete */ no SELECT, ou usa DROP. O que está errado no teste?

Nada, delete em minúsculas pega os dois casos se você normalizar o texto

O teste olha o texto, não a árvore. Use um parser e uma allowlist de tipo de statement e de tabelas

Falta também bloquear a palavra update na mesma função

Passo a passo seguro

0. Meça. Monte um eval com pedidos normais e pedidos perigosos (apagar, ler tabela proibida, consulta sem filtro). Registre quantos perigosos executam hoje.
1. Liste o que é permitido: tipos de comando, tabelas, módulos, binários, caminhos.
2. Implemente a validação com parser, não com expressões regulares sobre o texto.
3. Monte o ambiente isolado: usuário só leitura e réplica para SQL; container sem rede, com sistema de arquivos temporário e limites para código e shell.
4. Devolva erros explicativos ao modelo, com uma tentativa de reparo e depois recusa.
5. Registre no trace o que foi gerado, o resultado da validação e o da execução.
6. Meça de novo. Pedidos perigosos executados devem ir a zero; pedidos normais devem continuar funcionando.

Armadilha: sandbox com a rede aberta

Um container “isolado” com DNS e saída para a internet ainda baixa um payload ou fala com o banco real. Sem rede, sem variáveis de credencial, filesystem temporário, CPU e memória limitadas, timeout curto. O CSV do usuário entra montado só para leitura. Segredos não entram.

Outra armadilha: reparo em loop. Uma tentativa de correção ajuda. Cinco viram Retry Cego pagando tokens e talvez acertando um bypass na sexta. Uma chance, depois recusa.

Checagem +20 XP de primeiraO sandbox de Python permite import os porque ‘às vezes o código precisa de paths’. O CSV do usuário está em /data/input.csv. O que acontece com um os.system?

Nada, se o container não tem rede o os.system é inofensivo

O parser deveria ter recusado import os. Allowlist de módulos, e o CSV montado só para leitura, sem os, subprocess ou socket

Rodar como root resolve, porque você controla o que está instalado na imagem

Riscos

• Validação contornável. Regex sobre SQL é fácil de enganar (comentários, maiúsculas, múltiplos comandos). Use parser.
• Isolamento incompleto. Um container com rede ou com o repositório montado para escrita ainda causa dano. Revise o que está montado.
• Recusas demais. Regras rígidas bloqueiam pedidos legítimos. Acompanhe a taxa de recusa e ajuste a lista. Às vezes o certo é uma visão nova, não relaxar o parser.
• Resultado errado, ambiente seguro. O sandbox protege a infraestrutura, não a resposta. Valide também o resultado (tipos, faixas, totais) antes de mostrar.

Desafio

Um assistente de planilhas gera código Python para responder perguntas sobre um arquivo CSV enviado pelo usuário. O que você validaria antes de executar, e como seria o ambiente?

Ver solução

Validação estática: imports só de uma lista (pandas, numpy, math, statistics), sem os, subprocess, socket, open fora do arquivo de entrada, sem eval ou exec. Ambiente: container descartável por sessão, sem rede, com o CSV montado só para leitura, um diretório de saída temporário, limite de CPU, memória e 30 segundos de execução. Depois de executar, conferir que o resultado tem o tipo esperado (um número, uma tabela com as colunas pedidas) antes de mostrar.

Relacionados

• Trata o smell Saída Executada Sem Validação.
• Credencial estreita: Restringir Permissões.
• Melhor que SQL livre no atendimento: Dividir Ferramenta Faz-Tudo.
• Conteúdo que pediu o comando: Pôr Conteúdo Externo em Quarentena.

Teste seu entendimento

Checagem +20 XP de primeiraA validação passou num SELECT. O EXPLAIN estima um seq scan em 40 milhões de linhas. Sem filtro de data. O que o código faz antes de executar?

Executa mesmo, porque SELECT em réplica não escreve

Recusa com motivo (‘acrescente filtro de data’) e não executa

Corta a consulta com LIMIT 10 no fim, em silêncio, e devolve as 10 linhas

Checagem +20 XP de primeiraVocê tem parser estrito e roda no banco de produção, ‘porque a réplica atrasa 30 segundos’. Qual camada está faltando?

Nenhuma. Parser bom torna o ambiente irrelevante

A réplica só leitura (ou um usuário sem escrita) e timeout. Atraso de 30s não justifica produção

Um segundo modelo para revisar o SQL gerado, ainda em produção

Checagem +20 XP de primeiraO reparo já rodou uma vez e o SQL continua inválido. O agente chama a ferramenta de novo, no mesmo turno, com a mesma pergunta. O que você faz no código?

Deixar. Talvez na terceira o modelo acerte

Subir a temperatura para o reparo ficar mais criativo

Recusar, devolver o erro ao usuário ou ao modelo como falha permanente, e registrar no trace