Complex Data Engineering Issue: Inconsistent Role Enforcement When Using Snowflake PATs in Fabric

SavioFerraz — Thu, 11 Dec 2025 12:24:50 GMT

Hi everyone,

I'm encountering an unexpected and potentially critical security behavior when using Snowflake PATs with Microsoft Fabric connections, and I’d appreciate help validating whether this is expected or a bug.

🟦 Scenario
I have 4 business units, each with its own Snowflake shared database.

Each business unit has a dedicated role that grants access only to its database.

A service account was created in Snowflake.

I generated 4 PATs, each manually restricted to one specific role using Snowflake's role restriction for PATs.

In Fabric, I created 4 separate Snowflake connections, each using:

Username → service account

Password → one of the PATs (each tied to a different restricted role)

Expectation:
Each Fabric connection should only see one database, aligned with its PAT’s assigned role.

🟥 Problem
Regardless of which PAT I use, all 4 Fabric connections show ALL databases during:

Data Pipeline Copy operations

Dataflow Gen2 connections

Any Fabric item connecting to Snowflake

It seems Fabric is using only the service account’s default role, completely ignoring the PAT role restriction, which defeats the purpose of creating role-specific PATs.

🟩 What I verified
In Snowflake: each PAT is correctly restricted to a single role

In Snowflake UI: PAT mappings show proper PAT → role_restriction associations

In Fabric: re-creating the connections doesn’t change the behavior

Testing from Snowflake CLI: PATs respect role restrictions properly outside Fabric

❓ Questions
Does Fabric currently ignore Snowflake PAT role restrictions?
If so, this represents a major security gap.

Is this an acknowledged Fabric bug, or is there a known limitation where Fabric always uses the user’s default role instead of the PAT’s restricted role?

Is the only workaround manually selecting the role in Advanced Options every time a new data movement is created?

Has anyone successfully used PAT-level role restrictions in Fabric with enforced row-level or DB-level isolation?

Any guidance or validation would be extremely helpful — this impacts our data isolation design.

Thanks in advance!

Re: Complex Data Engineering Issue: Inconsistent Role Enforcement When Using Snowflake PATs in Fabri

Vinodh247 — Thu, 11 Dec 2025 16:02:25 GMT

Fabric currently ignores snowflake PAT role restrictions. Fabric authenticates using the underlying Snowflake user, not the PAT’s role binding. It then issues queries without explicitly setting the role, so Snowflake falls back to the user’s default role. This is a known limitation, not documented well, and it is effectively a role-enforcement bypass when you rely on PAT-level restrictions.

Not publicly acknowledged as a bug, but it aligns with existing Fabric–Snowflake connector behaviour: Fabric does not send USE ROLE <role> unless you explicitly set it in advanced options.

Workarounds available as of today:

Manually set the role in every pipeline, dataflow, and dataset using the advanced connection string options. Painful, but reliable.
Create separate Snowflake users per business unit and issue PATs for those users. This is the only fully isolated pattern Fabric respects right now.

No, there is no successful pattern today where PAT-level role restrictions alone enforce isolation in Fabric. Role-restricted PATs do not work as intended in Fabric today. If isolation is critical, you must use separate Snowflake users or enforce the role explicitly in every Fabric item.

topic Complex Data Engineering Issue: Inconsistent Role Enforcement When Using Snowflake PATs in Fabric in Data Engineering

Complex Data Engineering Issue: Inconsistent Role Enforcement When Using Snowflake PATs in Fabric

Re: Complex Data Engineering Issue: Inconsistent Role Enforcement When Using Snowflake PATs in Fabri