Microsoft Fabric Data Agent Governance: From POC to Production
In Part 1, we discussed — Who can access what? Click Here to read Part 1 We looked at identity, source permissions, RLS, CLS, OLS, query-path security, and why AI instructions should never become the authorization layer. But a Data Agent can be perfectly secure and still be poorly governed. Once we move from a POC into production, a different set of questions appears: Who can modify the agent? Which identity is used when the agent is called from another application? How do we test an instruction change before releasing it? What changes when Code Interpreter is enabled? Where does conversation history live? What happens when the Data Agent leaves Fabric? That is where the conversation moves from security into governance. Security and Governance Are Not the Same Thing SECURITY Who can access the agent and the data? What rows, columns, or objects can they see? GOVERNANCE Who can change the agent? How are changes tested and quality measured? Which runtime is used? Where is conversation data stored? How is the agent consumed outside Fabric? Security defines the boundary. Governance controls how the system is operated inside that boundary. Both are required for production. Fig. Security Vs Governance Code Interpreter Introduces Another Execution Surface The normal Data Agent source-query path (SQL, DAX, KQL) is read-oriented, so a prompt like "Delete all customers with zero revenue" doesn't turn the agent into a database administrator. But there is a nuance: Fabric Data Agent can optionally use Code Interpreter, which generates and executes Python in a Microsoft-managed sandbox for statistics, transformations, and charts. Underlying source │ Governed retrieval ▼ Fabric Data Agent │ ▼ Sandboxed Python execution │ ▼ Calculated / transformed / visualized result The source-query path remains governed and read-oriented, while Code Interpreter introduces an additional analytical execution environment. Rather than treating the word "sandbox" as sufficient evidence, we tested the execution path directly. What We Observed in Our POC Governed data was retrieved before Python executed. For "Total Sales by Region", the Run Steps showed the semantic model queried with DAX first. The authorized result was saved as a local JSON file under /mnt/data and then read by pandas. Code Interpreter was not independently querying the model. The sandbox could create local artifacts. Generated Python wrote files such as CSV and TXT into /mnt/data, and the Run Steps exposed the code used. Artifacts persisted across chats for the same user. A file created in one chat was still visible in a new chat. We do not infer a retention period from this; the lifetime remains unknown. A second user did not see the first user's artifact. User B enumerated files and found only their own test file. This is POC evidence consistent with user-level isolation in our environment, not a universal guarantee. Runtime details were visible, but sensitive introspection was constrained. Python version, OS, and package versions were exposed, but a request for environment-variable names was refused before execution. Outbound internet was treated as disabled. A requested HTTPS call was not issued and the environment reported internet access as disabled. Since no connection was attempted, this is not packet-level verification of a network block. A controlled Python error exposed nothing sensitive. Referencing a nonexistent column returned only a KeyError, with no credentials, connection strings, or unrelated file contents. Fig. Run Step showing the DAX query and generated Python reading the result file Fig. Same-user artifact persistence across chats Fig. New chat shows file exists. Fig. In our test, User B could enumerate their own isolation artifact but not User A’s artifact. Fig. Area of observations These are POC observations, not universal guarantees. For production, treat Code Interpreter as its own governed execution surface and ask: What data reaches Python? What code is generated? What artifacts persist, and for how long? Are users isolated? What can the environment reach? What appears in errors? Read-only source access does not mean there is only one execution surface. The Calling Identity Becomes Critical Outside Fabric Inside Fabric, identity is easy to reason about. A published Data Agent can also be called by custom applications, MCP clients, and automation, each with a different identity path. One architecture question should always be documented: Whose identity ultimately reaches Fabric? Service principals suit automation, CI/CD, and background processing, but they carry their own permissions. If User A, B, and C all reach the agent through one shared service principal, the platform evaluates that single identity, not each user's entitlements. For interactive apps where per-user entitlements matter, a delegated (on-behalf-of) identity is usually easier to reason about. Neither is universally better: The identity model must be intentional. Fig. Calling Identity Governance Starts Before the Agent Is Published Who can change the Data Agent is almost as important as who can use it. Creators work in a draft version (schema, instructions, examples, sources); consumers use the published version. A normal consumer shouldn't need edit rights to a definition like "Revenue means Net Revenue excluding intercompany" just to ask "What was revenue last month?" Separate four responsibilities: consume, inspect, edit, publish. Treat Data Agent Configuration Like Code Once instructions define business behavior, changing them is a production change. "Change instruction, save, hope nothing broke" is not a governance process. A stronger lifecycle: Development → Source control → Peer review → Test workspace → Regression validation → Production → Publish You should be able to answer who changed an instruction, what changed, which version was tested, and which version is running in production. Fig. Lifecycle Standard vs. Preview Runtime Is a Governance Decision A POC may use Preview capabilities for newer functionality; production may prefer the stable path. But even a standard runtime doesn't mean the underlying AI stack stays frozen. "We tested it once" is not a strategy, so regression testing has to become part of normal operation. Security Is Not the Same as Accuracy A response can be perfectly secure and still wrong. For "What did we spend on marketing last quarter?", an authorized user still depends on the agent interpreting "spend", "last quarter", which accounts count as marketing, and which source is authoritative. Production governance needs two questions: Was this user allowed to see the answer? and Was the answer actually correct? Native Evaluation Should Be Part of the Release Process "We asked five questions and the answers looked okay" is not a release gate. Maintain expected-answer test cases and run them on every change. A good set includes core KPIs, time-intelligence questions, synonym variations, ambiguous prompts, cross-source questions, restricted-data questions, expected failures, and known edge cases. When something fails, Run Steps help locate the divergence: wrong source, wrong query, wrong business interpretation, or a misleading explanation. Instead of "the AI got it wrong", ask where did the execution path diverge from what we expected? Fig. Security vs. Quality Evaluation Conversation History, Residency, and Networking Conversation history is part of the data estate. A prompt like "Why is revenue falling for Customer ABC while we negotiate their confidential renewal?" may be more sensitive than the result. Decide what users may enter, how long context persists, and who can investigate interactions. Data residency needs an explicit decision. Document more than where the capacity lives: where AI processing occurs, where conversation history and telemetry are stored, and where downstream applications process the response. Networking must be evaluated per source. Private Link (how do we privately reach a resource?) and Outbound Access Protection (which destinations may this workspace call?) solve different problems, and not every source follows the same path. As in Part 1: validate the actual path, not just the existence of a security feature. Fig. Conversation History, Data Residency, Networking What Happens When the Data Agent Leaves Fabric? A Data Agent can be used through Microsoft Foundry, Copilot Studio, Microsoft 365 Copilot, MCP clients, and custom applications. Once the response leaves Fabric, the receiving service brings its own identity model, retention policy, logging, compliance boundary, and geography. "Secure inside Fabric" does not mean "secure everywhere downstream." The same applies to identity. If the application calls Fabric as the user, the user's permissions apply. If it calls as a shared or maker identity, answers reflect that identity's permissions instead. The second pattern may be intentional, but it must be documented as a security and governance decision. Fig. When the Data Agent Leaves Fabric A Production Governance Model IDENTITY → AUTHORIZATION → DATA SECURITY → QUERY-PATH SECURITY → AI SCOPE → SEMANTIC GOVERNANCE → EXECUTION GOVERNANCE → QUALITY GOVERNANCE → LIFECYCLE GOVERNANCE → FABRIC DATA AGENT Part 1 covered the upper security layers. Part 2 adds the controls needed to operate the agent as a production analytical product. Fig. Data Agent Ready for Production Before Production, I Would Review These Areas Identity: confirm which identity reaches Fabric; document user, delegated, and service-principal paths separately. Data security and scope: validate RLS/CLS/OLS with real restricted identities on every query path; expose only the sources and fields required. Execution: document the runtime; review Code Interpreter separately (data passed to Python, artifact persistence, isolation, network limits). Quality: maintain expected-answer tests; regression-test critical questions. Lifecycle: separate consumers from creators; use draft and published versions; promote through Dev, Test, and Production; version instructions. Privacy, residency, network: define prompt rules, document AI processing and telemetry locations, review Private Link per source. External consumption: re-run the review for every channel and confirm the effective identity for each. Governance Still Does Not Tell Us What Happened The agent may now be secure and well governed, but production still raises questions: Who asked what? What did the agent answer? Which source did it choose? Where did execution fail? Can compliance investigate an interaction? These map to three disciplines: Audit (who asked what, and what was answered), Trace (how a request executed), and Observe (whether the agent is healthy in production). Next: Part 3 — Auditing, Tracing and Observing Microsoft Fabric Data Agents in Production Part 3 will combine Microsoft Purview, DSPM for AI, Microsoft Foundry, Application Insights, Fabric diagnostics, capacity telemetry, and MCP/application telemetry to answer not just what the Data Agent is allowed to do, but what it actually did. That is where security and governance turn into operational accountability. Related Reading Part 1 — Microsoft Fabric Data Agent Security: What Actually Protects Your Data? Building a Better Microsoft Fabric Data Agent: Instructions, Visual Policy, and Cost-Aware Design Building and Enriching a Microsoft Fabric Data Agent on a Power BI Semantic ModelMicrosoft Fabric Data Agent Security: What Actually Protects Your Data?
Most Microsoft Fabric Data Agent demos begin the same way: connect a semantic model, Lakehouse, or Warehouse, add some instructions, ask a natural-language question, and get an answer. That's the exciting part. But the moment we move from a demo to a real enterprise implementation, the questions change: Whose identity is actually querying the data? Does sharing the Data Agent also share the underlying data? Can the agent bypass RLS or CLS? Does Object-Level Security still protect metadata? What happens if the same data is reachable through multiple query paths? These are the questions we set out to answer during our Fabric Data Agent POC. The most important principle that came out of it was surprisingly simple: The Fabric Data Agent should not be your security layer. Your data platform should be. That one principle makes the rest of the architecture much easier to reason about. A Data Agent Does Not Get Unlimited Access to Fabric When someone uses a Fabric Data Agent directly in Fabric, the interaction normally runs in the context of the authenticated Microsoft Entra ID user. Fabric manages the underlying Azure OpenAI service, so users don't need to supply an OpenAI API key, and the Data Agent doesn't suddenly receive unrestricted access to every table in the workspace. When the agent needs data, it generates the appropriate SQL, DAX, or KQL and queries the underlying source using the permissions available to the calling identity. Fig. Security Path The important part is the middle: the agent generates the query, but the data platform decides whether that query can return the requested data. That is exactly where enterprise security should live. Sharing a Data Agent Does Not Mean Sharing the Data There are effectively two authorization checks: Can the user access the Data Agent itself? Can the user access the underlying data source? Fig. Two Authorization Checks Fabric doesn't elevate a user's access just because a Data Agent has been shared with them. Users still need the applicable permissions on the underlying source. Queries that touch data they can't access can fail authorization or return no data, depending on the source and its security model. This separation is critical for enterprise deployments: you can distribute one common analytical assistant while still preserving different data entitlements for Finance, Sales, Operations, or regional teams. Semantic Models Have an Interesting Permission Model Power BI semantic models are especially interesting here. Microsoft documents that a consumer can query a semantic model through a Data Agent with Read permission. They don't need: Workspace Member Workspace Contributor Build permission Write permission simply to ask questions through the Data Agent. (Build or Write permissions remain relevant when someone needs to modify the model or use capabilities that change its AI configuration, such as Prep for AI.) From a least-privilege perspective, this is a very useful improvement. Instead of granting broad workspace or semantic-model permissions just because somebody needs conversational analytics, you can grant only the narrower access required for consumption. What Happens to RLS and CLS? This is probably the security question that comes up most often around conversational analytics: "If the AI generates the query, can it somehow bypass RLS?" For supported Data Agent interactions, Microsoft explicitly documents that existing user permissions continue to apply, including Row-Level Security (RLS) and Column-Level Security (CLS). Fig. RLS — One Agent Three Users All three users can use the same published Data Agent, yet the semantic model can return different populations because the security context belongs to the user. The agent doesn't need instructions like: If User = John, only show Europe. In fact, that would be the wrong way to implement security. The model should enforce the rule. The Data Agent should operate inside it. What About OLS? We tested Object-Level Security (OLS) rather than assuming how the Data Agent would behave. In our model, we applied OLS to Customer[Company Name] in the Power BI semantic model and tested the Data Agent using the restricted identity. We then asked: "Show Total Sales by Company Name." Fig. Data Agent does not expose the OLS-protected Company Name field. The Data Agent responded that the model does not contain a Company Name field and suggested Customer Name instead. Fig. Run Steps show the semantic model was analyzed, but the protected field was unavailable to the agent. That was the key result. Company Name still physically exists in the semantic model, but for the OLS-restricted user, the Data Agent behaved as though the field didn't exist. In our tested path, OLS protected not only the data but also the object's metadata. Our test confirmed OLS enforcement for the tested Fabric Data Agent → Power BI semantic model path, including metadata hiding. There's an important qualification: this remains query-path specific. If the same underlying data is also exposed through a Lakehouse, Warehouse, SQL endpoint, or another source, that route needs its own security controls. Fig. OLS security Security Is Specific to the Query Path This is one of the broader lessons from our POC. Imagine the same business data can be reached through: Power BI Semantic Model │ └── RLS / CLS / OLS Lakehouse │ └── OneLake / item security Warehouse │ └── SQL / OneLake permissions Securing one route doesn't automatically prove that all the others are equally secure. The semantic model could correctly restrict a user's data through RLS or OLS while the same user has broader access to the underlying Lakehouse. If both are available to the Data Agent, the overall architecture may still be over-permissioned. So the enterprise question isn't simply "Does my semantic model have RLS?" It's: Is every query path available to this Data Agent secured for this identity? Fig. Security Is Specific to the Query Path AI Instructions Are Not Security Policies Consider an instruction like: Never display employee salary information. That may be useful behavioral guidance, but it is not an authorization boundary. A user could phrase the question differently. The orchestration could change. A future runtime could interpret an instruction differently. The instruction could be accidentally edited or removed. The secure implementation puts the control in the data platform (RLS/CLS/OLS and source permissions), with instructions layered on top for behavior. Fig. AI Instructions Are Not Security Policies The distinction is simple: Instructions determine how the agent should behave. Permissions determine what the agent is allowed to see. Never reverse those responsibilities. Reduce the Agent's Data Surface Security isn't only about identity — it's also about how much data you expose to the agent in the first place. When configuring a Data Agent, creators select relevant sources, tables, and schema context. For an enterprise Finance Data Agent, exposing: Dim Date Dim Account Dim Cost Center Fact Actuals Fact Forecast is usually better than exposing hundreds of unrelated HR, customer, and operational tables. It helps in two ways: it reduces unnecessary exposure, and it improves query generation because the agent has fewer irrelevant paths to reason through. But schema selection still isn't authorization. Fig. Three Boundaries Data Agent Querying Is Read-Oriented — With an Important Nuance The normal Data Agent source-query path is designed for analytical retrieval. Its SQL, DAX, and KQL tools retrieve and analyze data rather than modify the underlying source. So a prompt like: Delete all customers with zero revenue. doesn't turn the Data Agent into a transactional database administrator. That lowers risk significantly compared with giving an autonomous agent unrestricted write-capable database tools. But there's a nuance. Code Interpreter Changes the Execution Surface Fabric Data Agent can optionally use Code Interpreter (currently in Preview), which generates and executes Python in a Microsoft-managed sandbox for tasks such as statistics, advanced calculations, data transformation, visualization, and analytical processing. That does not make the underlying source write-enabled. A better mental model: Underlying Source │ │ Governed read ▼ Fabric Data Agent │ ▼ Sandboxed Python │ ▼ Calculated / visualized result Fig. Code Interpreter Surface Source querying remains governed and read-oriented, while Code Interpreter adds an additional analytical execution environment. That extra execution surface should be reviewed deliberately, especially when considering Preview capabilities for sensitive production workloads. Discussed in Part 2 with detailed analysis. Check Out. What We Took Away From the Security POC The cleanest security model for us became: IDENTITY Microsoft Entra ID ↓ AUTHORIZATION Fabric item + source permissions ↓ DATA SECURITY RLS / CLS / OLS / OneLake / SQL ↓ QUERY-PATH SECURITY Validate each available source ↓ AI SCOPE Selected schema ↓ FABRIC DATA AGENT The Data Agent sits on top of the security architecture. It should not replace it. That's the difference between building an impressive AI demo and building an enterprise analytical agent. Fig. Security Architecture Security Is Only the First Layer Once the basic security model is in place, a new set of questions appears: Who can modify the agent? Which runtime should production use? How do we test changes? What happens with Code Interpreter? How should service principals be handled? Where is conversation history stored? What happens when the agent is used from Copilot Studio, Foundry, MCP, or a custom application? Those are no longer just security questions — they're governance questions. Next: Part 2 — Governance, From POC to Production Part 2 focuses on how a production Data Agent should be changed, tested, released, consumed, and governed — including identity models, lifecycle management, evaluation, privacy, data residency, networking, and external consumption: Microsoft Fabric Data Agent Governance: From POC to Production. The central idea remains the same: Do not make the AI responsible for protecting the data. Make the data platform responsible for protecting the data, and make the AI operate inside those boundaries. Click Here to go to Part 2 Related Reading Building a Better Microsoft Fabric Data Agent: Instructions, Visual Policy, and Cost-Aware Design Building and Enriching a Microsoft Fabric Data Agent on a Power BI Semantic ModelDataflow Gen2 vs Copy Job vs Pipeline: Choosing by Workload, Not by Habit
Every Fabric team has a default tool. People who came from Azure Data Factory build a pipeline for everything. Power BI people open Dataflow Gen2 for everything. Newer teams might put every table into a Copy Job because the wizard is quick. Each tool does its own job very well. Problems start when it gets used for another tool's job: pipelines full of hand-built watermark logic, dataflows used only to copy tables, and Copy Jobs expected to handle transformations they were never built for. This post gives you a simple way to pick the right tool based on what the workload needs. One sentence each Copy Job moves data from A to B, including incremental loads, with as little setup as possible. Dataflow Gen2 shapes data. It cleans, merges, reshapes and applies business rules using Power Query. Pipeline coordinates work. It runs steps in order, handles dependencies and failures, and ties everything together. If you remember only one thing, remember this: Copy Job moves, Dataflow shapes, Pipeline orchestrates. Start with three questions about the workload Ask these before you open any editor. Am I moving data or changing it? If the data arrives at the destination looking mostly like the source, with only column mapping or type changes, you are moving data. If you are joining, deduplicating, deriving columns or applying business logic, you are transforming it. How does the source change? A one-time or full reload is a different problem from an ongoing incremental sync. Incremental loads based on change data capture (CDC) are different again. How many steps depend on each other? A single load on a schedule is one thing. "Load these, then validate, then transform, then run a stored procedure, then alert someone if it fails" is a workflow. Your answers usually point clearly to one tool. Copy Job: when the job is data movement Copy Job is the newest of the three and the one most often overlooked by teams stuck in old habits. Microsoft's decision guide lists its main scenarios as incremental copy and replication (both watermark-based and native CDC), data lake and storage migration, medallion ingestion, and out-of-the-box multi-table copy. Microsoft Learn The incremental support is the main reason to use it. In a pipeline, the Copy activity handles incremental copy through pipeline expressions and control tables, and only with watermarks. That means you build and maintain the control table, the lookup, the parameterized query and the watermark update yourself. Copy Job does this for you. Microsoft Learn Choose Copy Job when: You need to ingest many tables from a database into a lakehouse or warehouse. You want an initial full load followed by incremental updates, and you don't want to build watermark logic. The source supports CDC and you want inserts and updates merged into the destination automatically. The destination is outside Fabric. Copy Job supports 40+ destination connectors. Microsoft Learn Microsoft's own example fits this well: an analyst who needs multi-table selection across regional SQL Server instances, a bulk initial load, and then CDC-based incremental merges picks Copy Job because it supports both watermark-based and native CDC incremental copying through a wizard, and automatically detects CDC-enabled tables. Microsoft Learn Don't choose Copy Job when: You need real transformation. Its transformation support is rated low, and that is intentional. Microsoft Learn The load is one step in a larger workflow with conditions, retries and downstream dependencies. That belongs in a pipeline. Dataflow Gen2: when the job is shaping data Dataflow Gen2 is Power Query running at Fabric scale. It is the right tool when the value lies in the transformation logic. It offers 170+ built-in connectors, 300+ transformation functions in a visual interface, and data profiling tools for checking data quality. Microsoft Learn A common complaint is that dataflows are slow for large volumes. That used to be a fair criticism, but Fabric has added several performance features aimed at specific workloads: Fast Copy is for direct, high-throughput copies from a supported source with no transformations. It uses the same backend as the pipeline Copy activity. microsoftmicrosoft Modern Evaluator helps when you are shaping data from connectors that don't fold, or only partly fold. microsoft Partitioned Compute is for large, partitioned or multi-file datasets that can be processed in parallel. microsoft Staging lets you land raw data first and transform it afterwards (ELT), so ingestion and transformation don't compete in one pass. microsoft Choose Dataflow Gen2 when: Business logic is the main work: cleansing, standardizing codes, merging sources, calculated columns. The people who own the logic know Power Query and would struggle to maintain Spark or SQL. You are combining files, APIs, SharePoint lists and databases into one clean dataset. You want visual data profiling while you build. Don't choose Dataflow Gen2 when: You are only copying tables. Fast Copy makes this workable, but Copy Job is simpler, gives you incremental loads without extra work, and has less to maintain. Your destination isn't supported. Dataflow Gen2 lists around 7+ destination connectors, compared with 40+ for the copy tools. Microsoft Learn The transformations are very complex or code-heavy. At that point a notebook is usually the better choice. Pipeline: when the job is coordination A pipeline is not mainly a data movement tool. It is the orchestrator. Microsoft describes it as low-code orchestration that groups several activities together to complete a task. The Copy activity inside it is powerful, and it remains a strong option for very large migrations. The guide describes it as the best low-code choice for moving petabytes of data into lakehouses and warehouses, either ad hoc or on a schedule. Microsoft LearnMicrosoft Learn The real reason to use a pipeline is the control flow: dependencies, branching, retries, failure handling, parameters, and calling other items. Choose a pipeline when: Several steps must run in a set order, where step B only runs if step A succeeds. You need logic such as If/Else, ForEach over a metadata list, or waiting on an external event. You are combining different item types, such as a Copy Job, a dataflow, a notebook, a stored procedure and a web call. You need error handling and notifications around the whole process. You are doing a large, custom migration where you want detailed control over the Copy activity. Microsoft's scenario for pipelines describes a workflow that runs stored procedures, calls web APIs, moves files and executes other pipelines. That is orchestration, not simple ingestion. Microsoft Learn Don't choose a pipeline when: It would contain a single activity that just runs one dataflow on a schedule. Dataflows can be scheduled on their own. You would be rebuilding incremental loading by hand when Copy Job already supports your source. Side-by-side Copy Job Dataflow Gen2 Pipeline Main job Move and replicate Transform and shape Orchestrate Incremental loads Built in (watermark and CDC) Possible, but not its strength Manual (watermark and control tables) Transformation Low High None itself (calls other items) Destinations 40+ ~7+ Depends on activities Authoring Wizard Power Query Visual canvas and expressions Best owner Data integrator, analyst Analyst, data engineer Data engineer Warning sign you picked wrong Adding transformation workarounds Dataflow has no transformation steps Pipeline has one activity Common mistakes that come from habit The "everything is a pipeline" team. Every source table gets a Lookup, a ForEach, a parameterized Copy activity and a stored procedure to update the watermark. It works, but you now maintain a small custom framework that Copy Job gives you ready-made. Keep the pipeline and let it call the simpler pieces. The "everything is a dataflow" team. Dataflows with forty queries that just select a table and load it. Move the raw ingestion to Copy Job and keep dataflows for the layer where logic actually happens. The "Copy Job does it all" team. Trying to handle business rules with column mappings, then adding SQL views downstream to fix what should have been transformed properly. Once logic appears, add a Dataflow Gen2 or a notebook. The single-activity pipeline. A pipeline whose only purpose is to run one item on a schedule adds a layer to monitor without adding control. Use the item's own schedule until you really need dependencies. The pattern that usually wins: use all three, each for its own job For a typical medallion architecture, the tools fit together naturally: Bronze with Copy Job. Ingest source tables with built-in incremental or CDC loads. No custom watermark logic. Silver and Gold with Dataflow Gen2 (or notebooks for heavy, code-first logic). Apply cleansing, conformance and business rules where they are visible and easy to maintain. Pipeline around everything. Run ingestion, then transformation only if ingestion succeeded, then refresh or post-processing steps, and send an alert if anything fails. Each tool does what it is best at, and each is simpler because it isn't doing another tool's job. A 30-second decision checklist No transformation, and data must stay in sync over time? → Copy Job One-off or very large custom migration needing fine control? → Copy activity in a pipeline Transformation logic is the main work, and owners know Power Query? → Dataflow Gen2 Complex, code-first transformation at scale? → Notebook Multiple steps, dependencies, branching or error handling? → Pipeline, calling the tools above Closing thought The right question isn't "which tool do we use?" It is "what does this workload need?" Movement, shaping and coordination are three different problems, and Fabric gives you a dedicated tool for each. Teams that choose by workload build less custom plumbing, find problems faster, and hand solutions over more easily, because each piece does one clear job. Next time you start a new load, answer the three questions first, then pick the tool.Power BI Copilot Row Level Security: Security Test
I explored how Row Level Security (RLS) interacts with Copilot in Power BI and Microsoft Fabric—answering a common question about whether Copilot can bypass RLS restrictions. This walkthrough demonstrates practical steps for adding users, configuring permissions, and validating that security boundaries remain intact, even with AI-powered features. Organizations often worry that AI assistants like Copilot might expose data beyond intended roles. I addressed this by testing both admin and viewer experiences in a real Fabric workspace, focusing on what Copilot can summarize and display for each user. In this video: - I added a new user to my Merit Workspace with viewer-only permissions, showing the setup process. - I configured Row Level Security and explained how it applies to different users. - I tested Copilot interactions as both an admin and a restricted user, highlighting what each can access. - I examined whether Copilot respects RLS when summarizing or displaying data. - I demonstrated the classic RLS visual experience for a restricted user. - I verified that Copilot does not reveal unauthorized data categories. - I showed how RLS and Copilot work together in real Power BI scenarios.
Securing Data using Sensitivity Labels in Power BI
Data protection is very important in today's data-driven environment. To achieve this, organizations must apply specific policies and restrictions to maintain data integrity and confidentiality. In Power BI, we have data protection policies like sensitivity labels which allow organizations to classify and secure data in alignment with their company policies.These labels ensure that data is appropriately governed, controlled, and handled with care throughout its lifecycle. In this blog we will discuss on how Power BI’s data protection policies, like sensitivity labels, can help organizations meet their security needs while enabling efficient and responsible data collaborationPower BI Security: A practical guide to RLS, OLS and Masking
Row-Level Security (RLS) is great, but it cannot hide sensitive columns completely. When you try to use Object-Level Security (OLS) instead, your charts often crash. This post solves that problem. Learn how to implement a "Defence in Depth" strategy and discover the Field Parameter trick that allows you to hide columns dynamically while keeping your dashboard error-free.
