Forum Discussion
Copilot in embedded Power BI reports via iframe
Hello collegues,
We are looking into enabling Copilot for Power BI reports embedded in our web application via iframe, but we want to make sure we test it safely before enabling anything in production.
Our embedded reports are customer-facing and use Row-Level Security to keep each customer’s data separate. Some reports may also contain business data and PII.
Our intended approach is to use a dedicated demo workspace, create two demo customer accounts, configure RLS so each account can only access its own customer data, and then test Copilot inside the embedded iframe report. We want to confirm that Copilot only uses data available to the signed-in user and cannot return data from another customer’s scope.
We would like to understand:
1. What settings are required to enable Copilot inside embedded Power BI reports via iframe?
2. Can Copilot be enabled only for the demo workspace, selected reports, and selected demo users?
3. If we enable the required tenant/capacity data processing setting, could Copilot become available to other embedded reports or users outside the demo workspace?
4. Does Copilot fully respect RLS and Azure AD identity when the report is accessed through an embedded iframe?
5. Is this demo workspace + two demo accounts + RLS test a valid approach to verify customer data isolation?
6. Are there any additional security checks or limitations we should consider before moving to production?
What is the best approach for such task?
I would appreciate any help!
Thanks!
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
5 Replies
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
Hi @nick_leshkevich,
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
Hi 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...
Your test plan looks like the right approach. I would start with a dedicated workspace/capacity, limited users, and sample data with RLS enabled. Test with multiple demo accounts and include negative scenarios (for example, asking Copilot about another customer’s data) to confirm isolation.
Also review tenant and workspace Copilot settings carefully, because enabling tenant-level features can affect availability beyond your pilot scope. Validate permissions, sensitivity labels, audit logs, and semantic model security before moving to production.
A controlled pilot is the safest way to confirm Copilot behavior with embedded reports and customer-facing data.
