Enforcing OneLake Security on external semantic model API calls without adding security risks

Problem

External applications cannot query Fabric semantic models on a user’s behalf - with OneLake RLS security rules enforced - unless the Fabric API is exposed to any and every client an authorized user might decide to install and try out. Ungoverned API access is a security risk: users might unwittingly funnel data to an unapproved AI service or install a compromised open-source tool that exfiltrates it. Organizations must accept this risk to enforce OneLake security on semantic model calls from external applications. This practical limitation keeps OneLake security from delivering on its “define once, enforce everywhere” promise.

Details

The “Semantic Model Execute Queries REST API” tenant setting is scoped by identity only. If an application needs to query a semantic model for its users, every user must be granted API access. There is no way to say "you can use the API to get data from Fabric, but only through this application" - users may connect to Fabric using any external system they choose. Every other method of enforcing access restrictions (passing in effectiveUserName or impersonatedUserName in a service principal call) breaks onelake security.

Current workarounds and security solutions fail:

• A service principal with impersonatedUserName does not pass the user’s Entra identity to OneLake.
• An Entra user as a service account for impersonatedUserName passes the wrong Entra identity to Onelake, and additionally it is an anti-pattern that depends on interactive sign-in which is not suitable for enterprise applications.
• Some features (Private link, IP allow-lists, Azure API management, conditional access) can be configured to limit access to Fabric, but any setting that sufficiently restricts API access also negatively impacts protal access and/or functionality. For example - email distribution and on-premises data gateways are not compatible with tenant private links, workspace IP allow-lists limited to the external application would block legitimate inter-workspace traffic (if model and lakehouse are in different workspaces), and workspace private links explicitly do not support semantic models in the first place.

See forum thread for detailed discussion: Controlled "Semantic Model Execute Queries" REST API Access for Fabric Users | Microsoft Fabric Community

Request

Provide a supported way for an application to query a semantic model on behalf of a user such that:

1. Authorization to call the API is granted to the application, not to its users.
2. Data access is evaluated as the end user, using their real Entra identity, so OneLake security and SSO Direct Lake apply the same permissions they would in the portal.
3. The user cannot call the API from other clients unless they have been separately granted access.

How this is implemented — an OBO flow, a delegated token, a new tenant setting, or something else — is Microsoft’s call. The requirement is that the application is the authorized caller and the user is the effective identity.