Execute DAX Queries REST API (Preview)

Thanks kayu, that distinction makes sense, and I agree that customData itself should not be treated as a security boundary 🔐

In my architecture, the end user never has access to the Power BI REST API and never supplies customData directly. The client only authenticates to my backend. The backend validates the signed-in user, resolves the allowed tenant and user context server-side, and then sets effectiveUsername and customData when calling Execute DAX Queries.

So the security boundary is the application backend plus Power BI RLS, not customData as a user-controlled input.

I am currently validating two variants:

1. Generic RLS identity plus CUSTOMDATA() 🧩

SPN calls Execute DAX Queries.

effectiveUsername is a generic identity assigned to the RLS role.

customData carries the tenant or user key.

RLS filters on CUSTOMDATA().

This is attractive for multi-tenant SaaS because it avoids creating and assigning every external user in the model.

2. Real Entra External users as effectiveUsername 👤

SPN still calls Execute DAX Queries.

effectiveUsername is the actual external user identity.

RLS uses USERPRINCIPALNAME(), USERNAME(), or a user mapping table.

This gives stronger identity traceability and aligns more closely with traditional Power BI RLS, but adds more identity lifecycle overhead.

Would Microsoft consider both patterns valid for embedded/app-owns-data scenarios, assuming:

✅ The SPN has the required workspace and model permissions

✅ The effective user is assigned to the relevant RLS role

✅ customData is resolved server-side and never accepted from the client

✅ All DAX execution is performed only by the backend

✅ Audit logs record user, tenant, effectiveUsername, customData hash, and query metadata

Also, is there a preferred or recommended pattern between these two for multi-tenant embedded SaaS?

Finally, for the Microsoft-hosted Power BI MCP server: is there any plan to expose effectiveUsername, customData, and roles on ExecuteQuery-like tools? Without those parameters, it seems difficult to support secure embedded LLM chat scenarios end-to-end through the hosted MCP server.

Thanks again for the clarification and for forwarding the feedback to the AI/MCP teams 🙏

Be

Marius 🙂🙂