Row-level security and object-level security protect different parts of a semantic model. RLS filters which rows a user can query. OLS can hide entire tables or columns, including their metadata, from users who are not allowed to see them. For DP-600, configuring the roles is only the beginning; the control is trustworthy only when its surrounding access paths and identities match the threat model.
Security in Fabric is layered. Workspace roles, item permissions, semantic-model roles, and underlying data permissions can all grant access in different ways. That makes role-based access control more than background theory. The effective security boundary is the combination of every path a user or service can use, not the most restrictive rule visible on one screen.
A useful threat model therefore starts with assets and actors. Which rows are sensitive? Which columns or tables must be undiscoverable? Who should consume reports, who should build new reports, who can edit the semantic model, and who can access OneLake or a source directly? RLS and OLS control semantic-model queries; they do not erase broader permissions granted elsewhere.
RLS protects row sets, not workspace authors
In the Power BI service, RLS applies to users consuming a semantic model with Viewer permissions. Workspace Admins, Members, and Contributors are not constrained by RLS in the same way because those roles are treated as content creators or managers. A team can therefore configure perfect regional filters and still expose all regions to someone who was added as Contributor for convenience.
The threat is not a broken DAX expression; it is a role assignment that bypasses the intended consumption boundary. Review workspace roles before validating RLS. If a user is supposed to be a restricted consumer, the workspace role must reflect that operating model.
Classify the data before choosing controls. RLS is appropriate when different users may query the same columns but should receive different records. OLS is appropriate when the existence of a table or attribute is itself sensitive. If the requirement is to prevent report authors from reaching raw data entirely, workspace, item, OneLake, or source permissions are part of the solution rather than something semantic-model roles can replace.
OLS protects schema knowledge as well as values
OLS can deny access to tables or columns so unauthorized users cannot query or even discover those model objects. This is useful for sensitive attributes such as salary, personally identifiable information, or internal scoring fields. It differs from simply hiding a field in the model, which is a usability choice rather than a security control.
Model authors should identify whether the threat is exposure of records, exposure of attributes, or both. RLS alone can leave a sensitive column visible for the rows a user is allowed to see. OLS can remove the object, but that decision may break measures or reports that depend on the secured object, so testing needs both security and functional cases.
This distinction becomes important with group membership. A user can be correctly assigned to an RLS role and still bypass the intended row restriction by receiving a higher workspace role. Access reviews should therefore join two datasets conceptually: semantic-model role membership and workspace/item privilege. Reviewing either list alone can produce false confidence.
Identity assumptions are part of the control
Dynamic RLS often maps the signed-in user to a security table by using an identity function such as USERPRINCIPALNAME. That mapping assumes identity values are stable, correctly normalized, and joined to the intended business scope. Duplicate mappings, stale group membership, or unmatched users can create overexposure or unexpected denial.
Identity governance therefore matters outside Power BI. The principles behind Microsoft Entra identity and access management are relevant because the semantic role depends on reliable user and group identity upstream. When a person changes department, leaves the company, or receives an emergency role, those lifecycle events must reach the analytical access model.
OLS also affects dependent calculations. If a measure references a column that is hidden by OLS, test how the report behaves for the restricted role. A technically secure model that fills pages with broken visuals can encourage teams to grant broader access as a workaround. Security design should include a usable restricted experience, not only denial.
Direct data access can bypass semantic controls
A user who cannot see a column through OLS may still be able to read the underlying lakehouse, warehouse, or source if separate permissions allow it. Likewise, RLS on a semantic model does not automatically restrict SQL, notebook, or OneLake access. The semantic control protects one access path, not every copy of the data.
Map each route to the sensitive asset. Report consumption, Build permission, XMLA access, notebooks, SQL endpoints, OneLake file access, exports, and source-system permissions can represent different trust boundaries. The security design is complete only when the intended restriction is consistent across the paths the user actually possesses.
Dynamic security tables should have uniqueness and referential-integrity checks. If one user appears twice with conflicting scopes, or if a business unit has no matching identity row, the DAX filter may return an unexpectedly broad or empty result. Treat the security mapping table as production data with quality checks and an owner.
Build permission changes what a consumer can do
Consumers with Build permission can create new reports and issue queries against a shared semantic model. RLS and OLS can still apply, but the user now has far more freedom to explore the portion of the model they are authorized to see. That is appropriate for self-service analysts and unnecessary for many report viewers.
Grant capabilities according to task. A person who only needs a published dashboard should not receive authoring rights merely because it is convenient. The broader access-control discipline described in Azure RBAC fundamentals reinforces this distinction between using a resource and administering or building on it.
Export and Analyze in Excel paths deserve explicit review because users can interact with a semantic model outside the original report. The same model security rules may still apply, but the user can ask different questions and combine fields differently. A security design should be tested at the semantic-model boundary rather than assuming the published report is the only interface.
Misconfiguration often fails silently
A security rule can return plausible data while being wrong. A regional manager accidentally seeing two regions may not notice; a row filter with an overly broad relationship can simply show larger totals. This is why functional testing must use known personas with expected row counts and known forbidden values.
Test negative cases deliberately. Confirm that a user cannot discover an OLS-secured object, cannot retrieve excluded rows, and cannot gain broader access through a different workspace or shared item. A successful report render proves almost nothing about least privilege.
Test privileged personas as well as restricted ones. An administrator may legitimately see all data, but the organization should verify that the privilege comes from an intentional role rather than from an accidental direct grant. Positive tests prove the intended audience can work; negative tests prove unauthorized paths remain closed.
Telemetry should prove both use and attempted misuse
Evidence should include role membership, workspace permissions, sharing changes, and query or access activity where available. The objective is to answer who had access, through which path, and whether the observed access matched policy. Security without evidence becomes hard to distinguish from assumed security.
General security, compliance, and identity in Microsoft cloud environments practice helps because useful monitoring follows identity and access events across systems rather than collecting isolated logs with no interpretation. Alerts should focus on changes that expand privilege, unexpected sharing, or access patterns that contradict the expected role.
Audit evidence should be retained long enough to investigate delayed questions. Sensitive-data access may be challenged weeks after an event. A useful evidence plan identifies which identity and activity logs can reconstruct workspace-role changes, sharing changes, model-role membership, and important query access during that period.
A realistic failure path combines controls
Imagine a finance model with RLS by business unit and OLS on employee compensation columns. A manager is correctly mapped to one unit and sees only that unit in reports. Later, the manager is made workspace Contributor to help troubleshoot a visual. The RLS assumption changes immediately. If the same person also has read access to the warehouse, OLS no longer represents the only route to compensation data.
The lesson is that controls are contextual. The RLS expression and OLS role can remain unchanged while the effective threat boundary changes because surrounding permissions changed. Reviews should therefore focus on effective access rather than on whether the semantic-model configuration still looks correct.
Threat modeling should also cover service principals and automation identities. A pipeline or API identity with broad workspace rights can expose or export data outside the interactive RLS/OLS user experience. Machine identities need the same least-privilege design, credential lifecycle, and ownership discipline as human users.
Evaluate the control as a path, not a checkbox
A practical security review asks: what asset is protected, which identities can reach it, which paths exist, where is RLS or OLS enforced, which higher privileges bypass the control, and what evidence demonstrates the expected restriction? That model is more durable than a checklist of settings.
RLS and OLS are valuable because they let a shared semantic model serve different audiences safely. They become fragile when teams assume semantic security can compensate for overly broad workspace, item, or source access. The control is strongest when identity lifecycle, permissions, model roles, and evidence all describe the same trust boundary.
The security review should end with an effective-access table for representative personas. For each persona, record workspace role, item permissions, Build rights, semantic roles, direct data access, and expected visible assets. That simple artifact makes bypass paths much easier to see than a screenshot of one security settings page.
