Fabric Direct Lake RLS passes a role test while source access tells another story

The semantic model's “test as role” view looks right, yet a security reviewer asks whether a user can reach the underlying data through another route. A Fabric community write-up describes confusion around identity, workspace roles and changes that only appear after the model reframes.

Draw the access path first

List the user's workspace role, semantic-model permission, OneLake permission and SQL analytics endpoint permission separately. Microsoft's Direct Lake fixed-identity guidance explains how SSO and fixed identity change the data access path. A semantic-model RLS test proves behavior through that model. It does not prove that every other route to the lakehouse is closed; those routes exist only if the user has their own relevant permissions.

Test the real user, not only the role designer

Use a test identity with the same workspace and item grants as the intended audience. Query through the shared report, then test any separately granted SQL endpoint or lakehouse route. Remove a grant in a controlled environment and repeat. Record whether the user is relying on SSO or a fixed identity, because that determines which principal the source sees.

Account for security-change timing

Microsoft's Direct Lake mechanics explain framing and refresh. When the policy or underlying data changes, measure when the model reflects it rather than assuming the edit is immediately visible in every cached view. Make revocation timing part of the access acceptance criteria.

Adovo’s view

Security is a property of every usable path to data. A perfect role test in one interface is only one proof. A customer should be able to name the identity, route and revocation time for each audience.