Permissions and Data Access

This article describes every Microsoft permission that the BI Pixie workload requests inside a Microsoft Fabric tenant, why each one is needed, and what BI Pixie reads, writes and stores under it.

BI Pixie prepares Power BI semantic models for AI and measures how your reports are used. In Microsoft Fabric it is a workload published in the Workload Hub, so people create a BI Pixie item in a Fabric workspace and work with it inside the Fabric portal.

Summary

Applications registered in your tenant: Two in every tenant. One serves the interface people open in the Fabric portal, and one receives the calls Microsoft Fabric places itself. A third, BI Pixie Delivery, appears only if somebody turns on data residency for a license. All three are described in the next section.
Permission type: Delegated only. Neither workload application holds an application permission, so neither has standing access of its own. BI Pixie Delivery holds no Microsoft permission at all, and reaches only the one folder or container your organization grants it.
Administrator action required: A Fabric administrator approves BI Pixie once in the Workload Hub and chooses how widely it applies. Where your tenant has turned user consent off, a Microsoft Entra administrator also approves the BI Pixie applications, because your own tenant policy requires that. None of the individual permissions below requires administrator consent. See Who approves what below.
How widely it applies: Your choice of the whole tenant, named capacities, or named workspaces. Named workspaces is the narrowest and is fully supported.
Viewer user names collected by default: None. BI Pixie collects viewer user names only when you turn on Capture user identity, and until then it counts viewers by a masked IP address. When you turn it on, you choose on the Account page whether BI Pixie keeps each viewer's email address, a masked ID or nothing.
Where an AI Readiness assessment runs: On BI Pixie's infrastructure, not on your Fabric capacity.

This article covers one subject, which is what the BI Pixie workload asks your tenant for and what it does with that access. The Trust Center carries the wider security posture, including trust boundaries, encryption, storage access, sub-processors, and the same questions answered for the other three ways BI Pixie can be deployed.

Two terms recur below. Pixies are invisible tracking pixels native to Power BI. Each Pixie is a pixel-sized table visual with a hidden measure, which BI Pixie adds to a report in order to measure how it is used. No custom code or scripts are injected. AI Instructions are a Power BI feature rather than a BI Pixie one. They are the plain-language notes stored on a semantic model that tell an AI how to read it, and they belong to Microsoft's Prep data for AI. BI Pixie drafts AI Instructions for somebody to review, and writes only what that person approves.

The BI Pixie applications in your tenant

The BI Pixie workload registers two Microsoft Entra applications, and both of them appear in every tenant that adds it. What separates them is who places the call, rather than how much access each one carries. A third application, BI Pixie Delivery, appears only in a tenant where somebody turns on data residency, and it is described after the table.

BI Pixie Workload is the interface itself, which Fabric renders inside the Fabric portal. Every call it makes follows from something a signed-in person did in front of it, and it acts under that person's token.

BI Pixie Workload Backend receives the calls Microsoft Fabric places on its own, when somebody creates, deletes or restores a BI Pixie item in a workspace. Fabric sends those to a service endpoint rather than to a browser, so they arrive when no interface is open, and that is why a second registration exists. Microsoft's workload model requires the split: a Fabric workload declares a frontend application and a backend application in its manifest, and Fabric delivers item lifecycle calls only to the backend one.

Application	Application ID	What it does
BI Pixie Workload	`3e3c4859-980e-46a0-a3db-047ffb6f05c9`	The part people see. This is the workload user interface that Fabric renders inside the Fabric portal, and it acts under the token of whoever is signed in.
BI Pixie Workload Backend (prod)	`887dedf5-f34f-4b35-8d78-4f8719530df3`	The service Microsoft Fabric calls when somebody creates, deletes or restores a BI Pixie item in a workspace. Fabric places the call rather than the browser placing it, which is why it needs an application of its own. The word "prod" is part of the registered name and distinguishes it from the copy we use for our own testing.
BI Pixie Delivery	`b9a54fce-ed14-40d4-9669-10d691e2e3b8`	Appears only when somebody turns on data residency for a license. It delivers your engagement telemetry into your own OneLake, or reads it from your own Azure Data Lake Storage account, at times when nobody is signed in.

The backend application is the one worth scrutinizing hardest, because Fabric places its calls. The backend application holds exactly four Power BI permissions, Item.ReadWrite.All, Workspace.ReadWrite.All, OneLake.ReadWrite.All and Connection.ReadWrite.All, plus User.Read on Microsoft Graph. The frontend application holds all five of those as well, so the backend holds nothing that the frontend does not, and it holds none of the permissions that read semantic models, run notebooks or query data agents.

A lifecycle call still traces back to a person. Fabric places the call, but somebody creating, deleting or restoring a BI Pixie item in a workspace is what starts it, and the call carries that person's identity so that BI Pixie acts on their behalf and within what they can already reach.

BI Pixie Delivery exists for one job. When a license keeps its telemetry in your own storage, BI Pixie has to deliver events there, or read them from there, at any hour, including when nobody is signed in. That work cannot run under a person's token, so it has an application of its own. It is a separate application from the two above so that the access it needs is never added to the workload itself. It appears in your tenant only after somebody turns on data residency, either delivery to your own OneLake or storage in your own Azure Data Lake Storage account. See Data Residency.

BI Pixie Delivery holds no Microsoft permission. Its registration declares no API permission, and the consent somebody gives for it asks only for the sign-in permissions openid, profile and offline_access, which is what creates the application in your tenant. Everything it can reach comes from grants you can see and remove yourself:

For delivery to your own OneLake, the Viewer role on the workspace that holds the BI Pixie Dashboard, which on its own reads no data, and a OneLake security role that allows reading and writing one folder in that lakehouse, the folder whose name begins with bipixielake-. BI Pixie creates both when somebody turns delivery on, using that person's own access to the workspace. Nothing else in the workspace is open to it.
For your own Azure Data Lake Storage account, the role you assign it yourself on your events container, which is Storage Blob Data Reader in the Fabric workload. See Bring Your Own Storage.

The permissions BI Pixie requests

In the table below, the middle column is the wording Microsoft shows in the consent dialog, so you can match each row against what you are looking at. BI Pixie asks for several of these permissions at the moment somebody opens the feature that needs them, rather than asking for all of them at once.

The permissions usage tracking needs. Adding Pixies to your reports and seeing how people use them in the BI Pixie Dashboard needs only these: Fabric.Extend, Item.ReadWrite.All, Workspace.ReadWrite.All, OneLake.ReadWrite.All, Connection.ReadWrite.All and User.Read. When somebody first opens BI Pixie, it asks for those and no others, whether or not your licenses use data residency. Every other permission in the table belongs to an optional feature, and BI Pixie asks for it only when somebody uses that feature.

An administrator of your BI Pixie account can turn three optional features off for everyone in the account, under Features and data kept on the Security tab of the Account page: Add Pixies, Capacity details and AI features. BI Pixie never asks anyone for a permission that only a turned-off feature uses. With Capacity details off, nobody is asked for Capacity.Read.All. With AI features off, nobody is asked for the permissions that AI Readiness, benchmarks, A/B tests and data agents use.

Permission	Wording in the dialog	Why BI Pixie needs it
`Fabric.Extend`	Extend Fabric with new item types	Microsoft requires this permission of every Fabric workload. Without it, BI Pixie cannot run inside the Fabric portal at all.
`Item.ReadWrite.All`	Make API calls that require read and write permissions on all Fabric items	BI Pixie reads the items you point it at, such as a report you add Pixies to or a semantic model you assess, and writes back the changes you approve. The descriptions and AI Instructions written into a semantic model go through this permission. It is also what creates items on your behalf: the lakehouse, the notebooks that process your events, the semantic model and the report that make up the BI Pixie Dashboard, and the test data agent a benchmark asks its questions to.
`Workspace.ReadWrite.All`	Read and write all workspaces	BI Pixie installs the BI Pixie Dashboard and its semantic model into the workspace you choose.
`OneLake.ReadWrite.All`	Make API calls that read and write OneLake metadata	BI Pixie writes your engagement telemetry into your own OneLake. That is the storage option which keeps the telemetry inside your Fabric tenant.
`Connection.ReadWrite.All`	Make API calls that require read and write permissions on all Fabric connections	BI Pixie creates the one connection that the BI Pixie Dashboard reads your telemetry through, when that telemetry rests in BI Pixie's storage or in your own Azure Data Lake Storage account. A license that delivers its telemetry to your own OneLake needs no connection when the dashboard is installed into that same lakehouse, because the dashboard reads the telemetry where it already rests. BI Pixie still asks for this permission when somebody first opens it, because it cannot know in advance where each license keeps its telemetry, and because turning data residency off for a license creates the connection again.
`Capacity.Read.All`	View all capacities	This permission is optional. BI Pixie uses it to check whether a capacity is paused before it adds Pixies, runs an assessment or starts a benchmark. BI Pixie asks for it only when somebody selects Grant access on the benchmark, and never when somebody first opens BI Pixie. Without it, BI Pixie adds Pixies as usual and skips the paused-capacity check, so a paused capacity is reported when the work fails rather than before it starts.
`Notebook.Execute.All`	Execute notebooks	BI Pixie runs the BI Pixie ETL notebook when somebody selects Refresh data. The first time somebody does, BI Pixie also gives that notebook a daily schedule in your workspace, which Fabric then runs and which you can change or remove there. BI Pixie uses that notebook to turn the raw events your Pixies collected into tables you can report on: it reads the events from OneLake and writes them into the lakehouse in your own workspace, which belongs to you. The dashboard is built on those tables. The ETL notebook is the only notebook BI Pixie runs, and BI Pixie installed it.
`Dataset.ReadWrite.All`	Read and write all datasets	BI Pixie refreshes a semantic model when someone asks for a refresh.
`Dataset.Read.All`	View all datasets	BI Pixie reads a semantic model to assess its AI Readiness, and reads engagement counts from the BI Pixie semantic model so that it ranks findings by how much your reports are actually used.
`Workspace.Read.All`	View all workspaces	BI Pixie lists the workspaces and the items inside them so that someone can choose which one to work on.
`DataAgent.Execute.All`	Execute data agents	BI Pixie asks your Fabric data agent the benchmark questions you approved, which is how a benchmark measures whether the answers coming back are right. BI Pixie uses this permission only when somebody picks a Fabric data agent, either as the AI a benchmark tests or as your AI. An organization whose AI is Azure AI Foundry, OpenAI, or Anthropic instead never reaches it.
`MLModel.Execute.All`	Execute ML models	BI Pixie uses this permission only when somebody chooses Copilot as the AI to test, and nothing else in BI Pixie uses it. BI Pixie reaches Copilot through Microsoft's remote Power BI MCP server, and this permission authorizes its Generate Query tool, which is the same engine Copilot uses to turn a question into a DAX query. Two things about that server are Microsoft's rather than ours. It requires a Copilot license, and your administrator has to enable the tenant setting named Users can use the Power BI Model Context Protocol server endpoint (preview). Where that setting is off, Copilot cannot be benchmarked at all, whatever BI Pixie has been granted.
`User.Read` (Microsoft Graph)	Sign you in and read your profile	BI Pixie reads the signed-in person's own name, email address and company, so that the account and the audit trail name a real person.

Every one of these is a delegated permission. BI Pixie holds no application permission in your tenant, so it has no standing access of its own. Everything BI Pixie reads or writes happens under the identity of a person, and a delegated permission is bounded by that person, so BI Pixie reaches only the workspaces they can already open in Fabric, under the workspace roles you granted them, even under a permission whose name reads "all workspaces".

One feature runs without anybody present, and it stays inside that same boundary. On the Enterprise plan, somebody in your organization can put an AI Readiness assessment on a schedule, and BI Pixie then runs that assessment at the time they chose. An assessment is read-only, so a scheduled run changes nothing in your tenant. See Schedules.

One permission is broader than what BI Pixie does with it. Microsoft offers a narrower scope for each Fabric item type, and BI Pixie asks for the single Item.ReadWrite.All umbrella in place of three of them, because it shortens the consent dialog and lets Microsoft reuse one grant across the features that need it. The consequence is that the permission BI Pixie holds would allow it to create item types it never creates. What it does create is listed in the table above, and it creates nothing in a workspace nobody selected.

Microsoft's older Dataset permission names refer to semantic models. Dataset.Read.All and Dataset.ReadWrite.All are the same objects that Fabric now calls semantic models, and Microsoft has kept the older names on the permissions.

What BI Pixie reads

The structure of a semantic model someone selects. Its tables, columns, measures, relationships and descriptions. BI Pixie computes an AI Readiness assessment from that structure, and does not read the rows in your tables.
The definition of a report someone adds Pixies to. BI Pixie reads that report definition, adds the Pixies, and writes the report back.
The workspaces, items and capacities the signed-in person can already reach. BI Pixie fills the pickers in the product from that list.
Engagement counts from the BI Pixie semantic model. These are the counts your own Pixies collected, and BI Pixie ranks findings by them rather than guessing at what matters.

What a benchmark queries

A benchmark is the one feature that queries your business data, and it queries only the semantic model somebody chose to benchmark. BI Pixie queries it only while a benchmark that a person set up and started is running. BI Pixie does not read a table in full or copy your data, and it asks four narrow questions.

Can this semantic model be queried at all. Before a benchmark starts, BI Pixie runs one query that evaluates the number 1. It reads none of your data. It is there so that a benchmark that cannot run stops immediately with a reason somebody can act on, rather than part of the way through.
What is the latest date in one table. When a question is anchored to a period, BI Pixie reads the most recent date in the table that question is about, so that the question names a window with data in it rather than an empty one. Each of these queries returns one value.
What are five common values in one column. When a question needs to name a real value, such as a product or a region, and your Data Selections did not supply one, BI Pixie reads the five most frequent values in that column and picks one to put in the question.
What is the correct answer to this question. BI Pixie calculates the answer from your data, usually a single number and sometimes a short list of names, so that it can tell a right answer from a confident wrong one. It keeps the answer, not the rows the answer was calculated from.

Every result is bounded before BI Pixie keeps any of it. A query returns at most 100 rows and at most 256 KB, whatever the semantic model would otherwise have returned, and a benchmark carries at most 100 questions. What is stored at the end of a run is the question, the correct answer BI Pixie calculated, and the answer the AI gave, which is what a score is computed from and what lets somebody see why a question was marked wrong.

Benchmark results rest in the same place as the rest of your BI Pixie data, which is a container in BI Pixie's Azure that belongs to you alone, or your own OneLake when your organization has turned on data residency. See Data Residency.

What BI Pixie writes, and when

Every write below follows an action a person takes in the product, and none of them happens on a schedule.

Pixies into a report, when somebody selects Add Pixies on that report. No custom code or scripts are injected.
Descriptions and AI Instructions into a semantic model, when someone reviews a proposed optimization and applies it. Each proposed change is shown before it is written.
The BI Pixie Dashboard items into the workspace someone chooses, when they install the dashboard. Those items are a lakehouse, notebooks, a semantic model, a report and a connection, and they belong to you once they exist.
A Fabric data agent, when someone asks BI Pixie to create a test data agent for a benchmark. This is a user-triggered action and it never happens on its own.
A survey or feedback table into a report's semantic model, when somebody turns on surveys, or feedback on all pages, for that report and adds or updates its Pixies.

Assessing a semantic model writes nothing. An AI Readiness assessment is read-only, and nothing reaches the semantic model until someone reviews an optimization and applies it.

What BI Pixie collects

Through the Pixies added to a report, BI Pixie records how that report is used, which means page views, visual clicks, filter selections, bookmark navigation, tooltip views, drill-through actions, survey responses and feedback. BI Pixie collects viewer user names only when you turn on Capture user identity, and until then it counts viewers by a masked IP address. When you turn it on, you choose on the Account page whether BI Pixie keeps each viewer's email address, a masked ID or nothing. Filtered values and IP retention are each an explicit setting as well, and each one stays off until somebody in your organization turns it on.

BI Pixie does not mine your telemetry, does not train AI models on it, and does not use it for advertising or profiling. Retention is a setting you control, and events past your retention window are deleted daily. The maximum you can set depends on your plan: 30 days on the Free and Standard plans, one year on the Pro plan, and three years on the Enterprise plan. The Privacy Policy carries the full description of what is collected and how long it is kept.

Where the work runs

An AI Readiness assessment runs on BI Pixie's infrastructure, not on your Fabric capacity. Three things do run on your capacity: the BI Pixie ETL notebook, a semantic model refresh when someone asks for one, and a benchmark against your own Fabric data agent. The ETL notebook runs when someone selects Refresh data, and after that on the daily schedule that BI Pixie gives it the first time.

The workload user interface is served from BI Pixie's infrastructure and rendered inside the Fabric portal. The BI Pixie Dashboard items live in your Fabric workspace under your own Fabric permissions. Your telemetry rests in a container in BI Pixie's Azure that no other customer can reach, or, on the Enterprise plan, in your own OneLake or your own Azure Data Lake account. See Data Residency for the three options and how to choose between them.

Who approves what

BI Pixie can meet two separate approvals in your organization, in two different admin centers, and they are often given by two different administrators. The first always happens. The second happens only where your own tenant policy asks for it.

First, a Fabric administrator approves the workload. Adding a workload to a tenant is an administrator's action in Microsoft Fabric, so the Workload Hub asks for it there, on the BI Pixie tile, and the result is visible afterwards in the workload settings of the Fabric Admin portal. Fabric offers three widths for that decision and you pick one: the whole tenant, named capacities, or named workspaces. Adding BI Pixie to a few workspaces first is fully supported and is the narrowest of the three. See Add BI Pixie to Your Tenant for the steps.

Then, each person approves the permissions for themselves. The Fabric approval makes BI Pixie available, but it does not consent to the permissions in the table above. Microsoft asks for that consent in Microsoft Entra ID, the first time a person opens BI Pixie and again when they first use a feature that needs a further permission. None of those permissions requires an administrator, by Microsoft's own classification, so in the ordinary case each person accepts them for themselves and nobody else in your organization is affected by the answer. BI Pixie reads through whoever is signed in, so it never reaches further than that person can already reach.

Some tenants turn user consent off. That is a setting in your own Microsoft Entra tenant rather than something BI Pixie asks for, and it is the case where a Microsoft Entra administrator gives the second approval. Where it is on, Microsoft shows Need admin approval or the error AADSTS65001 in place of the consent dialog, even though a Fabric administrator has already added BI Pixie. If you reach that message, your organization has already decided that an administrator approves on your behalf, and this page is the one to forward them. It lists every BI Pixie application that can appear in your tenant, everything they would be approving, and why each item is needed. The same applies to BI Pixie Delivery when somebody turns on data residency.

People who use BI Pixie through the web portal rather than through Fabric meet only the Microsoft Entra approval, for a different application. The BI Pixie Cloud permissions page covers that case.

Reviewing and revoking access

Open the Microsoft Entra admin center, go to Enterprise applications, and search for BI Pixie. Both workload applications listed above appear there, and so does BI Pixie Delivery if somebody turned on data residency. You can confirm each one by its application ID.
Open the Permissions blade on either workload application to see exactly what has been consented to in your tenant.
To remove the access, delete both workload enterprise applications. Deleting only the frontend one leaves the lifecycle application in place. To stop new BI Pixie items being created without removing anything, open the Workload Hub and narrow or remove BI Pixie's distribution scope.
To remove BI Pixie Delivery's access, remove its OneLake security role in the lakehouse or its role on your storage container, or delete its enterprise application. BI Pixie then has no access to that storage. For delivery to your OneLake, the Data residency card in BI Pixie shows an access issue, so that whoever manages the account knows delivery has stopped.

Because every token operation goes through Microsoft Entra, the Conditional Access policies your tenant applies are evaluated on every BI Pixie session. Those include multi-factor authentication, compliant-device requirements, named locations, sign-in risk and session controls.