🤖 AI

Data Flow Control: Data Safety Policies for AI Agents

This paper introduces Data Flow Control (DFC), a framework featuring the Passant query rewriting layer that enforces declarative, tuple-level data safety policies directly within DBMS engines with negligible overhead, thereby shifting data protection from post-hoc checks to the core data infrastructure.

Original authors: Charlie Summers, Eugene Wu

Published 2026-06-05

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Charlie Summers, Eugene Wu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a very smart, eager assistant (an "AI Agent") who helps you manage your finances, write reports, or analyze data. You tell this assistant, "Please check my receipts and tell me which ones I can deduct for taxes." The assistant is great at following your instructions—it finds the right receipts and does the math correctly.

But here's the problem: Being "correct" isn't the same as being "safe."

Your assistant might do the math perfectly but accidentally break the law. For example, it might:

Leak privacy: Show your personal credit card details in a public report instead of just the total.
Hallucinate: Invent a fake receipt for a luxury car you never bought.
Break the rules: Deduct 100% of a steak dinner when the tax law only allows 50%.

Currently, we try to stop these mistakes by giving the AI strict instructions (prompts) or checking its work after it's done. But the paper argues this is like trying to catch a thief after they've already stolen the money. It's unreliable and slow.

The Solution: Data Flow Control (DFC)

The authors propose a new system called Data Flow Control (DFC). Think of DFC not as a security guard standing at the door, but as smart plumbing inside the pipes where the data flows.

Instead of asking the AI, "Is this safe?", the system builds the safety rules directly into the database engine itself. It ensures that as data moves from one place to another, it cannot violate the rules, no matter how smart or confused the AI is.

The Core Idea: The "Recipe" vs. The "Ingredients"

To understand how this works, imagine a chef (the AI) trying to make a soup (the final report).

Traditional Safety: You tell the chef, "Don't use poison." The chef might forget, or misunderstand, and add poison anyway.
DFC Safety: You install a filter in the pot. If the chef tries to add poison, the filter physically blocks it before it hits the soup. The soup is safe by default, even if the chef is distracted.

How They Did It (The Magic Tricks)

The paper introduces two main tools to make this happen:

1. PGN (The Rulebook)
This is a simple language for writing safety rules. It's like a checklist for the data.

Example Rule: "If you are adding a receipt to the expense list, it must come from a real receipt in our database, and you can't deduct more than 50% of a meal."
The system checks these rules while the data is being processed, not after.

2. Passant (The Rewriter)
This is the engine that makes the system fast.

The Old Way (The "Tax"): To check if data is safe, old systems would first write down a massive, detailed history of every single ingredient used (called "provenance"). This is like writing down every step of the recipe in a notebook before you can even taste the soup. It's incredibly slow and uses up a lot of memory.
The New Way (Passant): Passant is a "smart rewriter." Instead of writing down the whole history, it rewrites the chef's instructions on the fly. It says, "Hey, while you're mixing the soup, just check the salt level right then and there."
The Result: The system enforces these safety rules with almost zero slowdown. In their tests, it was so fast that sometimes it was actually faster than running the query without any safety rules at all!

Why This Matters

The paper tested this on five different database systems (like different brands of kitchen appliances) and found that:

It's Fast: It doesn't slow things down.
It's Reliable: It doesn't rely on guessing (like AI models do); it uses hard math to guarantee safety.
It's Flexible: It can handle complex rules, like "Don't mix data from Customer A with Customer B" or "Ensure every expense has a matching receipt."

The Bottom Line

This paper argues that we need to stop treating data safety as a "checklist" we do after the fact. Instead, we need to build safety into the very pipes that carry our data. By using Data Flow Control, we can ensure that even if an AI agent makes a mistake or tries to cut corners, the database itself acts as a safety net, preventing illegal, private, or incorrect data from ever leaving the system.

It's the difference between hoping your driver is careful and installing a car that physically prevents you from driving off the road.

Technical Summary: Data Flow Control (DFC)

1. Problem Statement

The paper addresses a critical gap in the safety of AI agents and data analysts interacting with database systems. While recent research focuses on improving the correctness of agent-generated SQL (i.e., does the query reflect user intent?), it often neglects safety. A query can be semantically correct yet violate regulatory, privacy, or business constraints regarding how data is combined, transformed, and released.

Current safety mechanisms are insufficient for three primary reasons:

Access Control vs. Data Flow: Traditional access controls govern who can read data, not how data flows and combines during query execution.
Integrity Constraints: These govern the static state of the database, not intermediate query states or derivations.
Provenance Overhead: While provenance systems can audit derivations retrospectively, materializing full provenance polynomials incurs prohibitive performance costs (ranging from 20% to 10,000× slowdown), making them unsuitable for real-time enforcement.
Probabilistic Approaches: Relying on Large Language Models (LLMs) to check safety via prompts or post-hoc validation is inherently probabilistic, lacks formal guarantees, and degrades as policy complexity and data scale increase.

The authors argue that data safety is fundamentally an infrastructure problem requiring a deterministic mechanism to enforce declarative policies over tuple-level data flows within the DBMS itself.

2. Methodology

The paper introduces Data Flow Control (DFC), a framework for declaratively specifying and guaranteeing policy enforcement over data flows. The methodology consists of three core components:

2.1 Formalization of Data Safety

The authors formalize data safety as aggregate predicates over provenance monomials.

Optimizer Invariance: A key challenge is that physical query plans affect the structure of provenance polynomials. To ensure policies are optimizer-invariant, DFC defines policies over a normalized representation: a bag of provenance monomials ( $M(o)$ ) for each output tuple $o$ , rather than the polynomial structure itself.
Semiring Aggregation: The system leverages semiring properties (e.g., natural numbers, sets) to efficiently compute aggregates over these monomials without materializing the full polynomial.

2.2 The PGN Policy Language

The authors propose PGN (Provenance Guard Notation), a declarative language for expressing DFC policies. PGN allows users to define:

Sources ( $S$ ): Relations the policy applies to.
Constraints ( $B$ ): Boolean expressions over attributes of source relations and provenance monomials (e.g., "maximum cost < 100" or "count distinct users > 1").
Resolution ( $F$ ): Actions taken on violation, such as REMOVE (drop the tuple), KILL (abort the query), or custom User-Defined Functions (UDFs) that may transform data or invoke LLMs for semantic decisions.
Extensions: PGN supports external dimensions (referencing system catalogs or other tables), sinks (target tables for inserts/updates), required sources (grounding), and relation-level resolutions.

2.3 The Passant Enforcement Engine

Passant is a portable query rewriting layer that enforces PGN policies without materializing full provenance. It employs two main rewriting strategies:

Partial-Push: Pushes policy aggregate computations down through joins but still requires computing provenance polynomials to access input attributes.
Full-Push: The primary contribution. It rewrites the base query to "piggyback" policy aggregate computations directly onto the base query execution using semiring annotations.
- Leaf Annotation: Input relations are annotated with semiring elements (e.g., 1 for count, attribute values for sum).
- Operator Rules: Joins multiply annotations; aggregations sum them.
- Result: Policy constraints are evaluated inline during normal query execution, avoiding the "provenance tax" of re-scanning tables or joining with lineage data.

The system handles SQL-92 constructs, including outer joins (via set annotations), unions, and self-joins (via symmetry optimizations).

3. Key Contributions

Formalization: Elevating provenance from an auditing tool to an active policy enforcement mechanism by defining safety as constraints over record-level provenance that are invariant to the query optimizer.
PGN Language: Designing a declarative language capable of expressing complex constraints (privacy, grounding, transformation limits) that reference system context, user privileges, and relational metadata.
Passant Engine & Algorithms:
- A naive post-processing baseline using existing provenance systems.
- Partial-Push and Full-Push rewriting algorithms that significantly reduce intermediate state.
- Optimizations for templated policies (collapsing multiple thresholds into a single dominating constraint) and symmetric self-joins (reducing factorial complexity to linear).
Empirical Evaluation: Demonstrating that DFC enforcement can be achieved with near-zero overhead across diverse database engines.

4. Results

The authors evaluated Passant across five DBMS engines: DuckDB, Umbra, PostgreSQL, DataFusion, and SQLServer.

Performance: Across TPC-H queries, Full-Push achieved ≈0% overhead in most cases and, surprisingly, outperformed the base query (No Policy) on the Umbra engine.
Comparison with Baselines:
- Logical/Physical Provenance: These approaches incurred massive slowdowns (2,000% to 75,000% for Logical; 300% to 700% for Physical) due to the cost of materializing and joining provenance data.
- LLM Checks: In a comparison of 13 TPC-H queries against 1–32 policies, DFC was orders of magnitude faster than LLM-based checks, which also lack formal guarantees.
Scalability:
- Policy Count: The system scales sub-linearly with the number of policies using templated optimization (collapsing constraints).
- Self-Joins: Symmetric policy optimizations reduced enforcement complexity from factorial ( $O(n!)$ ) to linear ( $O(n)$ ) for queries with many self-joins.
Application: In a business process state-machine enforcement task, Full-Push was two orders of magnitude faster than an LLM-based approach while providing deterministic correctness.

5. Significance and Claims

The paper claims that Data Flow Control represents the first step toward moving data safety from "prompts and post-hoc checks" into the data infrastructure.

Safety by Default: By achieving near-zero overhead, DFC makes it feasible to enforce safety policies on every query, making safety the natural choice rather than an optional, expensive add-on.
Deterministic Guarantees: Unlike probabilistic LLM guards, DFC provides formal, deterministic guarantees that data flows comply with regulatory and business constraints.
Infrastructure Shift: The work argues that safety should not be delegated to applications or agents but enforced by the database engine itself, governing how data is transformed and combined, not just who accesses it.

The authors note that while the current prototype focuses on monotonic SQL-92 queries, extending DFC to non-monotonic constructs (negation, recursion) is a necessary next step for broader applicability. The system is available open-source.