Forum Discussion
Copilot in embedded Power BI reports via iframe
Hi nick_leshkevich,
Thank you for reaching out to Microsoft Fabric Community.
Your approach is correct to validate the behaviour before enabling copilot in production.
- Copilot for embedded reports is currently supported only in User Owns Data (embed for your organization) scenarios. If your application uses the App Owns Data embedding model like for example using a service principal or master user, copilot in embedded reports is currently not supported.
- If you are using user owns data, copilot respects the signed in user's permissions, including RLS. Using a dedicated demo workspace with test users and RLS configured for separate customer data is the recommended way to verify that each user can access only their own data before rolling it out to production.
Thanks and regards,
Anjan Kumar Chippa
Hi nick_leshkevich,
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution I have provided for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa
Resolver IVHi Nick,
Worth pinning down your embed model before you build the test, because it decides most of the answers above.
Anjan's point is the crux: Copilot in embedded reports only works in user-owns-data. If your app is customer-facing and you're generating embed tokens with a service principal or master user plus an effective identity for RLS, you're on app-owns-data and Copilot won't attach at all. In that case the demo workspace with two AAD test users would validate a path you don't actually run in production, so it wouldn't tell you much.
A few things on the rest:
The Copilot and "data sent to Azure OpenAI" switches live at tenant level. You can scope them to a security group, but not to a single workspace or report. So "only for the demo workspace" isn't really a thing. Scope it to a security group containing your two demo accounts and you get close enough.
On RLS: in user-owns-data Copilot queries the model as the signed-in user, so row filters do apply. But RLS filters rows, not columns. Any PII column the user can already see is fair game for a Copilot answer. If you have PII in the model, hide those columns or point Copilot at a separate semantic model that doesn't carry them. That's the check I'd add to your list, not just cross-customer isolation.
We ran into exactly this at DataTako, where reports are embedded app-owns-data so viewers don't need a Pro or PPU license. Copilot simply isn't available in that setup. What we ended up doing is building a custom agent on top of the semantic model with Azure AI instead. It generates DAX and executes it against the model under the same identity the embed token carries, so RLS is enforced by the model itself rather than by the chat layer, and we get to whitelist which tables and columns the agent may touch. More work than flipping a tenant switch, but it's the only route we found that works in app-owns-data and keeps PII out of scope by design.
Which embed model are you on? If it's user-owns-data, your test plan is fine with the column caveat added. If it's app-owns-data, happy to go into how we wired up the agent...