Generate Ontology from Semantic Model - Security

Hey HoucemDerbelItm ,

Great question and an important one to ask early. Security assumptions like this one are easy to inherit silently, so raising it before relying on the ontology is exactly the right move.

RLS roles and DAX rules you define in a semantic model do not carry over to an ontology generated from it, so there is a genuine data‑leak risk. Semantic‑model RLS is only enforced when data is queried through the model (Power BI reports, Analyze in Excel, DAX). Ontology generation borrows the model's structure (entity types, properties, relationships) but binds to the underlying OneLake tables directly, reading beneath the layer where RLS lives which is why bound‑data queries work without measures or calculated columns.

Worse, ontology data binding currently requires the bound tables to have OneLake security disabled, so you can not push RLS down to OneLake either. Access to ontology data is therefore governed only by item‑level permissions, not row‑level and that same all‑rows access flows to downstream graph QuerySets and agents.

So do not treat semantic‑model RLS as a security boundary for an ontology. If some users may only see part of the data, separate it structurally (bind only the entitled subset, or use per‑audience ontologies/workspaces) and control access at the item level. And since this is a preview feature, keep sensitive or regulated data out of generated ontologies until per‑user row security is supported.

For Detailed Information:

Generating an ontology (preview) from a semantic model

Data binding in ontology (preview)

Row-level security (RLS) with Power BI

Fabric permission model – compute vs. OneLake security

OneLake security access control model

Security overview for graph in Microsoft Fabric

Hi Houcem! This is a great question regarding Row-Level Security (RLS) and semantic models.

When you generate an ontology or connect external tools to a Fabric semantic model, the RLS roles should technically pass through, provided the user is accessing the data via an identity that the model recognizes. However, if the ontology generation tool uses a service principal or extracts the data in bulk bypassing the user context, there is absolutely a risk of a data leak.

Always test the generated ontology output using a restricted test user account to verify if the RLS filters are actually being applied at the query level.

We had to be extremely careful with this exact security testing when building data models for our regional tax compliance clients (we manage data pipelines for the FBR Sales Tax Calculator and company financials). If sensitive financial data leaked across tenants, it would be a compliance disaster.

I'd recommend keeping the semantic model strictly governed and avoiding third-party exports if they don't natively support Fabric's security context.

Hi Houcem! This is a great question regarding Row-Level Security (RLS) and semantic models.

When you generate an ontology or connect external tools to a Fabric semantic model, the RLS roles should technically pass through, provided the user is accessing the data via an identity that the model recognizes. However, if the ontology generation tool uses a service principal or extracts the data in bulk bypassing the user context, there is absolutely a risk of a data leak.

Always test the generated ontology output using a restricted test user account to verify if the RLS filters are actually being applied at the query level.

We had to be extremely careful with this exact security testing when building data models for our regional tax compliance clients (we manage data pipelines for the FBR Sales Tax Calculator and company financials). If sensitive financial data leaked across tenants, it would be a compliance disaster.

I'd recommend keeping the semantic model strictly governed and avoiding third-party exports if they don't natively support Fabric's security context.

Hi HoucemDerbelItm  , 

The short answer is no , There's no data leak. The Data Agent / ontology inherits the user's permissions at each source: it honors RLS and CLS, and for semantic models only Read permission is required. If the user has RLS/CLS from their role, they only see their authorized subset. Full stop.

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

And this is key: it's one of Fabric's core security principles ,  security is defined once and enforced everywhere ("define once, enforce everywhere"), organized in levels that inherit downward:

• Level 1 – Authentication: who are you? (Entra ID)
• Level 2 – Fabric Authorization: can you access the tenant / workspace / item? (workspace roles, item permissions, tenant settings)
• Level 3 – Data security: which rows / columns can you see? (RLS, CLS, OLS, OneLake Security)

OneLake Security controls all access to data with permissions inherited from the parent item or workspace. That's why the ontology opens no backdoor: it consumes those same levels. Very important to keep this clear when designing client architectures.

https://learn.microsoft.com/en-us/fabric/onelake/security/get-started-security

If this helped, please consider giving it a Like. If it solved your issue, please mark it as the Accepted Solution to help others facing the same problem.

Thanks