Forum Discussion

HoucemDerbelItm's avatar
HoucemDerbelItm
Frequent Visitor
1 month ago

Let Fabric Data Agent ontology inherit RLS from Semantic Model roles instead of OneLake Security

I'm building a Fabric Data Agent with an ontology on top of a Lakehouse (Customer 360 style model — dimension and fact tables). I also have a Power BI semantic model over the same data with a DAX RLS role already defined (e.g., restricting a "Germany" role to rows for that region).

I expected the ontology/Data Agent to honor that semantic model role when a user with the role queries it. Instead, I found that the ontology queries the Lakehouse directly via a graph engine (GQL), and semantic model DAX RLS only applies within the scope of that semantic model — it has no effect on the ontology path. The only way to get row-level filtering enforced there is OneLake Security (data access roles), which requires defining access — including RLS predicates — separately, per table/folder, in the "Manage OneLake security" experience.

The problem:

This means the same business rule ("this role sees only Germany rows") has to be defined and maintained twice, in two different places, using two different mechanisms:

  1. Once as a DAX RLS role in the semantic model (for Power BI reports)
  2. Once as OneLake Security data access roles, configured per table, for the ontology/Data Agent path

For a model with many related tables (dimensions + facts), this means recreating the same predicate across every table individually in OneLake Security, rather than defining the rule once at the role level and having it apply consistently across all related tables — the way a single semantic model role does.

What I'd like to see:

I'd prefer that semantic model roles (and their RLS/CLS definitions) can be inherited by, or reused in, the ontology — so one role definition governs both the semantic model and the Data Agent/ontology layer, instead of maintaining a parallel, per-table configuration in OneLake Security. Today it feels like there's no single source of truth for "who sees what" when a Lakehouse is consumed through multiple paths (Power BI vs. Data Agent).

Questions for the community/product team:

  1. Is there a supported way today to have the ontology consume a semantic model as its data source (rather than Lakehouse tables directly), so DAX RLS is respected end-to-end?
  2. Is unifying RLS definition across semantic model and OneLake Security on the roadmap, or is the expectation that these stay as two independently maintained layers?
  3. If OneLake Security is meant to be the single enforcement layer going forward, is there a way to define a role once and have it apply across a set of related tables (dimensions + facts) rather than configuring RLS per table?

Any guidance — or confirmation this is a known gap — would be appreciated.
My Goal is to achieve RLS for Data Agents without having to define rules for each Table which what the Role DAX in Semantic Model offer .

Data Agent
graph
ontology

1 Reply

  • sannavajjala's avatar
    sannavajjala
    Icon for Resolver II rankResolver II
    1 month ago

    Your understanding aligns with how Fabric currently works.

     

    Today, Semantic Model RLS (DAX) and OneLake Security are two separate security layers with different enforcement points:

     

    Semantic Model RLS is enforced only when users query through the semantic model (Power BI reports, Analyze in Excel, etc.).

     

    Fabric Data Agents/Ontologies query the underlying OneLake/Lakehouse data and therefore rely on OneLake Security for row- and column-level access. They do not inherit DAX RLS from the semantic model.

     

     

    To answer your questions:

     

    1. Can an ontology use a semantic model as its data source so DAX RLS is respected?

     

    As of today, no. Ontologies are built over OneLake data rather than the semantic model, so DAX RLS isn't applied.

     

     

     

    2. Is unified RLS on the roadmap?

     

    I haven't seen any public announcement confirming this. It would certainly be a valuable enhancement, as maintaining the same business rules in multiple places increases administrative overhead and the risk of inconsistencies.

     

     

     

    3. Can OneLake Security define a role once and apply it across related tables?

     

    Currently, security is configured at the data layer, so you'll typically need to configure access for the relevant tables. There isn't an equivalent to a semantic model role that automatically propagates filters across table relationships.

     

     

     

     

    I agree this is a gap. A centralized security model where semantic model RLS could be reused by Data Agents—or where OneLake Security could define reusable role policies across related tables—would provide a much better "single source of truth" for enterprise governance. Until then, maintaining DAX RLS for reporting and OneLake Security for Data Agents is the expected approach.