RLS implementation under direct Lake connectivity

Your reasoning is solid and aligns with the current Microsoft guidance. Here's a more complete picture to round it out:
Your core point is correct — RLS defined at the Warehouse/SQL Analytics Endpoint level causes a DirectQuery fallback because Direct Lake can't push row-level security predicates down to VertiPaq from an external SQL security layer. The moment Direct Lake detects it needs to enforce SQL-layer row filters, it falls back to DirectQuery against the SQL Analytics Endpoint, losing the in-memory performance advantage entirely.
RLS at the semantic model layer is the right call for Direct Lake, and it's exactly what Microsoft recommends. Dynamic RLS using USERPRINCIPALNAME() or USERNAME() in DAX roles works natively within the VertiPaq engine without triggering fallback, as long as the filtering happens on tables that are loaded into the Direct Lake frame.
A few nuances worth knowing:
One thing to watch is that Direct Lake has its own concept of "fallback" triggers beyond just RLS — things like unsupported data types, very large string columns, or certain complex queries can also cause fallback. It's worth monitoring the fallback rate in the Fabric Capacity Metrics app after deployment to confirm you're genuinely staying in Direct Lake mode.
Another consideration is that semantic model RLS doesn't protect data if someone queries the Warehouse directly via SQL (e.g., through the SQL Analytics Endpoint or a notebook). If your Gold layer contains sensitive data, you might still want Warehouse-level security for those access paths, while accepting that those users won't go through the semantic model at all. The two security layers serve different access channels.
Finally, if you have very complex, dynamic RLS rules (like territory hierarchies or organizational rollups), make sure the security table itself is also in the Direct Lake frame — if it has to fall back to query the security mapping, you lose the benefit there too.

For Direct Lake over a Warehouse/SQL endpoint, applying RLS at the source will typically force DirectQuery fallback, which removes the main performance benefit. That’s why, in most cases, semantic model RLS is the preferred approach for interactive reporting.

However, this comes with a trade-off: model-level RLS only secures access through Power BI, not across other consumers of the same data. If you need centralized, cross-engine security, you’ll have to accept either performance impact or consider alternatives like OneLake-based architectures.

In short:

• Performance priority → RLS in semantic model
• Security centralization → RLS at data layer (with trade-offs)