Permissions and Data Access

This article describes every Microsoft Entra ID permission that BI Pixie Cloud requests, 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. People sign in at app.bipixie.com with their Microsoft work account, and BI Pixie then works against the Power BI and Fabric content that person can already reach.

Summary

Applications registered in your tenant: One, named BI Pixie. A second, BI Pixie Delivery, appears only if your organization keeps BI Pixie data in its own Azure storage, and it holds no Microsoft permission.
Permission type: Delegated only. BI Pixie holds no application permission, so it has no standing access of its own.
Administrator consent required: No. Microsoft classifies every permission below as one a person may consent to for themselves. A tenant that turns user consent off is the case where an administrator approves instead.
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.
Revoking access: You delete the enterprise application in Microsoft Entra ID. Any individual can also revoke their own consent without involving anyone else.

This article covers one subject, which is what BI Pixie Cloud 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

BI Pixie Cloud registers one Microsoft Entra application that everybody uses. It appears in your tenant as BI Pixie, with the application ID 114a7e20-3796-4ddd-ab99-568a78b7759b, and every permission on this page belongs to it.

A second application, BI Pixie Delivery, with the application ID b9a54fce-ed14-40d4-9669-10d691e2e3b8, appears only if your organization keeps BI Pixie data in its own Azure Data Lake Storage account. BI Pixie reads your telemetry from that account at times when nobody is signed in, so that work cannot run under a person's token and has an application of its own. 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. You assign it a role on your events container yourself, either Storage Blob Data Reader, or Storage Blob Data Contributor if you also want to delete data from the portal, and it can read only what that role allows. See Bring Your Own Storage.

Anything else carrying the BI Pixie name in your tenant came from the Fabric workload rather than from the web portal. The workload permissions page lists those applications and explains the separate approval a Fabric administrator gives.

Every permission below 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 token of a person who signed in, and a delegated permission is bounded by that person, so BI Pixie reaches only the workspaces they can already open in Power BI, under the 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.

Asked when you sign in

Permission	Why BI Pixie needs it
`openid`, `profile`, `email`	Sign in with Microsoft Entra ID. There is no BI Pixie password and no separate registration form.
`User.Read` (Microsoft Graph)	BI Pixie reads the signed-in person's own name, email address, company and job title. It reads no other person's profile.
`access_as_user` on BI Pixie's own API	BI Pixie calls its own service as the person who is signed in, so that every request carries their identity.

Asked when you connect Power BI

Signing in gives BI Pixie no access to your Power BI content. The three permissions below are requested when somebody selects Connect to Power BI, which is the point at which that person chooses to let BI Pixie see their reports.

Permission	Why BI Pixie needs it
`Workspace.Read.All`	BI Pixie lists the workspaces and reports the signed-in person can already reach, so that they can choose one.
`Report.ReadWrite.All`	BI Pixie reads the definition of a report and writes the Pixies into the report someone selects. Microsoft's own API requires the write permission even to read a report definition, which is why the read half cannot be requested on its own.
`SemanticModel.ReadWrite.All`	BI Pixie reads the structure of a semantic model to score its AI Readiness, and writes back the descriptions somebody reviews and approves. Microsoft's API requires the write permission to read a semantic model definition too.

Asked at the moment a feature needs it

BI Pixie asks for the remaining permissions one feature at a time, when somebody first selects the action that needs them. Somebody who never opens a benchmark is never asked for the benchmark permissions, and approving one prompt grants nothing beyond what that prompt listed.

Rows marked Optional are requested only if somebody chooses the feature or the option behind them, and each of those rows names the choice. Five choices account for all of them: installing the BI Pixie Dashboard into one of your Fabric workspaces, picking which AI a benchmark works through, benchmarking a lakehouse or a warehouse, choosing a Fabric data agent as your AI, and keeping BI Pixie data in your own storage. A customer who makes none of these choices and uses BI Pixie for Pixies and AI Readiness alone is never asked for an Optional permission.

Permission	Why BI Pixie needs it
`App.Read.All`	BI Pixie finds your BI Pixie Dashboard app, so that BI Pixie can offer somebody a link straight to that dashboard inside Power BI. It searches by name among the apps the signed-in person can already open, keeps the ones named BI Pixie, and drops the rest without storing them. Navigation to the dashboard is the only thing BI Pixie does with this permission.
`Dataset.Read.All`	BI Pixie uses this permission for two things. It reads engagement counts from the BI Pixie semantic model, so that it ranks AI Readiness findings by how much your reports are actually used rather than guessing at what matters. It also runs the queries a benchmark needs against the semantic model somebody chose to benchmark, which are set out under What a benchmark queries below.
`Item.ReadWrite.All`	Fabric uses this scope for creating and reading items, and BI Pixie needs it in three places. It installs the BI Pixie Dashboard into the workspace somebody chooses, which means creating a lakehouse, the notebooks that process your events, a semantic model and a report. It creates the test data agent a benchmark asks its questions to, and publishes a data agent someone selected. It also reads the run history of the BI Pixie ETL notebook, which is how you are told when your data was last refreshed.
`Notebook.Execute.All`	Optional. BI Pixie runs the BI Pixie ETL notebook, and only when somebody selects Refresh data. 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.
`Notebook.Read.All`	Optional. BI Pixie reads the run history of the BI Pixie ETL notebook. It uses this permission for one thing only, which is to tell you when your data was last refreshed.
`OneLake.ReadWrite.All`, `Workspace.ReadWrite.All`, `Connection.ReadWrite.All`	Optional. BI Pixie installs the BI Pixie Dashboard into the Fabric workspace someone chooses. These three cover writing the telemetry shortcut, placing the items in the workspace, and creating the connection the dashboard reads through. The items themselves are created under `Item.ReadWrite.All` above.
`Capacity.Read.All`	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.
`DataAgent.Execute.All`	Optional. 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. It is requested 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 is never asked for it.
`MLModel.Execute.All`	Optional. This permission is requested 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_impersonation` on Azure SQL Database	Optional. This permission is requested only when somebody benchmarks a lakehouse or a warehouse rather than a semantic model. BI Pixie uses it to calculate the benchmark's correct answers through that item's SQL endpoint, as the signed-in person. Each person grants it for themselves.
`user_impersonation` on Azure Storage	Optional. This permission is requested only where your organization has chosen to keep BI Pixie data in your own storage rather than in ours. Under that choice, BI Pixie writes the benchmark questions into your own OneLake using the signed-in person's own token, so that they stay in your tenant. On the default setup the questions rest in BI Pixie's Azure and this permission is never requested. The Data Residency page sets out the three options and how to choose between them.

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.

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, reports and capacities the signed-in person can already reach. BI Pixie fills the pickers in the portal 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, lakehouse or warehouse 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 storage where your organization has chosen that. The Data Residency page sets out the options and how to choose between them.

What BI Pixie writes, and when

Every write below follows an action a person takes in the portal, 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 Fabric 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. Two things do run on your capacity, and a person starts each of them: the BI Pixie ETL notebook when somebody selects Refresh data, and a benchmark against your own Fabric data agent.

Your engagement telemetry rests in a container in BI Pixie's Azure that belongs to you alone and that no other customer can reach, encrypted in transit and at rest. On the Enterprise plan you can keep it in your own Azure Data Lake account instead, and inside Microsoft Fabric it can be delivered to your own OneLake. See Data Residency for the three options and how to choose between them.

Who approves what

Most people can approve what BI Pixie asks for themselves, because Microsoft classifies every permission on this page as one a person may consent to. BI Pixie reads through whoever is signed in, so it never reaches further than that person can already reach.

In the ordinary case, Microsoft shows you the permissions BI Pixie is asking for, you accept them for yourself, and nobody else in your organization is affected by your answer. Because BI Pixie asks one feature at a time, you also see a short list each time rather than one long list at the start.

Some tenants turn user consent off. That is a setting in your own Microsoft Entra tenant rather than something BI Pixie asks for, and where user consent is off, Microsoft shows Need admin approval or the error AADSTS65001 in place of the consent dialog. 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 everything they would be approving and why each item is needed.

A tenant that also adds BI Pixie from the Fabric Workload Hub meets one more approval, given by a Fabric administrator in Microsoft Fabric, for different applications. The workload permissions page explains both approvals and the order they come in.

Reviewing and revoking access

Open the Microsoft Entra admin center, go to Enterprise applications, and search for BI Pixie. Confirm it by the application ID above.
Open the Permissions blade to see exactly what has been consented to in your tenant, and by whom.

To revoke access:

To remove BI Pixie's access, delete the enterprise application. Any individual can also revoke their own consent from myapps.microsoft.com without involving anyone else.
If your organization keeps BI Pixie data in its own Azure storage, BI Pixie Delivery appears in Enterprise applications too. To end its access, remove its role on your events container, or delete its enterprise application.

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.