Skip to content

Please Don't Kill My Vibe: Empowering Agents with Data Flow Control

🕒 Published (v1): 2025-12-05 02:24 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

This paper argues that LLM agent safety—covering policy violations, process corruption, and prompt injection—is fundamentally a data flow problem, and that systems (not just models or workflows) should natively enforce Data Flow Control (DFC) policies. The authors introduce FlowGuard, a rewrite-based DFC policy language for DBMSes grounded in provenance polynomials, and outline a research agenda extending DFC to full multi-tool agent ecosystems.

Problem

LLM agents interacting with stateful systems (databases, APIs) cause three classes of failures: (1) policy violations (e.g., privacy regulation breaches), (2) process corruption (illegal FSM state transitions), and (3) prompt injection (unsanitized data hijacking agent behavior). Current mitigations are model-centric (fine-tuning, RLHF, prompt engineering) or ad hoc application logic, neither of which provides systematic, low-overhead, administrator-configurable enforcement independent of agent code.

Method

FlowGuard represents in-DBMS data flows using provenance polynomials where \(+\) encodes alternative derivations (aggregation/deduplication) and \(\times\) encodes joins. A policy has the form:

POLICY [OVER | UPDATE] <relations>
[DIMENSION <extra relations/subqueries>]
[AGG <aggregation expressions>]
CONSTRAINT <boolean over provenance aggregates>
ON FAIL KILL [QUERY | ROW]

Enforcement is via query rewriting: rather than capturing full provenance (which is expensive), FlowGuard inlines AGG clauses into existing plan operators (e.g., \(\gamma\)) and appends lightweight KILL UDFs at the query root. For update policies (FSM enforcement), updated tuples are modeled as subqueries. Multi-query/multi-step enforcement (e.g., cross-query prompt injection propagation) is identified as an open problem, with monotonic constraints and lattice-based analysis as promising directions.

Key Contributions

  • DFC framing: recast agent safety (privacy, process integrity, prompt injection) as a unified data flow control problem, analogous to how DBMSes absorbed access control from application code.
  • FlowGuard: a declarative, provenance-polynomial-based DFC policy language enforced inside the DBMS via query rewriting, with no system internals modification required.
  • Efficient enforcement: avoids full provenance capture; rewrites inline policy aggregates directly into query plans, achieving 1–2+ orders of magnitude lower overhead than GProM (logical provenance) and SmokedDuck/FaDE (physical provenance) baselines on TPC-H.
  • Research agenda: outlines open problems for general DFC across multi-tool agent ecosystems, including multi-query enforcement, physical interventions (logging, buffering, redaction), and federated DFC via Model Context Protocol (MCP).

Results

  • Evaluated on a subset of TPC-H queries (scale factor 1, monotonic queries over lineitem) with a single K-threshold policy.
  • FlowGuard incurs ~0 overhead for most queries and is sometimes faster than the baseline (no-policy) execution.
  • Reduces policy enforcement overhead by 1–2+ orders of magnitude compared to logical (GProM) and physical (SmokedDuck+FaDE) provenance baselines.
  • Unlike the Physical baseline, FlowGuard requires no DBMS internals modification.

(Note: only a single simple policy is tested; complex aggregation policies are not evaluated against Physical baseline due to FaDE limitations.)

Limitations

  • Single-policy, simple-constraint experiments only: the Physical baseline (SmokedDuck/FaDE) does not support complex aggregations or predicates, making a fair broad comparison impossible.
  • In-DBMS scope only: FlowGuard does not yet extend to multi-tool agent ecosystems, external API calls, or LLM prompt flows.
  • Multi-table policy performance degrades: naive rewrites for cross-table constraints (e.g., median(T.x + S.y)) are costly; only semiring-distributable aggregates are tractable.
  • Multi-query/multi-step enforcement is unsolved: detecting cross-query prompt injection propagation through a DAG of queries remains an open research problem.
  • Policy language expressiveness vs. analyzability tradeoff: extending beyond provenance polynomials (for tool calls, external state) lacks formal semantics.
  • MCP/federated DFC: exposing fine-grained provenance through tool interfaces is stated as expensive and context-overwhelming; no solution is presented.

Relevance to Harnesses / Meta-Harnesses

FlowGuard is directly relevant to harness and meta-harness design because it proposes a system-level enforcement layer sitting beneath agent orchestration code—exactly the role a harness plays above it. A harness that invokes tools against a DFC-enabled DBMS could obtain policy enforcement "for free" without baking safety logic into each agent's workflow, mirroring how meta-harnesses centralize cross-cutting concerns (rate limiting, retry, logging). The paper's research agenda on MCP-level DFC declaration schemas is particularly actionable for harness authors: it suggests that tool interfaces should carry DFC metadata, enabling a meta-harness to selectively grant tool access based on policy visibility guarantees. The multi-query enforcement gap (detecting prompt injection across a DAG of agent steps) is precisely the accountability problem that harnesses are positioned to solve via execution tracing.