Why is my Fabric agent able to access the lakehouse despite restrictive labels and DLP policy

In this scenario, the behavior is consistent with how Microsoft Purview protection policies, sensitivity labels, and DLP policies for Fabric work:

1. Protection policies control access only when configured as Purview protection policies
   • Sensitivity labels by themselves do not override workspace permissions.
   • A Microsoft Purview protection policy must be explicitly associated with the sensitivity label to enforce access restrictions in Fabric.
   • When such a protection policy is in place, it “allows users and groups specified in the policy to retain permissions they have on the item, while blocking access for everyone else.” Users not covered by the policy are blocked, but:
     • The label issuer (the user who last applied the label) is not blocked by that policy.
     • The item creator retains access when labels are applied automatically.
   • If contributors (including the agent’s user identity) are still accessing the lakehouse/eventhouse, either:
     • The label is not associated with an active protection policy, or
     • Those users are included in the protection policy’s allowed users/groups, or
     • The label issuer/item creator scenario applies, so they are intentionally exempt.
2. DLP policies with “restrict access” act at evaluation time and are scoped by configuration
   • DLP policies for Fabric and Power BI support a “restrict access” action that, on a policy match, “restricts access to the data owners or to members of the organization, depending on the policy configuration. All other users lose access to the item.”
   • DLP policies use conditions such as sensitivity labels and sensitive info types (like credit card number SIT).
   • For Fabric, they apply to supported item types (semantic models, lakehouses, warehouses, KQL databases, mirrored databases, SQL databases).
   • If the agent and colleagues are still accessing the labeled lakehouse/eventhouse, likely causes include:
     • The DLP policy scope or conditions do not actually match the items (for example, the label condition or location scoping does not evaluate as expected).
     • The DLP policy’s restrict access configuration is set to allow members of the organization (internal users) to retain access, so contributors inside the tenant are not blocked.
     • A DLP evaluation has not been triggered yet for the item (for example, no operation that triggers DLP evaluation has occurred on that item since the policy was configured).
3. Policies do not always override workspace permissions for all principals
   • Protection policies and DLP policies can override workspace permissions, but with explicit exceptions:
     • Label issuers and item creators can retain access even when protection policies are in place.
     • DLP “restrict access” can be configured to still allow data owners or all members of the organization.
   • Therefore, a contributor (including a Fabric agent identity) may still access artifacts if:
     • They fall into one of these exception categories, or
     • The policy configuration is set to allow them (for example, “members of the organization” in the DLP policy), or
     • The policy is not actually matching the item.
4. How to validate and troubleshoot in this scenario
   To confirm whether policies are actually restricting access and why the agent/colleagues are not blocked:
   1. Check if a policy is the cause at all
      • Look for symptoms such as:
        • Items disappearing from workspace list/OneLake catalog.
        • “Permission required” or “Sorry we couldn’t locate that artifact” when opening via link.
        • Indicators that the item contains data from a restricted underlying source.
      • If none of these appear, the policies may not be matching or enforcing on those items.
   2. Use Manage Permissions / OneLake catalog
      • As workspace admin, open the item’s Manage Permissions page or the Permissions tab in OneLake catalog.
      • Check if affected users (agent identity, colleagues) show User is blocked.
        • If User is blocked appears, an organizational security policy (protection or DLP) is revoking access.
        • If it does not, the issue is likely workspace permissions or policy misconfiguration rather than policy enforcement.
   3. Identify whether it’s protection policy vs DLP
      • Recent label changes suggest a protection policy issue.
      • Recent item updates or sensitive data changes suggest a DLP restriction issue.
      • If neither is present, the policies may not be applied or evaluated as expected.
   4. Review DLP policy configuration
      • Confirm that:
        • The policy includes Fabric and Power BI workspaces as locations.
        • The Content contains condition uses the correct sensitivity label and/or sensitive info type.
        • The restrict access action is configured to block the intended users (for example, not leaving “members of the organization” with access if the goal is to block contributors).
        • The specific lakehouse/eventhouse are within the policy’s scope.
   5. Review protection policy configuration
      • Ensure the sensitivity label applied to the workspace/items is associated with a Fabric protection policy.
      • Verify which users/groups are allowed in that policy; remove the agent or contributors if they should be blocked.
      • Remember that the label issuer and item creator will retain access even if not explicitly listed.
5. Fabric data agent enforcement
   • The Fabric data agent uses the requesting user’s credentials and “respects Microsoft Purview governance controls applied to the underlying Fabric data sources, including Data Loss Prevention (DLP) and access restriction policies.”
   • If the agent can still access the data, that indicates the underlying user identity still has access according to the current protection/DLP policy configuration. The agent does not bypass policies; it enforces them based on the user’s effective permissions and policy outcomes.

In summary, sensitivity labels and DLP policies do not automatically override workspace permissions in all cases; their effect depends on how protection policies and DLP “restrict access” rules are configured, including exceptions for label issuers, item creators, and members of the organization. The next step is to verify that the label is tied to a protection policy, that the DLP policy truly matches the items and is configured to block the desired users, and that the agent’s user identity is not in an allowed category.

References:

• Troubleshoot access restrictions
• Protection policies in Microsoft Fabric
• Get started with data loss prevention policies for Fabric and Power BI
• Use sensitivity labels as conditions in DLP policies
• Fabric data agent concepts