Must an agent modify data or send tickets to be valuable? Fabric Data Agent takes a narrower position: it generates and executes read-only SQL, DAX, and KQL, leaving cross-system writes to external orchestration.
Identity comes before querying
Data access runs under the user’s Microsoft Entra ID and source permissions. Seeing a schema does not grant permission to read its data. Power BI semantic models remain subject to Read permission, RLS, and CLS. Enforcement stays in the data platform rather than in prompt instructions.
Assets route to different query languages
Lakehouse, Warehouse, and SQL Database use SQL; Power BI semantic models use DAX; Eventhouse/KQL Database uses KQL. An agent can combine source types, but language routing does not resolve cross-source definitions, grain, or time alignment.
What read-only reduces
The agent does not create, update, or delete data, and it does not trigger notebooks or action workflows from Eventhouse. That reduces the blast radius of a mistake and makes the analytical component easier to embed in broader orchestration.
Read-only is not synonymous with safe or correct. A bad query can still mislead, excessive permission can still expose data, and Purview DLP may truncate or block results. Chat response limits also make the experience unsuitable as a complete-data export path.
Three production checks
Verify the user’s effective permission on every source, not merely the workspace role. Provide example queries and semantic instructions for important questions, and retain generated queries for review. Finally, separate an analytical recommendation from a business action: any external agent writing back to a system must re-authorize the target, parameters, and recipient.
Fabric’s design shows that one agent does not need to own every action in a loop. A governed read-only analytical component plus explicit write orchestration is often easier to audit than one model holding unrestricted tools.
References: Fabric data agent concepts, Create a Fabric data agent