Fabric Data Agent Governance and Query Context

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

Frank Garofalo

10 Jul 2026 — 10 min read

Fabric data agents move governance into the control plane. The flashy part is conversational UX, but the real architectural shift is that software now decides how your question gets asked.

That matters more than most teams want to admit.

Microsoft has introduced Fabric data agents as a feature (currently in preview) for building conversational Q&A over enterprise data. Useful? Absolutely. But the governance catch is the big story: once an agent can choose between a semantic model, a KQL database, OneLake data, or an external source, your job is no longer just securing data assets. Your job is governing the decision logic that selects the path.

I’m bullish on this capability. I’m also blunt about the operating model: if you treat Fabric data agents like a chat feature, you will create answer inconsistency, lineage confusion, and audit headaches in record time.

The real story is not query convenience

The easy narrative is “users can ask questions in natural language and get answers faster.” Fine. That’s true, and it’s the least interesting part.

The real issue is delegation.

A Fabric data agent can answer questions across structured and unstructured data, semantic models, KQL databases, OneLake, and external sources per the Fabric docs. That means one business question can have multiple technically valid execution paths. The user sees one prompt box. Under the covers, the platform may choose very different semantics, security boundaries, and observability surfaces.

That is a governance boundary shift.

In Q1, I worked with a 14-person analytics team that had a clean Power BI semantic model for revenue, a separate KQL store for order events, and a pile of CSV snapshots in OneLake; the first agent pilot answered “What did we sell yesterday?” three different ways in the same week because each path encoded “sale” differently. Nobody had a model problem. They had a control-plane problem.

If answer trust depends on how the agent chooses where to ask, then routing logic is part of the governed system. Full stop.

Why Fabric makes this governance question unavoidable

Microsoft is not hiding the ball here. Fabric data agents are designed to work across OneLake data, semantic models, KQL databases, and external sources including Azure AI Search and Microsoft Graph as documented here. Fabric also positions Copilot experiences around working in the context that best fits the workflow. That flexibility is the product value.

It is also the governance challenge.

A single user intent can map to:

DAX over a semantic model for curated business metrics
KQL over operational telemetry for event-heavy analysis
Direct OneLake access for files or tables
External retrieval for systems that sit outside your core analytics estate

Every one of those contexts has different failure modes.

When I run this in my home lab, I think about it the same way I think about traffic routing between Proxmox-hosted services and Azure: the packet path is part of the design. Same principle here. The query path is part of the governance design.

This is why I keep coming back to the same point I made in Fabric Data Agent API Turns Governance Into Product Design: the agent is not just another consumer of data. It is a policy-bearing execution surface.

Context-aware query choice changes the control plane

Here’s the mental model I want CDOs, platform leads, and governance teams to adopt:

The governed object is no longer only the dataset, lakehouse, report, or KQL database. The governed object is also the policy that determines which of those gets used for a given class of question.

That sounds abstract until you draw it.

What to notice: the same natural-language prompt can branch into DAX, KQL, or an external call, and each branch needs its own policy checks before you can call the answer trustworthy.

Now add permissions. Microsoft states that data source access for a Fabric data agent is governed by item permissions and by the permissions of the user asking the question in the product guidance. Good. That gives you inherited enforcement. But inherited enforcement is not enough if the agent can choose among sources with different semantics and different egress rules.

External access is where teams usually get sloppy. It’s critical to consider how outbound calls from a data agent to external data sources are governed, likely through mechanisms like workspace data connection rules, and how requests to services like Microsoft Graph may be affected by outbound access protections. The practical point is the same: routing decisions can cross governance domains. One prompt may stay inside a semantic model. The next may trigger external retrieval.

That is not a data-plane-only concern. That is control-plane design.

If you want a parallel, I made the same argument in Azure Functions Just Redefined the Agent Control Plane. The mechanism changes, but the principle doesn’t: once software decides execution path, governance has to wrap the decision, not just the destination.

The trust problem is semantic before it is technical

Most bad agent answers in the enterprise are blamed on the model. That’s lazy analysis.

A lot of “hallucination” complaints are really semantic inconsistency. The agent picked a source that answered the words in the prompt but not the business meaning behind the prompt.

That’s why Fabric IQ matters here. Microsoft’s positioning is clear: Fabric IQ is part of Microsoft IQ, an enterprise intelligence layer, and the ontology capability represents enterprise vocabulary and a semantic layer that unifies meaning across domains and OneLake sources per the overview. Good. That is exactly where this needs to go.

My opinion is simple: semantic models, ontology, and business vocabulary are not optional metadata side quests if agents are going to choose query paths safely. They are the guardrails that tell the platform what “revenue,” “active customer,” “shipment,” or “incident” actually means.

Without that, context-aware query selection becomes a coin flip with a nice UI.

So here’s the rule I’d enforce:

Business metric questions should prefer certified semantic models.
Operational event questions can route to KQL if the question truly needs event grain or time-series behavior.
File- and document-heavy retrieval should stay constrained to approved OneLake or external retrieval paths with explicit egress rules.
External systems should be last-mile enrichment, not the default answer path for core KPI questions.

That hierarchy cuts down ambiguity fast.

Four failure modes leaders should expect

You don’t need to wait for a postmortem. These are the four problems that show up first.

1. Inconsistent answers

The same prompt gets different answers depending on whether the agent lands on a semantic model, KQL database, or raw source. This is the most damaging failure because executives experience it as “the AI is unreliable.”

2. Opaque execution paths

Users get a polished natural-language answer and have no idea whether it came from a curated semantic layer or a direct source. That destroys explainability.

3. Policy drift

Sensitivity labels, source permissions, outbound connection rules, and endorsement status drift across the possible paths. The agent inherits controls, but the controls are not harmonized.

4. Audit gaps

Yes, Fabric supports auditing and monitoring through activity logs and capacity metrics. That’s necessary. It is not sufficient. You still need an operating standard that ties together:

user intent
selected execution context
policy set applied
answer returned
evidence retained

This is why How AI agent observability should influence Fabric data product design is not an observability-only conversation. It is governance plumbing.

Purview, semantic models, and data-product ownership are the real enablers

The teams that will get this right are not the teams with the cleverest prompts. They’re the teams with the cleanest ownership model.

Fabric data agents support governance features including inherited sensitivity labels from data sources and Microsoft Purview Information Protection labels on agent responses according to Microsoft. That is exactly the kind of policy continuity you want. But labels only help if the underlying source landscape is disciplined.

My recommendation is opinionated and practical:

Treat semantic models as the preferred governed interface

If the question is about business performance, route to a certified semantic model first. That gives you reusable definitions, established security boundaries, and a better chance of consistent answers.

Treat direct source access as an exception path

KQL, raw lake data, and external sources are powerful. They should be used because the question demands that context, not because nobody bothered to curate the business layer.

Put data-product owners on the hook

Every agent-eligible source should have:

a named owner
documented business definitions
label posture
review cadence
allowed question classes
approved execution contexts

If nobody owns whether a source is safe for agent routing, then it is not safe for agent routing.

What I would standardize now

This is the hands-on part. If you’re running Fabric or planning to, here’s the governance starter pack I’d put in place this quarter.

1. Build an agent dependency inventory

Start embarrassingly simple. Enumerate each agent and classify what it can hit: semantic models, KQL databases, and external sources.

# Build a small dependency inventory for Fabric data agents and classify governance controls.
from dataclasses import dataclass, asdict
import json

@dataclass
class Dependency:
    agent: str
    kind: str
    name: str
    workspace: str
    control_family: str

deps = [
    Dependency("SalesCopilot", "semantic_model", "RevenueModel", "Finance", "RLS+Sensitivity"),
    Dependency("OpsAnalyst", "kql_database", "PlantTelemetry", "Operations", "Retention+Access"),
    Dependency("VendorRisk", "external_source", "ServiceNowAPI", "Risk", "Connector+Egress"),
]

print(json.dumps([asdict(d) for d in deps], indent=2))

What to do next: turn this into a review artifact. If you can’t list an agent’s dependencies in a small JSON or CSV, you do not understand its governance surface.

2. Emit a review-ready CSV for control mapping

Once you have dependencies, map each dependency type to the review focus. This is the minimum viable governance inventory I’d hand to an architecture review board.

# Inventory agent dependencies and emit a governance review CSV for audit preparation.
import csv

agents = [
    {"agent": "SalesCopilot", "semantic_models": ["RevenueModel"], "kql_databases": [], "external_sources": ["SAP"]},
    {"agent": "OpsAnalyst", "semantic_models": [], "kql_databases": ["PlantTelemetry"], "external_sources": []},
]

rows = []
for a in agents:
    for model in a["semantic_models"]:
        rows.append([a["agent"], "semantic_model", model, "Validate RLS, sensitivity labels, endorsements"])
    for kql in a["kql_databases"]:
        rows.append([a["agent"], "kql_database", kql, "Validate retention, RBAC, query scope"])
    for src in a["external_sources"]:
        rows.append([a["agent"], "external_source", src, "Validate approved connector, secrets, egress"])

with open("fabric_agent_governance_inventory.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.writer(f)
    writer.writerow(["agent", "dependency_type", "dependency_name", "review_focus"])
    writer.writerows(rows)

print("Wrote fabric_agent_governance_inventory.csv")

What to observe: each dependency type implies a different control family. Don’t review a semantic model, KQL database, and external API with the same checklist.

3. Score risk by query context

Not all contexts deserve the same review depth. I like a lightweight scoring approach because it forces prioritization.

# Score governance risk by query-language context to prioritize review depth.
contexts = [
    {"agent": "SalesCopilot", "query_language": "DAX", "asset": "RevenueModel", "sensitivity": "High"},
    {"agent": "OpsAnalyst", "query_language": "KQL", "asset": "PlantTelemetry", "sensitivity": "Medium"},
    {"agent": "VendorRisk", "query_language": "External", "asset": "ServiceNowAPI", "sensitivity": "High"},
]

base = {"DAX": 2, "KQL": 3, "External": 4}
boost = {"Low": 0, "Medium": 1, "High": 2}

for c in contexts:
    score = base[c["query_language"]] + boost[c["sensitivity"]]
    print(f"{c['agent']}: {c['query_language']} on {c['asset']} => risk_score={score}")

What to do next: use the score to decide review cadence. High-sensitivity external retrieval should get more scrutiny than a low-risk semantic model over certified finance data.

4. Package evidence for audit before someone asks for it

If you wait for Legal, Internal Audit, or a regulator to ask how an agent answered a sensitive question, you are already late.

# Produce a compact audit evidence package as JSON for governance reviewers.
import json

evidence = {
    "review_name": "Fabric Data Agent Query Context Review",
    "controls": {
        "semantic_model": ["RLS enforced", "Sensitivity labels present", "Certified or endorsed"],
        "kql_database": ["RBAC validated", "Retention configured", "Cross-cluster access reviewed"],
        "external_source": ["Approved connector", "Secret management", "Outbound egress approved"],
    },
    "agents_reviewed": ["SalesCopilot", "OpsAnalyst", "VendorRisk"],
}

with open("fabric_agent_evidence.json", "w", encoding="utf-8") as f:
    json.dump(evidence, f, indent=2)

print("Wrote fabric_agent_evidence.json")

What to observe: this is not production automation. It is a pattern for assembling evidence around the control families that matter.

5. Check workspace and connection posture

For external access, I want a simple export of workspace governance settings and connection posture. This is where teams discover the ugly stuff: unmanaged identities, weak secret handling, or inconsistent egress posture.

# Export workspace governance settings relevant to Fabric data agent reviews.
$workspaces = @(
    [pscustomobject]@{ Name = "Finance"; Capacity = "F64"; SensitivityLabels = $true; ManagedIdentity = $true },
    [pscustomobject]@{ Name = "Operations"; Capacity = "F32"; SensitivityLabels = $true; ManagedIdentity = $false }
)

$workspaces |
    Select-Object Name, Capacity, SensitivityLabels, ManagedIdentity |
    Export-Csv -Path ".\workspace-governance-settings.csv" -NoTypeInformation

Write-Host "Exported workspace-governance-settings.csv"

Then validate connection-rule posture for external sources used by agents.

# Report connection-rule posture for external sources used by data agents.
$connections = @(
    [pscustomobject]@{ Agent = "VendorRisk"; Source = "ServiceNowAPI"; ApprovedConnector = $true; PrivateLink = $false; SecretStore = "KeyVault" },
    [pscustomobject]@{ Agent = "SalesCopilot"; Source = "SAP"; ApprovedConnector = $true; PrivateLink = $true; SecretStore = "KeyVault" }
)

$connections | ForEach-Object {
    $_ | Add-Member -NotePropertyName Posture -NotePropertyValue (
        if ($_.ApprovedConnector -and $_.SecretStore -eq "KeyVault") { "ReviewReady" } else { "NeedsAttention" }
    )
    $_
} | Export-Csv -Path ".\connection-rule-posture.csv" -NoTypeInformation

Write-Host "Exported connection-rule-posture.csv"

What to do next: review anything that is not clearly “ReviewReady” before expanding agent scope.

6. Tie activity references back to governance review

You need a lightweight trail that connects operations to governance evidence.

# Export activity-log references that support a governance review trail.
$activity = @(
    [pscustomobject]@{ Time = "2025-07-10T09:00:00Z"; Workspace = "Finance"; Operation = "DataAgentQuery"; ReferenceId = "evt-1001" },
    [pscustomobject]@{ Time = "2025-07-10T09:05:00Z"; Workspace = "Operations"; Operation = "ConnectionAccess"; ReferenceId = "evt-1002" }
)

$activity |
    Select-Object Time, Workspace, Operation, ReferenceId |
    Export-Csv -Path ".\activity-log-references.csv" -NoTypeInformation

Write-Host "Exported activity-log-references.csv"

If you want a compact admin summary for review meetings, join the exports.

# Join workspace, connection, and activity exports into a lightweight admin summary.
$workspaceRows = Import-Csv ".\workspace-governance-settings.csv"
$connectionRows = Import-Csv ".\connection-rule-posture.csv"
$activityRows = Import-Csv ".\activity-log-references.csv"

$summary = [pscustomobject]@{
    WorkspaceCount = $workspaceRows.Count
    ConnectionCount = $connectionRows.Count
    ReviewReadyConnections = ($connectionRows | Where-Object { $_.Posture -eq "ReviewReady" }).Count
    ActivityReferenceCount = $activityRows.Count
}

$summary | ConvertTo-Json

What to observe: this gives you a basic operating picture across workspaces, connections, and activity references. Not glamorous. Very useful.

A practical governance stance for the next 12 months

Don’t freeze adoption. Don’t wave it through either.

The right move is controlled expansion inside a hard governance envelope.

My playbook looks like this:

Approve a hierarchy of query contexts.

- Semantic model first for business questions - KQL for operational/event questions - OneLake direct access only for approved scenarios - External retrieval only with explicit connection-rule approval

Require source-to-answer lineage expectations.

Every agent interaction should be explainable in terms of source, context, and policy path.

Certify agent-eligible data products.

Ownership, definitions, labels, and review cadence are table stakes.

Govern outbound access like a first-class architecture decision.

External source routing is not a connector checkbox. It is an egress policy decision.

Review decision paths, not just usage volume.

The question is not “How many prompts did users send?” The question is “Which paths did the agent take, under which policies, and were those paths the right ones?”

That’s the center of gravity now. Fabric data agents should be governed as a control-plane capability because context-aware query choice changes where policy, lineage, semantic consistency, and auditability must be enforced.

If you only govern the data the agent can reach, you’re governing yesterday’s problem.

Rate your team’s current state on agent query-path governance from 1 to 5: are you governing only access, or are you governing the routing decision too?

#MicrosoftFabric #Datagovernance #EnterpriseAI

Sources & References

Try it yourself

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