Controlled "Semantic Model Execute Queries" REST API Access for Fabric Users

All responses have been reviewed. No solution has yet been offered that meets these criteria:

• Application must run DAX queries against a semantic model via API calls (OBO or direct SP calls)
• RLS rules must be enforced on the calls based on the application's current user
• Must be compatible with onelake security RLS on lakehouse (SSO enabled)
• Traffic to the 'query semantic model' API is rejected unless it comes from the application
• Portal access and core Fabric features stay intact for all users
• No Entra user as a service account; auth must be automated and reliable

Proposed solutions

• Dedicated Entra service user with impersonation: entra user as a service account is an anti-pattern, reliability concerns
• Additional authentication layer: core Fabric features are lost due to tenant private link, which is required to ensure all traffic passess through the additional layer (APIM) 
• Query lakehouse tables directly / GraphQL: bypasses RLS rules entirely, requires duplication of complex business logic outside of semantic model
• Service principal with impersonation and fixed-identity Direct Lake: requires model with fixed identity -  onelake security RLS rules can't be implemented.

Just to restate the need - we want to use Fabric as the single plane for defining and enforcing RLS restrictions across our organization's data. This should apply even when users are interacting with Fabric data outside of Fabric via API calls. The current API is an on/off switch for security groups. Enabling API access for the application gives a large population of users the ability to connect to Fabric data with untrusted tools, which is a valid security concern. The current solutions are not suitable because a) they don't support onelake security RLS rules on lakehouse tables, b) they result in substantial feature loss for users, or c) they introduce reliability concerns that are not acceptable in an enterprise-grade application.

If anyone has additional ideas, we'd love to hear them!