Saltar al contenido principal

Seguridad

Datafala no ve tus datos​

La API nunca se conecta a tu base de datos y nunca recibe sus credenciales. Solo conoce el DDL, las descripciones, el contexto y los ejemplos que registraste en el panel. Los resultados de las consultas quedan solo en tu sistema.

SQL Guard​

Todo SQL generado por el LLM, todo ejemplo guardado en el panel y todo caso de evaluación pasan por el SQL Guard, que analiza la consulta como árbol sintáctico (no como texto) en el dialecto de tu schema. Rechaza todo lo que no está explícitamente permitido:

  1. Una sola sentencia, y debe ser SELECT (se aceptan CTE no recursivas). INSERT, UPDATE, DELETE, DDL, SELECT ... INTO, bloqueos (FOR UPDATE) y múltiples sentencias se rechazan.
  2. Solo tablas registradas y visibles. Las tablas del sistema (pg_catalog, information_schema, mysql, performance_schema, sys) nunca se aceptan. En Firebird, los objetos con los prefijos RDB$, MON$ y SEC$ se ignoran en la importación y no se pueden consultar.
  3. Solo columnas registradas y visibles. SELECT * se expande y se rechaza si alcanza una columna oculta.
  4. Funciones por lista de permitidos según el dialecto (agregación, fecha, texto, matemática y condicionales). Las funciones peligrosas como pg_sleep, pg_read_file, dblink, SLEEP, BENCHMARK y LOAD_FILE están bloqueadas, igual que las variables @@/@ y los comentarios ejecutables /*! */ en MySQL. En Firebird, se rechazan GEN_ID, NEXT VALUE FOR, RDB$GET_CONTEXT, RDB$SET_CONTEXT y las llamadas a procedimientos/UDF no permitidos.
  5. Placeholders y parámetros coinciden: todo %(nombre)s tiene valor en params, y viceversa.
  6. LIMIT siempre aplicado, reescrito en el árbol, salvo en agregaciones que demostrablemente devuelven una fila. Un LIMIT mayor que max_rows se reduce. En Firebird, el Guard limita con FIRST/SKIP o ROWS según la consulta.

En Firebird, las consultas sin FROM también se rechazan; no uses RDB$DATABASE para evitar el requisito de consultar una tabla registrada. EXECUTE BLOCK, EXECUTE PROCEDURE, SELECT ... WITH LOCK, PLAN y otras formas que no sean un SELECT permitido también se bloquean.

Si el primer SQL es rechazado, la API pide una corrección al LLM una sola vez, informando solo códigos genéricos, para que el LLM nunca descubra lo que ocultaste.

Defensa en profundidad

El Guard es la primera capa. La segunda es tuya: un usuario de base de datos de solo lectura, con acceso solo a las tablas registradas y tiempo máximo por consulta. Consulta Ejecutar el SQL.

Claves y secretos​

  • API keys: 256 bits aleatorios, guardadas solo como hash SHA-256 y mostradas una sola vez.
  • La clave de tu LLM: guardada cifrada (Fernet) y descifrada solo en el momento de la llamada al proveedor.
  • Contraseñas del panel: Argon2, con una política de contraseña fuerte y un límite de intentos de inicio de sesión.

Qué va al LLM​

El prompt incluye el schema visible (sin tablas ni columnas ocultas), el contexto, los ejemplos, la fecha de hoy y la pregunta. Los comentarios de feedback y los casos de evaluación nunca entran en el prompt. Como la explanation puede repetir fragmentos del prompt, no pongas secretos en el contexto del panel.

Los datos enviados al LLM siguen la política del proveedor que elegiste, en tu cuenta. El administrador del tenant puede ver en el Historial del panel exactamente el prompt enviado en cada pregunta.

Transporte y headers​

Toda llamada usa HTTPS. Las respuestas de /v1 traen Cache-Control: no-store; no dependas de la caché HTTP para reutilizar respuestas, usa el historial o tu propia caché por request_id.