Copilot Studio

How to enforce Row-Level Security for Fabric Data Agent when connected directly to Lakehouse tables

(1) Share

Report

Posted on by RR-16041311-0

Hi Team,

I’m looking for help regarding Row‑Level Security (RLS) with Fabric Data Agent.

Scenario

We have created a Fabric Data Agent
The Data Agent is directly connected to Lakehouse tables
The Data Agent is NOT built on a semantic mode

Requirement

We need row-level security so that users only see the data they’re authorized to see (similar to how RLS works in Power BI)
Example: When a Sales Head logs in through a custom portal and queries the Fabric Data Agent, they should be able to see only the rows assigned to them as the Sales Head. We also have a master table that stores the Sales Head email IDs and their assignments.

Questions

Is RLS on Lakehouse tables expected to be enforced when accessed via Fabric Data Agent?
Is there any supported way to implement RLS for a Data Agent built directly on Lakehouse tables (without using a semantic model)?

Categories:

Autonomous agents

I have the same question (0)

All responses (2)

Answers (0)

Sort by

AP-26031104-0 Microsoft Employee on at

Like (1)

Report
Copy link

Link copied!
Hi RR-16041311-0

Thanks for outlining your scenario.

Current Behavior

RLS is not enforced when a Fabric Data Agent is connected directly to Lakehouse tables. RLS in Fabric currently works only through semantic models (Power BI datasets).

1. Is RLS enforced via Data Agent on Lakehouse tables?

No, there’s no automatic RLS enforcement in this setup.

2. Is there a supported way without a semantic model?

No, not natively supported today.

Recommended Options

Use a Semantic Model (Recommended):

Build a model on top of the Lakehouse and define RLS roles. This is the only secure, supported approach.

App-Level Filtering (Workaround):

Filter data in your custom portal using the logged-in user’s email and mapping table.

Requires strict handling to avoid security gaps.

SQL Views (Workaround):

Create filtered views per user/group, but this is not true RLS.

Was this reply helpful? Yes No
Suggested answer

Valantis 6,456 on at

Like (1)

Report
Copy link

Link copied!

Hi @RR-16041311-0,

Microsoft docs confirm that the Fabric Data Agent does honor RLS but only when the right security model and identity propagation are in place.

From Microsoft docs: "The Fabric data agent honors all user permissions to the data, including Row-Level Security (RLS) and Column-Level Security (CLS)."

The reason it may not be working in your scenario is identity propagation. When the Data Agent runs queries against Lakehouse tables, it needs to pass the calling user's identity to the SQL analytics endpoint or OneLake layer for RLS to evaluate. If the endpoint is running under a fixed identity (the lakehouse owner) rather than SSO, RLS can't filter per user it just sees the owner's identity.

For RLS on Lakehouse tables directly (without a semantic model), you have two confirmed paths:

Path 1: SQL Analytics Endpoint + T-SQL RLS
Your Lakehouse has a SQL analytics endpoint. You can define T-SQL RLS using CREATE SECURITY POLICY with inline table-valued functions on the SQL analytics endpoint. You then need to switch the SQL analytics endpoint to User's Identity mode (SSO) in the Security tab of the Lakehouse settings. When the Data Agent queries via the endpoint, the calling user's identity is passed through and RLS filters apply per user.

Path 2: OneLake Security (Preview)
OneLake now supports native RLS for Delta parquet tables via OneLake security roles. This is enforced consistently across all Fabric engines when enabled. Switch your SQL analytics endpoint to OneLake security mode, define RLS roles in OneLake, and RLS is enforced whenever the Data Agent queries those tables regardless of which engine it uses.

Important limitation: the known issue from community investigation confirms that when the Fabric Data Agent is accessed via Azure AI Foundry, RLS may not be enforced due to identity not being propagated. If you're accessing it through Copilot Studio or directly within Fabric, identity propagation works correctly.

Ref: https://learn.microsoft.com/en-us/fabric/data-science/data-agent-sharing

Ref: https://learn.microsoft.com/en-us/fabric/onelake/security/row-level-security

Ref: https://learn.microsoft.com/en-us/fabric/data-warehouse/row-level-security

Was this reply helpful? Yes No