Text-to-SQL seguro: como o projetei para limitar o modelo

O risco de deixar um modelo escrever SQL

O text-to-SQL transforma uma pergunta em linguagem natural numa consulta. O risco é que a consulta é gerada por um modelo: ele pode escrever em vez de ler, pedir tabelas que não deveria, devolver dados de outro cliente ou lançar uma consulta que nunca termina.

O design: uma única porta, com restrições em duas camadas

Na plataforma de agentes de IA para empresas, a SQL Tool é o único acesso às tabelas. As restrições vivem em duas camadas distintas:

• Na ferramenta: somente leitura, lista permitida, SQL validado, timeout e limite de linhas.
• No banco de dados: as tabelas levam RLS por tenant_id, e o JWT do usuário leva o tenant_id.

O agente de SQL é um dos três para os quais o orquestrador do LangGraph encaminha, e o banco guarda também um catálogo de tabelas e métricas.

A mesma regra, já em produção no AgendaGo

O AgendaGo, que está em produção, não faz text-to-SQL: o modelo dele chama ferramentas. Mas aplica a regra de isolamento que este design adota: o tenant vem do JWT e nunca do modelo, e os parâmetros proibidos são descartados, com RLS do Postgres habilitado em todo o esquema.