Fabric Data Agent Query Governance and Control

Fabric Data Agents Choosing Query Language by Context: The Governance Implications

Frank Garofalo

10 Jul 2026 — 5 min read

Fabric data agents are already making governance decisions for you.

If the agent can choose the query path, then query-language selection belongs in your control plane, not in the prompt.

Microsoft Fabric data agents can answer across multiple execution targets, including semantic models, lakehouses, warehouses, KQL databases, notebooks, and external sources. That flexibility is powerful. It is also where governance gets slippery.

My blunt take: the real risk is not agent autonomy. The risk is autonomy without deterministic controls over which language, endpoint, and semantic layer gets used.

Back in Q4, I sat in a finance review where the same “gross margin by region” question produced two different answers within 20 minutes. One path hit a certified semantic model. The other went direct to warehouse tables with a different returns filter. Nobody had a model problem. They had a routing problem.

Why query-language choice is a governance decision

A lot of teams still talk about query-language choice like it is a developer convenience issue.

It isn’t.

When a Fabric data agent decides whether to answer through a semantic model, generate SQL against a warehouse, hit a KQL database, call a notebook, or reach outside Fabric, it is choosing a policy surface. Each path carries different business definitions, permissions, lineage artifacts, and operational blast radius.

That matters because the user only sees one thing: the answer. They do not see whether it came from a certified semantic layer with governed measures, a raw engine query over tables, or a notebook doing ad hoc transformation.

Once multi-path execution is built into the platform, governance has to move up a layer and govern path selection itself.

My mental model is simple: prompt interpretation is the data plane, route selection is the control plane.

Fabric already gives agents multiple execution paths

This is where the happy-path demos hide the hard part.

Fabric gives agents a broad set of valid routes:

Semantic models
Lakehouses
Warehouses
KQL databases
Notebooks
External sources

That is a great platform story. It is also multiple opportunities to answer the same question through different semantics and controls.

Every additional route creates three immediate problems:

More ways to bypass shared business definitions
More variance in security enforcement
More difficulty proving how an answer was produced

That is why routing is not an implementation detail. It is architecture.

Here is the simplest version of the policy pattern I want to see before broad rollout: evaluate the question, classify the allowed route, and block anything outside policy.

What matters is the first branch: not “what can the agent do?” but “what path is approved?”

The semantic layer has to stay authoritative

If consistency matters, the semantic layer cannot be optional.

Fabric IQ’s ontology direction is promising because it pushes toward shared business meaning across domains and OneLake sources. But if an agent is free to answer outside that layer whenever it wants, then the semantic layer becomes advisory, not governed.

That is the failure mode I care about most:

Path A uses a semantic model with certified measures
Path B uses direct SQL over warehouse tables
Both answers look plausible
Only one honors the agreed business definition

My opinion is simple: for business metrics, the routing hierarchy should default to semantic model first, ontology-backed meaning where available, and direct engine access only by approved exception.

A lightweight classifier is enough to prove the pattern:

# Policy prototype: classify a question into an approved execution path
from dataclasses import dataclass

@dataclass
class RequestContext:
    user: str
    question: str
    has_exception: bool = False
    needs_external: bool = False

def classify_request(ctx: RequestContext) -> str:
    q = ctx.question.lower()
    if ctx.needs_external or "external api" in q or "internet" in q:
        return "deny_external_access"
    if any(term in q for term in ["raw sql", "kql", "spark sql", "warehouse table"]):
        return "direct_engine_by_exception" if ctx.has_exception else "semantic_model_first"
    return "semantic_model_first"

ctx = RequestContext(user="analyst@contoso.com", question="Compare sales by region from the semantic model")
print(classify_request(ctx))

What to notice: “raw SQL” or “KQL” does not automatically win. The classifier pushes those requests into exception handling unless policy says otherwise.

The 3 hidden risks of ungoverned Fabric agents

1. Security

Microsoft already treats some agent actions as governed egress decisions. When outbound access protection is enabled, external calls are governed by workspace data connection rules.

That same mindset should apply internally. Route choice changes least-privilege assumptions:

A semantic model may enforce business-friendly abstractions and security semantics
A direct warehouse query may expose lower-level objects and broader joins
A notebook path may introduce transformation logic and intermediate artifacts
An external call adds exfiltration and third-party dependency risk

2. Lineage

Agentic analytics makes auditability harder because the answer may come from generated SQL, a semantic query, a notebook, or a chain of tools.

If you cannot answer these questions, you do not have governed agent analytics:

Who asked the question?
Which engine answered it?
Which source was used?
Was a semantic layer involved?
What policy decision approved the route?
What fallback happened if the preferred route failed?

3. Cost

The wrong route can be technically correct and still be operationally wrong.

I have seen agents choose expensive paths because prompt wording nudged them there:

Direct engine queries against large warehouse tables instead of a curated model
Notebook execution for questions that should have been satisfied by a measure
Repeated exploratory queries during peak hours
External enrichment calls that added latency for no business value

If the semantic model can answer the question in 2 seconds with certified logic, letting the agent generate raw SQL over a broader surface is not flexibility. It is waste.

A governance-first operating model

This is the model I would put in front of a serious Fabric steering committee.

1. Define a routing hierarchy

Start with:

Semantic model first for business metrics and standard analytics
Ontology-backed definitions where shared business vocabulary exists
Direct engine access only by approved exception
Notebook execution only for bounded analytical workflows
External access denied by default unless explicitly approved

2. Make fallback behavior explicit

If the preferred semantic path fails, what happens?

Retry?
Route to a lower-level engine?
Return a governed “cannot answer” message?

Do not leave this to model improvisation.

3. Bind exceptions to scope and time

If a team needs direct SQL or KQL access, tie it to:

Named use case
Approved owner
Narrow source scope
Review date
Logging requirements

4. Require answer provenance

Every response should be able to surface:

Source used
Engine used
Semantic layer yes/no
Policy decision
Timestamp
Exception ID if applicable

5. Review route telemetry monthly

Not prompts. Routes.

Look for:

Rising direct-engine usage
New external access patterns
Slowest paths
Most frequent fallbacks
Highest-cost workloads

What leaders should insist on before broad rollout

If you are signing off on Fabric data agents, insist on four things before scale:

Approved query-path policies
Least-privilege defaults
Documented fallback behavior
Measurable answer provenance

And if you are the architect, stop framing query-language selection as prompt engineering. It is governance architecture.

My bottom line is straightforward: agent autonomy is useful only when the organization can prove which path was taken, why it was taken, and what controls applied on that path.

Anything less gives you inconsistent answers, audit pain, and avoidable cost drift dressed up as AI innovation.

Rate your team’s current query-routing governance from 1 to 5. If it is below 4, where exactly does it break: semantic authority, exception control, or observability?

#MicrosoftFabric #Datagovernance #EnterpriseAI

Sources & References

Try it yourself

Run this tutorial as a Jupyter notebook: Download runbook.ipynb (40 cells, 36 KB).