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.
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.
Personal data collected by default: None.
Where an AI Readiness assessment runs: On BI Pixie's infrastructure, not on your Fabric capacity.
Revoking access: 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 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.

One application

BI Pixie Cloud registers a single Microsoft Entra application. It appears in your tenant as BI Pixie, with the application ID 114a7e20-3796-4ddd-ab99-568a78b7759b. Anything else carrying the BI Pixie name in your tenant came from the Fabric workload rather than from the web portal, and the workload permissions page covers that case.

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 at the Connect Power BI click, which is the point at which somebody 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, at the click 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. Three choices account for all of them, which are installing the BI Pixie Dashboard into one of your Fabric workspaces, picking which AI a benchmark works through, and keeping BI Pixie data in your own storage. A customer who declines all three and uses BI Pixie for Pixies and AI Readiness alone is never asked for any of these permissions.

Permission	Why BI Pixie needs it
`App.Read.All`	BI Pixie finds your BI Pixie Dashboard app, so that the portal 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 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.
`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 the AI provider BI Pixie works through. An organization that uses Azure AI Foundry or another AI provider instead is never asked for it.
`MLModel.Execute.All`	Optional. This permission is requested 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_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. 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, 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 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.

Those 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 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 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.

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. Two things do run on your capacity, and a person starts each of them: the BI Pixie ETL notebook when somebody clicks 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 it is on, 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.

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 remove the access, delete the enterprise application. Any individual can also revoke their own consent from myapps.microsoft.com without involving anyone else.

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.