Riepilogo Tecnico: Data Flow Control (DFC)

1. Definizione del Problema

Il documento affronta una lacuna critica nella sicurezza degli agenti IA e degli analisti di dati che interagiscono con i sistemi di database. Mentre la ricerca recente si concentra sul miglioramento della correttezza delle query SQL generate dagli agenti (ovvero, se la query riflette l'intento dell'utente), spesso trascura la sicurezza. Una query può essere semanticamente corretta ma violare vincoli normativi, di privacy o di business riguardanti il modo in cui i dati vengono combinati, trasformati e rilasciati.

Gli attuali meccanismi di sicurezza sono insufficienti per tre ragioni primarie:

1. Controllo degli Accessi vs. Flusso di Dati: I controlli degli accessi tradizionali regolano chi può leggere i dati, non come i dati fluiscono e si combinano durante l'esecuzione della query.
2. Vincoli di Integrità: Questi regolano lo stato statico del database, non gli stati intermedi o le derivazioni delle query.
3. Overhead della Provenance: Sebbene i sistemi di provenance possano auditare le derivazioni a posteriori, la materializzazione di interi polinomi di provenance comporta costi prestazionali proibitivi (che variano da un rallentamento di 20× a 10.000×), rendendoli inadatti all'enforcement in tempo reale.
4. Approcci Probabilistici: Affidarsi ai Large Language Models (LLM) per verificare la sicurezza tramite prompt o validazione post-hoc è intrinsecamente probabilistico, manca di garanzie formali e degrada all'aumentare della complessità delle policy e della scala dei dati.

Gli autori sostengono che la sicurezza dei dati sia fondamentalmente un problema di infrastruttura che richiede un meccanismo deterministico per imporre policy dichiarative sui flussi di dati a livello di tupla all'interno del DBMS stesso.

2. Metodologia

Il documento introduce il Data Flow Control (DFC), un framework per specificare e garantire in modo dichiarativo l'applicazione di policy sui flussi di dati. La metodologia consiste in tre componenti principali:

2.1 Formalizzazione della Sicurezza dei Dati

Gli autori formalizzano la sicurezza dei dati come predicati aggregati su monomi di provenance.

• Invarianza dell'Ottimizzatore: Una sfida chiave è che i piani fisici delle query influenzano la struttura dei polinomi di provenance. Per garantire che le policy siano invarianti rispetto all'ottimizzatore, il DFC definisce le policy su una rappresentazione normalizzata: un bag of provenance monomials ($M(o)$) per ogni tupla di output $o$, piuttosto che sulla struttura del polinomio stessa.
• Aggregazione Semirings: Il sistema sfrutta le proprietà dei semiring (ad esempio, numeri naturali, insiemi) per calcolare efficientemente gli aggregati su questi monomi senza materializzare l'intero polinomio.

2.2 Il Linguaggio di Policy PGN

Gli autori propongono PGN (Provenance Guard Notation), un linguaggio dichiarativo per esprimere le policy DFC. PGN consente agli utenti di definire:

• Sorgenti ($S$): Le relazioni alle quali la policy si applica.
• Vincoli ($B$): Espressioni booleane sugli attributi delle relazioni sorgente e sui monomi di provenance (ad esempio, "costo massimo < 100" o "conteggio utenti distinti > 1").
• Risoluzione ($F$): Azioni intraprese in caso di violazione, come REMOVE (scarta la tupla), KILL (interrompe la query), o funzioni utente definite (UDF) che possono trasformare i dati o invocare LLM per decisioni semantiche.
• Estensioni: PGN supporta dimensioni esterne (riferimento a cataloghi di sistema o altre tabelle), sink (tabelle target per insert/update), sorgenti richieste (grounding) e risoluzioni a livello di relazione.

2.3 Il Motore di Enforcement Passant

Passant è uno strato di rewriting delle query portabile che applica le policy PGN senza materializzare l'intera provenance. Impiega due strategie principali di rewriting:

1. Partial-Push: Spinge i calcoli aggregati delle policy attraverso le join, ma richiede comunque il calcolo dei polinomi di provenance per accedere agli attributi di input.
2. Full-Push: Il contributo principale. Riscrive la query base per far sì che i calcoli aggregati della policy siano "piggyback" (trascinati) direttamente sull'esecuzione della query base utilizzando annotazioni di semiring.
   • Annotazione delle Foglie: Le relazioni di input sono annotate con elementi di semiring (ad esempio, 1 per il conteggio, valori di attributo per la somma).
   • Regole degli Operatori: Le join moltiplicano le annotazioni; le aggregazioni le sommano.
   • Risultato: I vincoli della policy vengono valutati inline durante la normale esecuzione della query, evitando la "tassa di provenance" derivante dal re-scansione delle tabelle o dalla join con dati di lineage.

Il sistema gestisce le costrutti SQL-92, incluse le outer join (tramite annotazioni di set), le union e le self-join (tramite ottimizzazioni di simmetria).

3. Contributi Chiave

1. Formalizzazione: Elevare la provenance da strumento di auditing a meccanismo attivo di enforcement delle policy, definendo la sicurezza come vincoli sulle derivazioni dei record che siano invarianti rispetto all'ottimizzatore della query.
2. Linguaggio PGN: Progettare un linguaggio dichiarativo capace di esprimere vincoli complessi (privacy, grounding, limiti di trasformazione) che facciano riferimento al contesto di sistema, ai privilegi dell'utente e ai metadati relazionali.
3. Motore e Algoritmi Passant:
   • Un baseline di post-processing ingenuo utilizzando sistemi di provenance esistenti.
   • Algoritmi di rewriting Partial-Push e Full-Push che riducono significativamente lo stato intermedio.
   • Ottimizzazioni per policy templatizzate (collasso di molteplici soglie in un singolo vincolo dominante) e self-join simmetriche (riduzione della complessità fattoriale a lineare).
4. Valutazione Empirica: Dimostrare che l'enforcement DFC può essere ottenuto con un overhead quasi nullo su diversi motori di database.

4. Risultati

Gli autori hanno valutato Passant su cinque motori DBMS: DuckDB, Umbra, PostgreSQL, DataFusion e SQLServer.

• Prestazioni: Sulle query TPC-H, il Full-Push ha ottenuto un overhead ≈0% nella maggior parte dei casi e, sorprendentemente, ha superato la query base (No Policy) sul motore Umbra.
• Confronto con i Baseline:
  • Provenance Logica/Fisica: Questi approcci hanno subito rallentamenti massicci (2.000% - 75.000% per la Logica; 300% - 700% per la Fisica) a causa del costo di materializzazione e join dei dati di provenance.
  • Controlli LLM: In un confronto tra 13 query TPC-H contro 1–32 policy, il DFC è stato ordini di grandezza più veloce dei controlli basati su LLM, che mancano inoltre di garanzie formali.
• Scalabilità:
  • Conteggio Policy: Il sistema scala in modo sub-lineare con il numero di policy utilizzando l'ottimizzazione dei template (collasso dei vincoli).
  • Self-Joins: Le ottimizzazioni di policy simmetriche hanno ridotto la complessità di enforcement da fattoriale ($O(n!)$) a lineare ($O(n)$) per query con molte self-join.
• Applicazione: In un compito di enforcement di una macchina a stati di processo aziendale, il Full-Push è stato due ordini di grandezza più veloce di un approccio basato su LLM, fornendo al contempo correttezza deterministica.

5. Significato e Rivendicazioni

Il documento sostiene che il Data Flow Control rappresenti il primo passo verso lo spostamento della sicurezza dei dati dai "prompt e controlli post-hoc" all'interno dell'infrastruttura dati.

• Sicurezza di Default: Raggiungendo un overhead quasi nullo, il DFC rende fattibile l'applicazione di policy di sicurezza su ogni query, rendendo la sicurezza una scelta naturale anziché un'opzione costosa.
• Garanzie Deterministiche: A differenza dei guardiani probabilistici degli LLM, il DFC fornisce garanzie formali e deterministiche che i flussi di dati rispettino i vincoli normativi e di business.
• Spostamento verso l'Infrastruttura: Il lavoro sostiene che la sicurezza non debba essere delegata alle applicazioni o agli agenti, ma deve essere imposta dal motore del database stesso, governando come i dati vengono trasformati e combinati, non solo chi vi accede.

Gli autori notano che, sebbene il prototipo attuale si concentri su query SQL-92 monotone, estendere il DFC a costrutti non monotoni (negazione, ricorsione) è un passo successivo necessario per una più ampia applicabilità. Il sistema è disponibile open-source.