In Short: Layers That Compose, Gaps That Surprise
Fabric's security model is genuinely capable and genuinely layered: workspace roles, item permissions, OneLake data access roles, engine-level controls (row-level and object-level security), and Purview sensitivity labels on top. Each layer is simple alone. The surprises live in composition - what wins when layers disagree, and which paths bypass which controls.
This is the working map we use on engagements, with the classic gaps named, because in the AI era a permissions mistake no longer waits quietly: Copilot and agents find it conversationally.
Layer 1: Workspace Roles, the Coarse Grain
Every workspace assigns four roles: Admin (everything, including access management), Member (publish and share), Contributor (create and edit), Viewer (consume). Roles apply workspace-wide: a Viewer sees, broadly, everything in the workspace.
The design consequence: workspaces are the primary security boundary, so estates that need different audiences need different workspaces - which is why medallion layers and domains map to workspace structure. Stuffing mixed-sensitivity content into one workspace and patching with exceptions is the original sin of most Fabric security audits.
Layer 2: Item Permissions and OneLake Data Access
Item sharing grants access to a single item - a report, a lakehouse, a model - without workspace membership, each share carrying specific capabilities (view, build a model on it, read the SQL endpoint, read OneLake files directly).
OneLake data access roles go finer: named roles scoped to particular folders or tables inside a lakehouse, granted to users or groups. This is the answer to "the analysts may read gold, nobody reads bronze" without multiplying lakehouses. The pattern that works: default-deny the lake, define roles per consumption boundary, grant to groups rather than individuals.
Layer 3: Engine Controls - RLS, OLS and the Classic Gap
Warehouses support SQL-native security; semantic models support row-level security and object-level security, filtering what each user's queries return.
The gap every estate must internalise: model RLS protects the model's front door only. A user who also holds SQL endpoint access or OneLake read on the underlying tables walks around the filter. So enforce data-level restrictions at the layer users actually reach: RLS in the semantic model for report consumers, matching restrictions (or no direct access at all) beneath it. Then test with representative accounts - under report access and under conversational access, since AI answers respect exactly what you configured, including the mistakes.
Layer 4: Labels and the Policy Ride-Along
Purview sensitivity labels classify items and follow content through exports and downstream items; DLP and DSPM for AI policies act on them. Labels do not open or close doors by themselves - they make the estate legible to policy and to auditors, which is why the governance framework treats labelling the priority estates first as a quarter-one deliverable, not a someday.
The Configuration Order That Works
- Structure workspaces so each has one audience and one sensitivity story
- Assign workspace roles to groups, sparingly; Admin is an on-call rota, not a courtesy
- Share items outward instead of adding workspace members inward
- Default-deny lakes; open them with OneLake data access roles per consumption boundary
- Add RLS where consumers need filtered views, and align or remove the paths beneath it
- Label the estates that would make headlines, then let policy enforce
- Test with real accounts quarterly, and again before every AI enablement
None of it is exotic. All of it is the difference between a security model you assert and one you can demonstrate.
Sources and Further Reading
Frequently asked
Broadly five: workspace roles (Admin, Member, Contributor, Viewer) governing everything in a workspace; item permissions for sharing individual items; OneLake data access roles for folder and table level control in lakehouses; engine-level controls such as row-level and object-level security in warehouses and semantic models; and Purview sensitivity labels riding on top.
Admins manage the workspace including access; Members add others and publish; Contributors create and edit content; Viewers see content without editing. Workspace roles are coarse: everyone with a role sees broadly everything there, which is why production estates use more workspaces rather than more exceptions.
OneLake data access roles: define a role scoped to specific folders or tables and grant it to users or groups. Combined with sharing the item without workspace membership, this is the mechanism for fine-grained lake access.
No, and this is the classic gap: RLS filters queries through the model. A user with direct lakehouse or SQL endpoint access bypasses it entirely. Data-level restrictions must be enforced at the layer users actually touch.
Apply them to classify and protect flows: labels travel with exports and downstream items and drive Purview policy. They complement, not replace, access control - a label tells you data is Confidential; permissions decide who opens it.
