Power BI RLS / OLS Testing
Security rules should be tested, not assumed
SemanticOps helps validate row-level and object-level security behavior after model changes, refactors, and AI-assisted edits — so access boundaries are confirmed, not hoped for.
The problem
Security logic can silently regress
RLS and OLS rules are often validated manually or with narrow spot checks. Security behavior can change indirectly — without touching a role directly — through any of these model changes.
Relationship changes
A relationship direction change can shift how filters propagate, silently changing which rows a role can see.
Filter expression edits
A measure used inside a role filter is refactored — the filter still applies but now returns a different boundary.
Role changes
A role is renamed, merged, or modified. Existing users assigned to the old role fall through to the wrong access level.
Table restructuring
A table is split or renamed. Role filters referencing the old table name silently fail or lose effect.
Column rename or delete
An OLS rule referencing a renamed column may become a no-op — the column is now visible when it should be restricted.
AI-generated model changes
An agent adds or modifies a relationship, measure, or table. Security behavior is not tested as part of the workflow.
Test examples
What security regression tests look like
Scenario
Sales Manager role
Test
Impersonate [Sales Manager] role
Validates
Filter boundary correctness
Assert: only rows where Region = user.Region are returned
Scenario
Finance restricted
Test
Impersonate [Finance Restricted] role
Validates
OLS column visibility
Assert: Salary and Margin columns are hidden
Scenario
Cross-region data
Test
Impersonate [Regional Analyst] role
Validates
Cross-filter propagation
Assert: no rows from other regions appear in any table
Workflow
Security regression as a release gate
A test suite that includes RLS and OLS validation makes security a first-class part of the release process — not an afterthought.
Build a security regression test suite
Cover each role, boundary condition, and sensitive column
Run the suite before any model change reaches production
Include RLS and OLS tests in every release gate
Run again after AI-assisted edits
Agents may touch relationships or measures that affect security
Review failing tests before deploying
Any boundary change is surfaced explicitly, not discovered by users
Export test results as security evidence
Useful for compliance reviews and client handovers
Test security rules, not just business logic.
Build RLS and OLS regression suites that run before every deployment and every AI-assisted edit.