Stored procedure permissions different than caller user/account permissions in Fabric Warehouse

[stuckerj]

In T-SQL, we use the EXECUTE AS to give the stored procedure permissions that go beyond the calling user/account permissions.  Is there an equivalent way to do this for a stored procedure in a Fabric Warehouse?

Using the principle of least privilege, I want a service account to call a stored procedure on a schedule, and I don't want to grant that service account all of the privileges that are needed inside the stored procedure itself, like read from specific source data or insert into specific destination data.

Thanks,

'('  Jeff
\

[vrsanaidu2025 · Accepted solution]

In Microsoft Fabric Warehouse, there currently isn't a direct equivalent to T-SQL's EXECUTE AS for stored procedures. However, you can achieve similar behavior using Service Principals and Managed Identity delegation combined with role-based access control (RBAC) and workspace-level permissions

[v-achippa]

Hi @stuckerj,

Thank you for reaching out to Microsoft Fabric Community.

Thank you @vrsanaidu2025 and @tayloramy for the prompt response.

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or have you raised this in the ideas forum?

Thanks and regards,

Anjan Kumar Chippa

[tayloramy · Accepted solution]

Hi @stuckerj, 

THis isn't supported yet. Only GRANT< REVOKE, and DENY are currently supported for granular permissions in fabric warehouses: https://learn.microsoft.com/en-us/fabric/data-warehouse/sql-granular-permissions

I recommend submitting this as an idea and see if it gains any traction: https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

[vrsanaidu2025 · Accepted solution]

In Microsoft Fabric Warehouse, there currently isn't a direct equivalent to T-SQL's EXECUTE AS for stored procedures. However, you can achieve similar behavior using Service Principals and Managed Identity delegation combined with role-based access control (RBAC) and workspace-level permissions