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. One serves the interface people open in the Fabric portal, and one receives the calls Microsoft Fabric places itself. Both are described in the next section.
Permission type: Delegated only. Neither application holds an application permission, so neither has standing access of its own.
Administrator action required: Once, to add the workload. A Fabric administrator approves BI Pixie in the Workload Hub and chooses how widely it applies. None of the individual permissions below requires administrator consent.
How widely it applies: Your choice of the whole tenant, named capacities, or named workspaces. Named workspaces is the narrowest and is fully supported.
Personal data collected by default: None.
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 native Power BI elements, which are measures and table visuals, that 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.

Two BI Pixie applications, both expected

BI Pixie registers two Microsoft Entra applications, and both of them appear in your tenant. What separates them is who places the call, rather than how much access each one carries.

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.

The backend application is the one worth scrutinizing hardest, because Fabric places its calls, so here is its whole permission set. It 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.

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.

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.
`Capacity.Read.All`	View all capacities	BI Pixie reads which capacity a workspace runs on. That is how you are told before a benchmark starts that a trial capacity cannot run one.
`Notebook.Execute.All`	Execute notebooks	BI Pixie runs the BI Pixie ETL notebook, and only when somebody clicks Refresh data. That notebook is what turns 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 reads from 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 in order to score 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 the AI provider BI Pixie works through. An organization that uses Azure AI Foundry or another AI provider instead never reaches it.
`MLModel.Execute.All`	Execute ML models	BI Pixie uses this permission only when somebody chooses Copilot in Power BI 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 in Power BI 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 in Power BI 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. An AI Readiness assessment is computed from that structure, and it 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. It runs for a benchmark that a person set up and started, and at no other time. It does not read a table in full, and it does not copy your data. It asks four narrow questions of it.

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.

Inside Microsoft Fabric those results rest in your own OneLake, alongside the telemetry, so they stay in your tenant. 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 clicks 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.

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

BI Pixie collects no personal data by default. 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. People are identified by a hash. Named identity capture, filtered values and IP retention are each an explicit setting, 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, and a person starts each of them: the BI Pixie ETL notebook when someone clicks Refresh data, a semantic model refresh when someone asks for one, and a benchmark against your own Fabric data agent.

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 can rest in your own OneLake, in a container in BI Pixie's Azure that no other customer can reach, or, on the Enterprise plan, in your own Azure Data Lake account. See Data Residency for the three options and how to choose between them.

Who approves what

Adding a workload to a tenant is an administrator's action in Microsoft Fabric, so the Workload Hub asks a Fabric administrator to approve at that point. 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.

None of the permissions in the table above requires an administrator, by Microsoft's own classification. BI Pixie reads through whoever is signed in, so it never reaches further than that person can already reach.

If your tenant restricts which applications people may consent to, that restriction is your own Microsoft Entra policy rather than something BI Pixie asks for, and your organization decides who approves.

Reviewing and revoking access

Open the Microsoft Entra admin center, go to Enterprise applications, and search for BI Pixie. Both applications listed above appear there, and you can confirm each one by its application ID.
Open the Permissions blade on either application to see exactly what has been consented to in your tenant.
To remove the access, delete both 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.

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.