🤖 AI

Data Flow Control: Data Safety Policies for AI Agents

Dit artikel introduceert Data Flow Control (DFC), een framework met de Passant query-herziene laag die declaratieve, tuple-niveau dataveiligheidsbeleidsregels direct binnen DBMS-engines afdwingt met verwaarloosbare overhead, waardoor de gegevensbescherming wordt verschoven van achteraf uitgevoerde controles naar de kern van de data-infrastructuur.

Oorspronkelijke auteurs: Charlie Summers, Eugene Wu

Gepubliceerd 2026-06-05

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Charlie Summers, Eugene Wu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer slimme, enthousiaste assistent hebt (een "AI-agent") die je helpt bij het beheren van je financiën, het schrijven van rapporten of het analyseren van gegevens. Je zegt tegen deze assistent: "Controleer alstublieft mijn bonnetjes en vertel me welke ik kan aftrekken van de belasting." De assistent is geweldig in het opvolgen van je instructies — hij vindt de juiste bonnetjes en doet de berekeningen correct uit.

Maar hier is het probleem: "Correct" zijn is niet hetzelfde als "veilig" zijn.

Je assistent kan de berekeningen perfect uitvoeren, maar per ongeluk de wet overtreden. Bijvoorbeeld, de assistent zou kunnen:

Privacy lekken: Je persoonlijke creditcardgegevens in een openbaar rapport tonen in plaats van alleen het totaalbedrag.
Hallucineren: Een nepbonnetje verzinnen voor een luxe auto die je nooit hebt gekocht.
De regels breken: 100% van een diner met biefstuk aftrekken wanneer de belastingwet slechts 50% toestaat.

Momenteel proberen we deze fouten te voorkomen door de AI strikte instructies (prompts) te geven of door het werk nadat het klaar is te controleren. Maar het artikel stelt dat dit is alsoals proberen een dief te vangen nadat hij het geld al heeft gestolen. Het is onbetrouwbaar en traag.

De Oplossing: Data Flow Control (DFC)

De auteurs stellen een nieuw systeem voor genaamd Data Flow Control (DFC). Zie DFC niet als een bewaker die bij de deur staat, maar als slimme loodgieterswerk in de leidingen waar de data doorheen stroomt.

In plaats van de AI te vragen: "Is dit veilig?", bouwt het systeem de veiligheidsregels direct in de database-engine zelf. Het zorgt ervoor dat naarmate data van de ene naar de andere plek beweegt, het niet de regels kan schenden, ongeacht hoe slim of in de war de AI ook is.

Het Kernidee: Het "Recept" versus de "Ingrediënten"

Om te begrijpen hoe dit werkt, stel je een chef (de AI) voor die probeert een soep (het eindrapport) te maken.

Traditionele Veiligheid: Je zegt tegen de chef: "Gebruik geen gif." De chef kan dit vergeten, of verkeerd begrijpen, en toch gif toevoegen.
DFC Veiligheid: Je plaatst een filter in de pan. Als de chef probeer gif toe te voegen, blokkeert de filter het fysiek voordat het in de soep terechtkomt. De soep is standaard veilig, zelfs als de chef afgeleid is.

Hoe ze het hebben gedaan (De Magische Trucs)

Het paper introduceert twee belangrijke hulpmiddelen om dit mogelijk te maken:

1. PGN (Het Regelboek)
Dit is een eenvoudige taal voor het schrijven van veiligheidsregels. Het is als een checklist voor de data.

Voorbeeldregel: "Als je een bonnetje aan de lijst met uitgaven toevoegt, moet dit afkomstig zijn van een echt bonnetje in onze database, en mag je niet meer dan 50% van een maaltijd aftrekken."
Het systeem controleert deze regels terwijl de data wordt verwerkt, niet achteraf.

2. Passant (De Herschrijver)
Dit is de motor die het systeem snel maakt.

De Oude Manier (De "Belasting"): Om te controleren of data veilig is, schreven oude systemen eerst een enorme, gedetailleerde geschiedenis van elk gebruikt ingrediënt op (genaamd "provenance"). Dit is als het opschrijven van elke stap van het recept in een schrift voordat je zelfs maar aan de soep kunt proeven. Het is ontzettend traag en verbruikt veel geheugen.
De Nieuwe Manier (Passant): Passant is een "slimme herschrijver". In plaats van de hele geschiedenis op te schrijven, herschrijft het de instructies van de chef on the fly. Het zegt: "Hé, terwijl je de soep mengt, controleer dan meteen even het zoutgehalte."
Het Resultaat: Het systeem dwingt deze veiligheidsregels af met bijna nul vertraging. In hun tests was het zo snel dat het soms zelfs sneller was dan het draaien van de query zonder enige veiligheidsregels!

Waarom dit ertoe doet

Het paper heeft dit getest op vijf verschillende databasesystemen (zoals verschillende merken keukenapparatuur) en concludeerde dat:

Het Snel is: Het vertraagt de boel niet.
Het Betrouwbaar is: Het vertrouwt niet op gokken (zoals AI-modellen doen); het gebruikt harde wiskunde om veiligheid te garanderen.
Het Flexibel is: Het kan complexe regels aan, zoals "Meng geen data van Klant A met Klant B" of "Zorg ervoor dat elke uitgave een bijbehorend bonnetje heeft."

De Kernboodschap

Dit paper betoogt dat we moeten stoppen met het behandelen van dataveiligheid als een "checklist" die we achteraf uitvoeren. In plaats daarvan moeten we veiligheid inbouwen in de eigenlijke leidingen die onze data vervoeren. Door gebruik te maken van Data Flow Control, kunnen we ervoor zorgen dat zelfs als een AI-agent een fout maakt of probeert de kantjes er vanaf te lopen, de database zelf als een vangnet fungeert, waardoor illegale, privé of onjuiste data nooit het systeem kan verlaten.

Het is het verschil tussen hopen dat je chauffeur voorzichtig is en het installeren van een auto die je fysiek voorkomt van de weg af te rijden.

Technische Samenvatting: Data Flow Control (DFC)

1. Probleemstelling

Het artikel behandelt een kritieke kloof in de veiligheid van AI-agenten en data-analisten die met databasesystemen interageren. Terwijl recent onderzoek zich richt op het verbeteren van de correctheid van door agenten gegenereerde SQL (i.e., weerspiegelt de query de gebruikersintentie?), wordt de veiligheid vaak verwaarloosd. Een query kan semantisch correct zijn, maar toch schendingen veroorzaken van regelgevende, privacy- of zakelijke beperkingen met betrekking tot hoe gegevens worden gecombineerd, getransformeerd en vrijgegeven.

Huidige veiligheidsmechanismen zijn onvoldoende om drie belangrijke redenen:

Toegangscontrole versus Datastroom: Traditionele toegangscontroles regelen wie gegevens mag lezen, niet hoe gegevens stromen en combineren tijdens de query-executie.
Integriteitsbeperkingen: Deze regelen de statische staat van de database, niet de tussenliggende query-staten of afleidingen.
Provenance-overhead: Hoewel provenance-systemen afleidingen achteraf kunnen auditeren, brengt het materialiseren van volledige provenance-polynomen prohibitieve prestatiekosten met zich mee (variërend van 20× tot 10.000× vertraging), wat ze ongeschikt maakt voor real-time handhaving.
Probabilistische Benaderingen: Het vertrouwen op Large Language Models (LLMs) om veiligheid te controleren via prompts of post-hoc validatie is inherent probabilistisch, mist formele garanties en verslechtert naarmate de beleidscomplexiteit en de schaal van de data toenemen.

De auteurs stellen dat dataveiligheid fundamenteel een infrastructuurprobleem is dat een deterministisch mechanisme vereist om declaratieve policies af te dwingen over tuple-niveau datastromen binnen de DBMS zelf.

2. Methodologie

Het artikel introduceert Data Flow Control (DFC), een framework voor het declaratief specificeren en garanderen van policy-handhaving over datastromen. De methodologie bestaat uit drie kerncomponenten:

2.1 Formalisering van Dataveiligheid

De auteurs formaliseren dataveiligheid als geaggregeerde predicaten over provenance-monomialen.

Optimizer Invariance: Een belangrijke uitdaging is dat fysieke queryplannen de structuur van provenance-polynomen beïnvloeden. Om policies optimizer-invariant te maken, definieert DFC policies over een genormaliseerde representatie: een bag of provenance monomials ( $M(o)$ ) voor elke output-tuple $o$ , in plaats van de polynomiale structuur zelf.
Semiring Aggregatie: Het systeem maakt gebruik van semiring-eigenschappen (bijv. natuurlijke getallen, verzamelingen) om efficiënt aggregaties over deze monomialen te berekenen zonder de volledige polynoom te materialiseren.

2.2 De PGN Policy Language

De auteurs stellen PGN (Provenance Guard Notation) voor, een declaratieve taal voor het uitdrukken van DFC-policies. PGN stelt gebruikers in staat om het volgende te definiëren:

Bronnen ( $S$ ): Relaties waarop de policy van toepassing is.
Constraints ( $B$ ): Booleanse expressies over attributen van bronrelaties en provenance-monomialen (bijv. "maximale kosten < 100" of "aantal unieke gebruikers > 1").
Resolutie ( $F$ ): Acties bij overtreding, zoals REMOVE (tuple verwijderen), KILL (query afbreken), of aangepaste User-Defined Functions (UDF's) die gegevens kunnen transformeren of een LLM kunnen aanroepen voor semantische beslissingen.
Extensies: PGN ondersteunt externe dimensies (verwijzend naar systeemcatalogi of andere tabellen), sinks (doeltabellen voor inserts/updates), vereiste bronnen (grounding) en relatie-niveau resoluties.

2.3 De Passant Enforcement Engine

Passant is een draagbare query-rewriting laag die PGN-policies afdwingt zonder volledige provenance te materialiseren. Het maakt gebruik van twee belangrijke rewriting-strategieën:

Partial-Push: Duwt policy-aggregatieberekeningen door joins heen, maar vereist nog steeds het berekenen van provenance-polynomen om toegang te krijgen tot input-attributen.
Full-Push: De primaire bijdrage. Het herschrijft de basisquery om policy-aggregatieberekeningen direct "mee te laten liften" op de uitvoering van de basisquery met behulp van semiring-annotaties.
- Leaf Annotation: Input-relaties worden geannoteerd met semiring-elementen (bijv. 1 voor count, attribuutwaarden voor sum).
- Operator Rules: Joins vermenigvuldigen annotaties; aggregaties tellen ze op.
- Resultaat: Policy-constraints worden inline geëvalueerd tijdens de normale query-executie, waardoor de "provenance tax" van het opnieuw scannen van tabellen of het joinen met lineage-data wordt vermeden.

Het systeem handelt SQL-92 constructen af, inclusioneel outer joins (via set-annotaties), unions en self-joins (via symmetrie-optimalisaties).

3. Belangrijkste Bijdragen

Formalisering: Het verheffen van provenance van een auditing-tool naar een actief policy-handhavingsmechanisme door veiligheid te definiëren als constraints over record-niveau provenance die invariant zijn voor de query-optimizer.
PGN Taal: Het ontwerpen van een declaratieve taal die in staat is complexe constraints uit te drukken (privacy, grounding, transformatiegrenzen) die refereren aan systeemcontext, gebruikersrechten en relationele metadata.
Passant Engine & Algoritmen:
- Een naïeve post-processing baseline met behulp van bestaande provenance-systemen.
- Partial-Push en Full-Push rewriting-algoritmen die de tussenliggende staat aanzienlijk verminderen.
- Optimalisaties voor templated policies (het samenvoegen van meerdere drempelwaarden tot één dominante constraint) en symmetric self-joins (het reduceren van de faculteit-complexiteit naar lineair).
Empirische Evaluatie: Het aantonen dat DFC-handhaving kan worden bereikt met nagenoeg nul overhead over diverse database-engines.

4. Resultaten

De auteurs hebben Passant geëvalueerd over vijf DBMS-engines: DuckDB, Umbra, PostgreSQL, DataFusion en SQLServer.

Prestaties: Over TPC-H queries behaalde Full-Push in de meeste gevallen ≈0% overhead en presteerde verrassend genoeg beter dan de basisquery (No Policy) op de Umbra-engine.
Vergelijking met Baselines:
- Logical/Physical Provenance: Deze benaderingen veroorzaakten enorme vertragingen (2.000% tot 75.000% voor Logical; 300% tot 700% voor Physical) vanwege de kosten van het materialiseren en joinen van provenance-data.
- LLM Checks: In een vergelijking van 13 TPC-H queries tegenover 1–32 policies, was DFC orde van grootte sneller dan LLM-gebaseerde checks, die bovendien geen formele garanties bieden.
Schaalbaarheid:
- Policy Count: Het systeem schaalt sublineair met het aantal policies door middel van templated optimalisatie (het samenvoegen van constraints).
- Self-Joins: Symmetrische policy-optimalisaties verminderden de handhavingscomplexiteit van faculteit ( $O(n!)$ ) naar lineair ( $O(n)$ ) voor queries met veel self-joins.
Toepassing: In een taak voor het afdwingen van een business process state-machine, was Full-Push twee orden van grootte sneller dan een LLM-gebaseerde aanpak terwijl het deterministische correctheid bood.

5. Betekenis en Claims

Het artikel claimt dat Data Flow Control de eerste stap is naar het verplaatsen van dataveiligheid van "prompts en post-hoc checks" naar de data-infrastructuur.

Veiligheid als Standaard: Door een nagenoeg nul-overhead te bereiken, maakt DFC het mogelijk om veiligheidspolicies op elke query af te dwingen, waardoor veiligheid de natuurlijke keuze wordt in plaats van een optionele, dure toevoeging.
Deterministische Garanties: In tegenstelling tot probabilistische LLM-guards biedt DFC formele, deterministische garanties dat datastromen voldoen aan regelgevende en zakelijke restricties.
Infrastructuur Verschuiving: Het werk beargumenteert dat veiligheid niet aan applicaties of agenten moet worden gedelegeerd, maar moet worden afgedwongen door de database-engine zelf, die reguleert hoe gegevens worden getransformeerd en gecombineerd, en niet alleen wie toegang heeft.

De auteurs merken op dat hoewel de huidige prototype zich richt op monotone SQL-92 queries, het uitbreiden van DFC naar niet-monotone constructen (negatie, recursie) een noodzakelijke volgende stap is voor bredere toepasbaarheid. Het systeem is open-source beschikbaar.