Permissions

Fabric Desktop by KratosBI never gets more access than the person using it. It signs in as you and can only do what your own Fabric workspace roles let you do. It has no app-level (application) permissions of its own.

There are two ways it signs in:

• Microsoft's Fabric sign-in (the default). Nobody registers an app, grants consent or types an app ID. Fabric Desktop by KratosBI signs in through the same Microsoft app that Fabric's own command-line tool (Fabric CLI, fab auth login) uses, which every Microsoft Entra tenant already trusts for Fabric and OneLake. On Windows it signs in through Windows itself (Web Account Manager), so you are often signed in with your Windows work account and see no prompt.
• Your organization's own app registration (optional). For organizations whose policy says every app must be registered in their own tenant, or that want to choose the exact permissions. See Using your own app registration.

The headless agent is separate: it runs unattended, so it signs in as a managed identity or service principal.

Microsoft's Fabric sign-in: what IT may need to check#

Nothing, in most tenants. These are the things that can stop it:

What each feature uses#

With Microsoft's sign-in, Fabric Desktop by KratosBI asks each Microsoft API for its default access (/.default), which Microsoft sets for the Fabric CLI app. The table says which API each feature calls. A feature that needs something Microsoft's app doesn't cover says so, and still works with your own app registration.

"Expected" means Fabric CLI itself does these things with the same app. None of it has been tried from Fabric Desktop by KratosBI on a live tenant yet.

Endorsement (Certified, Promoted) isn't shown in Fabric Desktop by KratosBI's own list, because it needs an admin-only permission. Fabric's admin API is used for two reads only, both by a Fabric administrator: domain names, when they choose Import from Fabric (the names are then kept in the platform, so nobody else needs that permission), and tenant settings, for the tenant settings history (kept in the central lakehouse, where people with access to it read the history without the admin role). The Fabric catalog embedded on the same page shows it.

Using your own app registration#

You only need this if your organization requires it. Everything below is optional.

1. Register the app. Entra admin center: App registrations > New registration, any name (for example Fabric Desktop). For people from one organization choose single tenant; for several, Accounts in any organizational directory. Under Authentication > Add a platform > Mobile and desktop applications, add the redirect URI http://localhost.
2. Add the delegated permissions below. API permissions > Add a permission, then Microsoft APIs, or APIs my organization uses if you search by name. Choose Delegated permissions each time.
3. Grant admin consent (optional). None of these permissions requires an admin, so people can consent for themselves at first sign-in if your tenant lets users consent to apps. If it doesn't, select Grant admin consent for (Global Administrator, Privileged Role Administrator or Cloud Application Administrator).
4. Give the app's ID to Fabric Desktop by KratosBI: see Rolling out to your organization.

With your own app, Fabric Desktop by KratosBI signs in with the browser (not Windows sign-in) and asks for each permission the first time a feature needs it.

The Fabric permissions are listed under Power BI Service in Entra, even though the app calls api.fabric.microsoft.com. Only add what your people will use: without a permission, the feature that needs it says which one, and everything else works.

"Could not grant admin consent. Your organization does not have a subscription (or service principal)..."#

Your tenant has never used one of those Microsoft APIs, so Entra has no local record (service principal) of it to grant consent against. New and developer tenants often lack Azure Storage and Azure Key Vault. Create the missing ones once, then grant consent again. With the Azure CLI, signed in as an admin (az login --allow-no-subscriptions):

"Already exists" or "already in use" means that one is fine. Creating them needs Application Administrator, Cloud Application Administrator or Global Administrator. If you'd rather not add Key Vault, remove its permission instead; consent then succeeds for the rest.

After adding a permission#

Sign in again so your token carries it: close the app, delete %LOCALAPPDATA%\FabricDesktop\msal_cache.bin, and open it again. (Otherwise it takes effect within an hour.)

Rolling out to your organization#

With Microsoft's sign-in there is nothing to roll out: people download the app and sign in. To use your own app registration instead, set its ID in one of these; the first one found wins, in this order:

Leave all of them empty to use Microsoft's sign-in.

policy.json can also fix the update channel, hide preview features, and say where Report a problem goes:

{
  "client_id": "00000000-0000-0000-0000-000000000000",
  "channel": "stable",
  "show_preview": false,
  "support_url": "mailto:data-platform@contoso.com"
}

Every key is optional; leave out client_id to keep Microsoft's sign-in. channel is stable or preview; support_url is an https:// link (a Teams channel, a ticket form) or a mailto: address.

Four more keys are for control rather than convenience:

An invalid file or key fails closed: a file that can't be read leaves each PC on the last copy it could read, or, on a PC that never read a valid one, turns off runs in Fabric, Preview features, telemetry and AI tools until it's fixed. Sign-in still works there, and allowed_tenants isn't enforced until the file is fixed, so check the file on a pilot PC first. A wrongly typed restriction takes its most restrictive value. The full table, what fails closed, and how to check the file was read, is in Configure Azure and Fabric.

People from more than one organization, with your own app. Make the registration multitenant. If an organization doesn't let users consent, its Microsoft Entra admin approves the app once with the link in Settings > Account > Admin approval (https://login.microsoftonline.com/organizations/adminconsent?client_id=<application-client-id>).

Updates. The newest green build of main goes to the Preview channel at once; when merges land close together, only the build of the last one is published, one publish at a time. The Stable channel, which everyone gets by default, only moves when someone runs Actions > Promote to stable with the notes people will see as What's new. With auto_update: false nothing moves until you roll out a new exe.

The headless agent#

The agent runs with nobody signed in, so it can't use a person's sign-in. A managed identity needs no app registration at all: use it when the agent runs on an Azure VM, Azure Arc server or container. Elsewhere it needs a service principal (an app registration with a certificate). Either way its registration needs no entries on the API permissions page: Fabric gives app identities what their workspace roles allow. Set up, in alphabetical order:

Schedules on a PC (Windows Task Scheduler) are different: they run as the person who set them up, with their saved sign-in, and need nothing here.

External AI tools#

People can connect AI tools they already use (Claude, Codex, Copilot, Cursor, any MCP client) to Fabric Desktop by KratosBI through Settings > Integrations. This asks for no new Entra permission: an AI tool works only through the app, which uses the person's own sign-in, so it can never do more in Fabric than the person can. The app never hands a tool a token. But Python a tool runs (after the person approves it) runs as the person, like any notebook, and today can read the person's token cache on the PC; treat approving it like running a script you were sent (see Security model). Integrations are off until the person switches them on, and IT can keep them off.

Each connected tool gets some of these categories, in alphabetical order:

Policy keys integrations, integrations_http, integrations_max_permissions and integrations_extensions (azure-setup.md) turn integrations off, cap the categories or limit which extensions can be turned on. Extensions add capabilities in these same categories; they add no new ones. The threat model is in ai-integration-security.md.

Keeping this page right#

When code asks for a new scope (sidecar/fabric_desktop/auth.py) or the agent needs a new role, add it to the tables here in its alphabetical place, in the same pull request, and say whether Microsoft's sign-in is expected to cover it.