Dr. Estera Kot

FabCon Europe 2026 in 18 demos · Part 15 of 18 · Security and governance

Policies in Fabric: an allow list with no Deny

Tenant and capacity admins write rules that allow an action when conditions match. Anything no rule matches is blocked, so the first rule changes the default.

By Dr. Estera Kot, Microsoft MVP, CTO at Clouds on Mars, and former Microsoft Principal Product Manager for the Apache Spark runtime in Fabric. Published .

Microsoft Fabric policies are condition-based governance rules that a Fabric administrator or a capacity administrator activates for the whole tenant or for one capacity. Each rule names conditions, such as workspaces, security groups, or sensitivity labels, and one effect: Allow. When a policy has rules and none matches an action, Fabric blocks it. Every policy is an allow list. This post is part of FabCon Europe 2026 in 18 demos.

Three policies exist today. One governs sharing data outside the tenant, one governs which items people create on a capacity, and one governs which workspace admins may edit encryption and outbound networking settings. Policies are in preview, cost no capacity units, and are managed from the Govern tab of the OneLake catalog.

In short

  1. A Fabric policy is an allow list. Allow is the only effect you can write, and an action that matches no rule is blocked.
  2. The scope is the tenant or one capacity, fixed when you create the policy set. Only one policy is active per scope, and nothing applies until an admin activates it.
  3. The first Allow rule flips a policy from allow all to allow list. Add the rule that keeps everything else open in the same change.
OneLake catalog, Govern tab, Policies (preview): the Fabric tenant scope with no policy set connected, and the system policy for workspace settings set to Allowed (System Default). 16 seconds, no sound, recorded Oct 19, 2026.

Same demo in Polish and German. Step-by-step runbook: D12.

What Fabric policies are and how they decide

A policy lives in a policy set, a Fabric item stored in a workspace. That gives policies REST APIs, Git integration, CI/CD, and service principal support. You choose the admin scope, tenant or capacity, when you create the policy set, and you cannot change it later. Anyone with permission on the item can edit rules. Only the admin of the scope can activate the policy, and Git cannot activate it.

Only one policy is active per scope. When a user attempts a governed action, the owning feature asks the policy engine for a verdict and enforces it.

How Fabric evaluates an action against a policy A user tries a governed action. Fabric finds the admin scope, tenant or capacity. If no active policy with rules exists for that scope, the policy default applies. If rules exist and one matches, Fabric allows the action. If rules exist and none matches, Fabric blocks it. Conditions in a rule combine with AND, values with OR for AnyOf and NOR for NoneOf, rules with OR, and a missing condition matches everything. Every result goes to the audit log. A user tries a governed action Admin scope tenant or capacity Active policy with rules? yes Does any rule match? yes Allow no Default applies set per policy type no Blocked implicit, no Deny rule How a rule matches Conditions in a rule: AND AnyOf: OR, NoneOf: NOR Rules in a policy: OR Missing condition: matches everything One active policy per scope. The scope is fixed at creation. Nothing applies until an admin activates the policy. Fabric writes every result, default, allow, or block, to the audit log. How Fabric evaluates an action against a policy A governed action goes to its admin scope. Without an active policy with rules, the default applies. With rules, a matching rule allows the action and no match blocks it. A user tries a governed action Admin scope tenant or capacity Active policy with rules? no Default applies yes Does any rule match? no Blocked yes Allow How a rule matches Conditions in a rule: AND AnyOf: OR, NoneOf: NOR Rules in a policy: OR Missing condition: matches everything One active policy per scope. The scope is fixed at creation. Nothing applies until an admin activates the policy. Fabric writes every result, default, allow, or block, to the audit log.
Figure 1. A Fabric policy is an allow list. Once a policy has rules, anything that matches none of them is blocked. Based on the evaluation order in Microsoft Learn.

The three policies available today

IDPolicyScopeWhat it controlsDefault
P1Allow external data sharingTenantWho shares data outside the tenant, by group, workspace, label, and recipient domainOverview: Block all. Policy page: the legacy tenant setting
P2Allow item creationCapacityWhich item types users create in the capacity's workspacesAllow all item types
P3Allow workspace settings editingTenantWhich workspace admins edit encryption and outbound networking settingsAllow editing of all settings

Conditions come from a short list: workspaces, Microsoft Entra security groups, sensitivity labels with a No label option, recipient email domain, item type, and workspace setting type. P3 is the policy behind the demo. It decides who may change outbound access protection in the first place.

What the Fabric policies demo shows

This is the default state of a tenant: one system policy, allowed for everyone, and nothing to edit until a policy set exists. The recording shows one tenant policy. Learn lists two at tenant scope, so the list in your tenant can differ.

Fabric tenant policies pane in the OneLake catalog Govern tab: No policy set connected, the policy Workspace admins can edit workspace settings expanded and set to Allowed (System Default), and a note to connect a policy set item first
The tenant policy pane at 0:12, cropped to the policy. Allowed (System Default), locked until a policy set is connected.

Fabric policies limits and catches

The catch: the first Allow rule changes the default. In the workspace settings policy, switching to Advanced and adding one rule turns allow all into an allow list. Learn's example: a rule that allows editing customer-managed keys immediately blocks all other security settings, unless another rule allows them.

Before: Allowed (System Default)

AdminEncryptionOutbound
Key adminsCan editCan edit
Other adminsCan editCan edit

After: Advanced, one rule lets Key admins edit Encryption

AdminEncryptionOutbound
Key adminsCan editBlocked
Other adminsBlockedBlocked

Fix in the same change. Add a second rule with setting type NoneOf Encryption and no group condition. Every workspace admin can edit outbound settings again, and encryption stays with Key admins.

Figure 2. The first Allow rule turns allow all into an allow list. Example based on the workspace settings policy in Microsoft Learn. The group name is illustrative.

Policies prevent. The OneLake catalog Govern tab, where the Policies center lives, shows what already drifted.

Run the Fabric policies demo yourself

You need the PolicySetTenantSwitch tenant setting, part of settings on in the recap demos folder, the Fabric administrator role, and a capacity outside West Europe, North Europe, and West US. Steps from runbook D12:

1. Open OneLake catalog > Govern > Policies (preview).
2. Switch between Fabric tenant and Capacities.
3. Open "Workspace admins can edit workspace settings" and read the note to connect a policy set first.

Expected result: the policy list per scope. Allow is the only effect, and there is no deny rule. Time and cost: about 3 minutes, no Fabric capacity needed.

Viewing needs no capacity. Creating a policy set does: Learn requires a workspace on a capacity and Contributor access or higher. This is Learn's own item creation example for one capacity:

Policy:  Allow item creation        Scope: one capacity
Rule 1:  Security groups  AnyOf  DataflowGen2-Creators
         Workspaces       AnyOf  Prod-Analytics, Prod-Reporting
         Item type        AnyOf  DataflowGen2
Rule 2:  Workspaces       NoneOf Prod-Analytics, Prod-Reporting

Rule 1 alone would block every other item creation across the capacity. Rule 2 keeps the other workspaces open.

What to do on Monday

On Monday: Pilot policies on one capacity.

Pick a capacity outside the unsupported regions. Test with one member and one nonmember of each group before you activate.

Key facts at a glance

Checked on Microsoft Learn on November 3, 2026.

IDFactSource
K1Microsoft Fabric policies are in preview.Learn: What are Microsoft Fabric policies (preview)?
K2Allow is the only effect. If rules exist and none matches, the operation is denied.Learn: What are Microsoft Fabric policies (preview)?
K3Scopes: Tenant, activated by a Fabric administrator. Capacity, activated by a capacity administrator.Learn: What are Microsoft Fabric policies (preview)?
K4One active policy per scope. The scope cannot change after creation, and Git cannot activate a policy.Learn: What are Microsoft Fabric policies (preview)?
K5Up to 100 rules per tenant policy, 50 per capacity policy, 50 values per condition.Learn: What are Microsoft Fabric policies (preview)?
K6Changes take effect within 15 minutes of activation.Learn: What are Microsoft Fabric policies (preview)?
K7Not supported yet in the capacity regions West Europe, North Europe, and West US.Learn: What are Microsoft Fabric policies (preview)?
K8Included with the Fabric license. Policies do not consume capacity units.Learn: What are Microsoft Fabric policies (preview)?

Frequently asked questions

What are Microsoft Fabric policies?

Fabric policies are governance rules that a Fabric administrator or a capacity administrator activates for the tenant or for one capacity. Each rule combines conditions, such as workspaces, security groups, or sensitivity labels, with an Allow effect. They are in preview as of November 3, 2026.

Can a Fabric policy deny an action?

You cannot write a Deny rule, because Allow is the only effect. Blocking is implicit: once a policy has rules, Fabric blocks any action that matches none of them. The workspace settings policy also offers a Blocked mode that stops all workspace admins from editing the governed settings.

What is the difference between tenant and capacity scope in Fabric policies?

A tenant-scoped policy applies across the whole organization, and a Fabric administrator activates it. A capacity-scoped policy applies to the workspaces on one capacity, and a capacity administrator activates it. You choose the scope when you create the policy set and cannot change it later.

Which policies are available in Microsoft Fabric?

Three, as of November 3, 2026: Allow external data sharing at tenant scope, Allow item creation at capacity scope, and Allow workspace settings editing at tenant scope. The last one controls which workspace admins can edit customer-managed keys and outbound networking settings.

How are conditions combined in a Fabric policy rule?

Conditions within one rule combine with AND. Values within a condition combine with OR for AnyOf and NOR for NoneOf. Separate rules combine with OR, and a condition you leave out matches everything.

Why can't I use Fabric policies on my capacity?

Microsoft Learn lists West Europe, North Europe, and West US as capacity regions where Fabric policies are not supported yet. A Fabric administrator must also turn on the Policies tenant setting, which can be limited to specific security groups.

About the author

Dr. Estera Kot is CTO at Clouds on Mars, a Microsoft and Databricks partner for data and AI in Europe and the Middle East. At Microsoft she was Principal Product Manager for the Apache Spark runtime in Azure Synapse Analytics and Microsoft Fabric, and she created the Native Execution Engine. She is a Microsoft MVP and holds a Ph.D. in Computer Science from the Warsaw University of Technology. She presented this series as the FabCon Europe 2026 recap in Gdynia on October 21, 2026, and online on October 23, 2026. Slides, recordings, and runbooks are in the public recap repository.

Sources

Microsoft Learn and the recap repository, checked on November 3, 2026.