2026 Fall Microsoft Eval Workshop

I want to set up environment steering with a popular use case: NL2SQL. It turns out that producing the "correct query" is not enough, and often limits NL2SQL adoption.

After my students Haonan Wang and Jerry Liu surveyed nearly 600 blog and forum posts related to properties of database production readiness, they found that there are many other properties such as correctness under concurrent accesses, correctly handling the effects of integrity constraints, obeying access and safety rules, and writing queries that leverage indexes and other data structures.

Using these observations, they created the CARE-ful benchmark, being presented at NeurIPS 2026 later this year.

Let's look at integrity constraints. Jerry owns a number of projects in the lab and is leaving for a startup (this is fictional) so i want to delete his record

Well, the agent generates the "correct" DELETE query. But the database maintains referential integrity, so his projects get deleted too!! Doesn't seem particularly desirable.

A "production ready" agent should be aware of this possibility and ask the user what to do.

This is a case where the agent needs to understand constraints and other properties in the environment (which it may not even know about), anticipate the effects of potential actions, and "do the right thing".

The point of environment steering is that the agent does not see everything -- it observes the environment through a narrow tool call interface. In contrast, the environment can see everything, and perhaps it should be delegated more responsibility, and help steer the agent towards safer task completions.

I'll talk about this in the context of Data Flow Control for database queries.

Suppose the user asks the agent to pay their credit card bill by $50. The agent picks one of the user's balances and pays it down.

It turns out it violates the Truth in Lending Act! Regulation Z Section 53 states that the highest rate balances should be paid off first (id 1, 2) and not balances under dispute (id 2). How is the agent supposed to know the state of the database and all 62 sections of the regulation, among other requirements?

Let's see how well frontier models perform on detecting if a query abides by section 53. We give the LLM the query, the database contents, the query results, and the regulation text.

... and they do no better than a coin flip. In general, they simply do not have visibility into the query's data flows, which are needed to enforce many policies.

For instance, some regulations forbid aggregating protected groups (like races, sexes, disabilities, etc) because it may hide disparities.

Humans usually remember to do so, but will an agent?

What about user data policies on how they want their data to be used? Or business process? or other requirements?

Sometimes prompting works, but it's expensive and not guaranteed.

Are existing mechanisms enough?

Constraints restrict allowable data in the database, but not its use. Access controls prevent unauthorized users and actions, but not data's use. LLM checks filter tool calls, but not data's use.

What we want are constraints over data flows.

This is a similar concept to information flow control, which has been used in contextual safety (like Conseca, its follow ups, and Fides), but for databases. Here, we want a policy mechanism that's light weight, fast, general to any database, cheap, and scales to data. The last parts are particularly tricky.

The policy language is fairly simple. If we want to enforce disaggregation, the policy states that if a query reads from the students table

each output row must be derived from one distinct sex, income, etc...

and if not, the query should be aborted.

the constraint can join with and thus reference anything that is table-like in the database. This includes the database catalog, transaction state, foreign data wrappers, views, etc. So one can state that a policy only applies if the user is in a specific jurisdiction.

Also the expressions in the constraints are normal SQL expressions, so they can involve UDFs or even LLMs, but only if desired.

We can also limit the policy to queries that write to studentStats

The obvious approach is to materialize the query's data flows (its provenance) during execution, check the provenance for violations, and then kill the query or change its results if there are violations. However, provenance materialization, including our lab's prior work on physical provenance capture, is so slow that it's a non starter.

DFC instead embeds the enforcement into the query itself using a simple rust-based query rewriter, so it works for any DBMS. In our work, we've evaluated on DuckDB, Umbra, PostgreSQL, DataFusion, and SQLServer.

It's also fast. Other than Q4, which for correctness reasons needs to disable the query's semijoin optimization, it's basically free or in some cases speeds up the query.

Oh, it also enforces section 53 with 100% accuracy, and in millisecond cost.

We also applied DFC to agent safety benchmarks (being presented during the REALM 26 workshop at EMNLP).

Let's say the user asks to rebuy a shirt. The agent looks up past orders, finds the shirt and tries to buy it. So far so good.

But the system asks for an email confirmation code, so the agent reads the latest email, finds the code but also sees a GREAT DEAL on diet pills. Then it buys the pills.

The issue is that the user only wanted data to flow from their past orders into buy(), and from no other source. If we model each tool call as its input and output tables, we can write a simple DFC policy to this effect.

In our experiments, we simply asked an LLM to generate policies.

The key result is summarized in this Agent Dyn benchmark. Most existing safety approaches try to filter tool (but what if the user bought diet pills in the past?), construct a "safe plan" from the task before execution (how would it know to check email?), or detect safety violations in the prompt. Empirically, they all give up safety for task accuracy.

In these benchmarks, observing and enforcing policies over data flows is sufficient to basically eliminate safety violations and improve the task success rates above not even having defenses at all!

As an example, if the user asks to re-purchase a shirt, data flows should only go from the orders table to the shopping cart. If this were enforced, then any prompt injections that try to purchase other items would be harmless, detected, and prevented.

It is clear that better models are not enough, and the environment it executes against -- the Agentic Data Environment -- must shoulder the work, provide guarantees, and new capabilities. For instance, our lab also works on branchable environments to support agentic training and test-time exploration.

But just focusing on data environments is not enough for widespread trust of agent automation. Ultimately, agent automation is a quality problem, that no individual discipline can solve. Instead, it requires vertical integration of the technology and usability stack to control quality end-to-end.

That's also why the DAPLab vertically integrates researchers across applications and user interfaces; agent and model designs, RL/post-training, and optimizations; as well as cloud-level software infrastructure.