Microsoft announced a batch of new Purview capabilities for Fabric at FabCon Atlanta earlier this year, and the framing was blunt: AI adoption is increasing data exposure risk, and the new controls exist to let organizations scale AI initiatives without scaling that risk alongside it. If you're running a Fabric workspace, or planning one, this matters for how you think about Purview data governance from here forward. I've spent more than a decade in the BI trenches, and most recently inside Purview's catalog and the Microsoft data stack around it. People often ask me about this on calls: "Microsoft added governance guardrails" and "our organization is now governed" are two different claims. Only the first one is true the day these features ship.
Microsoft just added four new guardrails to Fabric
The update covers four areas. First, Data Loss Prevention now extends into Fabric Warehouses and KQL/SQL databases, so administrators can apply policies that trigger a warning or restrict access when sensitive data shows up somewhere it shouldn't. Second, Insider Risk Management now covers Fabric lakehouses, flagging risky behavior like external sharing or data exfiltration that used to sit outside Purview's field of view. Third, Data Security Posture Management extends into Fabric workloads alongside DLP and IRM, giving a security team a posture view instead of a per-workload guess. Fourth, and newest, Purview brings preview-stage governance to Copilot and AI agent activity inside Fabric: detecting sensitive data inside prompts and responses, flagging oversharing risk, and giving investigators a way to trace unsafe AI usage, backed by existing Purview tools like Audit, eDiscovery, and retention policies.
That's a real expansion of what Microsoft ships out of the box, and it closes gaps that genuinely mattered, especially the AI-prompt visibility, which nobody had a good answer for six months ago. Whether all four of these controls actually cover your Fabric footprint depends entirely on how the workspace was scoped when it launched. That's the exact question a Fabric Readiness Assessment is built to answer before a rollout starts, not after.
A guardrail is not the same thing as a governance program
Here's the distinction that gets lost in announcement season: a guardrail is a control somebody else built and shipped for you. A governance program is your organization's own decision about who's accountable when that guardrail fires. Microsoft can ship DLP for a Fabric Warehouse. Microsoft cannot decide who reviews the policy tip when it fires, who owns the exception process, or who's on the hook when a legitimate business user gets blocked from data they actually need.
Call this borrowed governance: capability that shows up in your tenant on day one, but that nobody in your organization has actually claimed. I've walked into more than one client site where a shiny new Purview feature had been live for months and not a single person could tell me who owned it. It's the equivalent of a smoke detector that's wired in but assigned to no one - the alarm sounds, but responding to it isn't anyone's job.
This is where the standard data governance roles still do the heavy lifting Purview can't do for you. Data stewards, usually from the business side, decide what "sensitive" means for a given domain and keep the glossary terms current. Data custodians, typically your DBAs and data engineers, own the technical plumbing: who gets access, how lineage gets traced, what happens when DLP flags a false positive at 2 a.m. Without both roles assigned before the guardrails go live, the new controls generate noise instead of protection.
The Unified Catalog update surfaces problems; it doesn't resolve them
The other half of this release lives in the Purview Unified Catalog: organization-wide data discovery, publication workflows for data products and glossary terms, and expanded data quality checks that now run even against ungoverned assets. That last part is the sleeper feature. For the first time, Purview will tell you about data quality problems in assets nobody has formally claimed yet.
That's genuinely useful, and it's also where a lot of Fabric rollouts get their first uncomfortable surprise: the catalog surfaces two teams with two different definitions of the same metric, or a data product with no assigned steward, and now there's a paper trail proving the gap existed. The catalog is a mirror, not a fix. It shows you where ownership is missing. It doesn't assign it.
Microsoft's own language for this model is a federated approach to Microsoft Purview data governance: central policy, distributed ownership across whoever actually understands a given slice of the data estate. Purview even ships a dedicated data governance administrator role, distinct from the general administrator role, precisely so business concepts get defined by the people who understand them, not by IT alone. The Microsoft Purview Unified Catalog is where that's supposed to play out: business users register data products, tag data sources, and build managing-data habits that outlive whoever originally wrote the pipeline. Whether that federated model actually holds together depends on whether your governance domains map to how the organization is structured, or just to how Fabric happened to get provisioned. Any data governance solutions effort like this only works when the users in your organization who own a given domain actually know they own it, and know enough about that domain's data health to answer for it.
Financial services, healthcare, and insurance organizations don't get the luxury of treating this as a future problem. If your Fabric environment holds anything that touches a compliance obligation, the gap between "Microsoft ships a DLP policy engine" and "our organization has a documented, tested policy for what that engine enforces" is exactly the gap an auditor will ask about. Fortified Data's team has been SOC 2 Type II certified and doing this work since 2002; the Purview features change, but the underlying discipline, (defined roles, tested policies, an owner for every exception) doesn't.
Microsoft's recent update makes Fabric measurably safer to run AI workloads on top of. What it doesn't do is assign your data stewards, write your exception process, or decide who answers when a policy fires outside business hours. That work was never Microsoft's to do. If your Fabric rollout is treating these new guardrails as the finish line rather than the starting point, talk to Fortified Data's team about what a governance program built around them actually looks like.