Resumen Técnico: Control de Flujo de Datos (DFC)

1. Planteamiento del Problema

El artículo aborda una brecha crítica en la seguridad de los agentes de IA y los analistas de datos que interactúan con sistemas de bases de datos. Mientras que la investigación reciente se centra en mejorar la corrección del SQL generado por agentes (es decir, ¿refleja la consulta la intención del usuario?), a menudo descuida la seguridad. Una consulta puede ser semánticamente correcta y, aun así, violar restricciones regulatorias, de privacidad o de negocio respecto a cómo se combinan, transforman y liberan los datos.

Los mecanismos de seguridad actuales son insuficientes por tres razones principales:

1. Control de Acceso vs. Flujo de Datos: Los controles de acceso tradicionales gobiernan quién puede leer los datos, no cómo fluyen y se combinan los datos durante la ejecución de la consulta.
2. Restricciones de Integridad: Estas gobiernan el estado estático de la base de datos, no los estados intermedios de la consulta o sus derivaciones.
3. Sobrecarga de la Proveniencia: Aunque los sistemas de proveniencia pueden auditar las derivaciones retrospectivamente, la materialización de polinomios de proveniencia completos incurre en costos de rendimiento prohibitivos (que oscilan entre un 20% y un 10,000× de ralentización), lo que los hace inadecuados para la aplicación en tiempo real.
4. Enfoques Probabilísticos: Confiar en los Modelos de Lenguaje Extensos (LLM) para verificar la seguridad mediante prompts o validación post-hoc es inherentemente probabilístico, carece de garantías formales y se degrada a medida que la complejidad de las políticas y la escala de los datos aumentan.

Los autores argumentan que la seguridad de los datos es fundamentalmente un problema de infraestructura que requiere un mecanismo determinista para aplicar políticas declarativas sobre los flujos de datos a nivel de tupla dentro del propio DBMS.

2. Metodología

El artículo introduce el Control de Flujo de Datos (DFC), un marco para especificar declarativamente y garantizar la aplicación de políticas sobre los flujos de datos. La metodología consta de tres componentes principales:

2.1 Formalización de la Seguridad de los Datos

Los autores formalizan la seguridad de los datos como predicados agregados sobre monomios de proveniencia.

• Invarianza del Optimizador: Un desafío clave es que los planes de ejecución físicos de las consultas afectan la estructura de los polinomios de provenciencia. Para asegurar que las políticas sean invariantes al optimizador, el DFC define las políticas sobre una representación normalizada: una bolsa de monomios de proveniencia ($M(o)$) para cada tupla de salida $o$, en lugar de la estructura del polinomio en sí.
• Agregación de Semirreales: El sistema aprovecha las propiedades de los semirreales (por ejemplo, números naturales, conjuntos) para computar eficientemente los agregados sobre estos monomios sin materializar el polinomio completo.

2.2 El Lenguaje de Políticas PGN

Los autores proponen PGN (Notación de Guardia de Proveniencia), un lenguaje declarativo para expresar políticas de DFC. PGN permite a los usuarios definir:

• Fuentes ($S$): Relaciones a las que se aplica la política.
• Restricciones ($B$): Expresiones booleanas sobre los atributos de las relaciones de origen y los monomios de proveniencia (por ejemplo, "costo máximo < 100" o "conteo de usuarios distintos > 1").
• Resolución ($F$): Acciones tomadas ante una violación, tales como REMOVE (eliminar la tupla), KILL (abortar la consulta), o Funciones Definidas por el Usuario (UDF) personalizadas que pueden transformar datos o invocar LLMs para decisiones semánticas.
• Extensiones: PGN admite dimensiones externas (referenciando catálogos del sistema u otras tablas), sumideros (tablas objetivo para inserciones/actualizaciones), fuentes requeridas (anclaje) y resoluciones a nivel de relación.

2.3 El Motor de Aplicación Passant

Passant es una capa de reescritura de consultas portátil que aplica las políticas PGN sin materializar la proveniencia completa. Emplea dos estrategias de reescritura principales:

1. Partial-Push (Empuje Parcial): Empuja los cálculos de agregación de políticas a través de los joins, pero aún requiere computar los polinomios de proveniencia para acceder a los atributos de entrada.
2. Full-Push (Empuje Total): La principal contribución. Reescribe la consulta base para "piggyback" (montarse sobre) los cálculos de agregación de la política directamente en la ejecución de la consulta base utilizando anotaciones de semirreales.
   • Anotación de Hoja: Las relaciones de entrada se anotan con elementos de semirreales (por ejemplo, 1 para el conteo, valores de atributos para la suma).
   • Reglas de Operador: Los joins multiplican las anotaciones; las agregaciones las suman.
   • Resultado: Las restricciones de la política se evalúan de forma integrada durante la ejecución normal de la consulta, evitando el "impuesto de proveniencia" de re-escanear tablas o realizar joins con datos de linaje.

El sistema maneja constructos SQL-92, incluyendo outer joins (vía anotaciones de conjunto), uniones y self-joins (vía optimizaciones de simetría).

3. Contribuciones Clave

1. Formalización: Elevar la proveniencia de una herramienta de auditoría a un mecanismo activo de aplicación de políticas al definir la seguridad como restricciones sobre la proveniencia a nivel de registro que son invariantes al optimizador de consultas.
2. Lenguaje PGN: Diseñar un lenguaje declarativo capaz de expresar restricciones complejas (privacidad, anclaje, límites de transformación) que referencian el contexto del sistema, privilegios de usuario y metadatos relacionales.
3. Motor y Algoritmos Passant:
   • Una línea base de post-procesamiento ingenua utilizando sistemas de proveniencia existentes.
   • Algoritmos de reescritura Partial-Push y Full-Push que reducen significativamente el estado intermedio.
   • Optimizaciones para políticas plantilladas (colapsar múltiples umbrales en una única restricción dominante) y self-joins simétricos (reduciendo la complejidad factorial a lineal).
4. Evaluación Empírica: Demostrar que la aplicación de DFC puede lograrse con un overhead casi nulo en diversos motores de bases de datos.

4. Resultados

Los autores evaluaron Passant en cinco motores de DBMS: DuckDB, Umbra, PostgreSQL, DataFusion y SQLServer.

• Rendimiento: En consultas TPC-H, Full-Push logró un ≈0% de overhead en la mayoría de los casos y, sorprendentemente, superó a la consulta base (Sin Política) en el motor Umbra.
• Comparación con Baselines:
  • Proveniencia Lógica/Física: Estos enfoques incurrieron en ralentizaciones masivas (2,000% a 75,000% para Lógica; 300% a 700% para Física) debido al costo de materializar y unir los datos de proveniencia.
  • Verificaciones de LLM: En una comparación de 13 consultas TPC-H contra 1–32 políticas, DFC fue órdenes de magnitud más rápido que las verificaciones basadas en LLM, que también carecen de garantías formales.
• Escalabilidad:
  • Conteo de Políticas: El sistema escala de forma sublineal con el número de políticas mediante la optimización de plantillas (colapso de restricciones).
  • Self-Joins: Las optimizaciones de política simétrica redujeron la complejidad de la aplicación de factorial ($O(n!)$) a lineal ($O(n)$) para consultas con muchos self-joins.
• Aplicación: En una tarea de aplicación de máquina de estados de proceso de negocio, Full-Push fue dos órdenes de magnitud más rápido que un enfoque basado en LLM, proporcionando además corrección determinista.

5. Significado y Reivindicaciones

El artículo afirma que el Control de Flujo de Datos representa el primer paso para mover la seguridad de los datos de los "prompts y chequeos post-hoc" hacia la infraestructura de datos.

• Seguridad por Defecto: Al lograr un overhead casi nulo, DFC hace que sea factible aplicar políticas de seguridad en cada consulta, haciendo que la seguridad sea la elección natural en lugar de un complemento opcional y costoso.
• Garantías Deterministas: A diferencia de los guardias probabilísticos de LLM, DFC proporciona garantías formales y deterministas de que los flujos de datos cumplen con las restricciones regulatorias y de negocio.
• Cambio de Infraestructura: El trabajo argumenta que la seguridad no debe delegarse a las aplicaciones o agentes, sino que debe ser aplicada por el motor de la base de datos, gobernando cómo se transforman y combinan los datos, no solo quién accede a ellos.

Los autores señen que, si bien el prototipo actual se centra en consultas SQL-92 monotónicas, extender DFC a constructos no monotónicos (negación, recursión) es un siguiente paso necesario para una aplicabilidad más amplia. El sistema está disponible como código abierto.