Text-to-SQL seguro: cómo lo diseñé para limitar al modelo
Dejar que un modelo consulte una base de datos exige decidir qué no puede hacer. Esta página describe el diseño de mi plataforma de agentes, que está en construcción, en fase 0.
El riesgo de dejar que un modelo escriba SQL
Text-to-SQL convierte una pregunta en lenguaje natural en una consulta. El riesgo es que la consulta la genera un modelo: puede escribir en vez de leer, pedir tablas que no corresponden, devolver datos de otro cliente o lanzar una consulta que no termina nunca.
El diseño: una sola puerta, con restricciones en dos capas
En la plataforma de agentes de IA para empresas, la SQL Tool es el único acceso a las tablas. Las restricciones viven en dos capas distintas:
- En la herramienta: solo lectura, lista blanca, SQL validado, timeout y límite de filas.
- En la base de datos: las tablas llevan RLS por tenant_id, y el JWT del usuario lleva el tenant_id.
El agente de SQL es uno de los tres a los que deriva el orquestador de LangGraph, y la base guarda además un catálogo de tablas y métricas.
La misma regla, ya en producción en AgendaGo
AgendaGo, que sí está en producción, no hace text-to-SQL: su modelo llama herramientas. Pero aplica la regla de aislamiento que este diseño toma: el tenant sale del JWT y nunca del modelo, y los parámetros prohibidos se descartan, con RLS de Postgres habilitado en todo el esquema.
Stack relacionado
- PostgreSQL
- LangChain
- LangGraph
- Python