Everything that crosses the boundary, and nothing else

We publish exactly which metadata is transferred from your tenant, and we separate the required minimum from the optional items. This is the complete list. If something is not on it, we do not receive it.

What has and has not been checked

The transfers below are described from the setup script's source and the worker's design. They have not yet been checked against an observed run. We say so here rather than leave it for you to discover, because you are entitled to know which claims are verified and which are not. If you find something crossing the boundary that is not listed here, that is a defect in the product, not an omission in this page: please report it.

How it connects

A small collection worker runs in your own Azure subscription. The setup script you run creates it, and creates the managed identity it runs as, with read-only grants. There is no app registration and no client secret; nothing of yours is handed over. The worker connects out to Fabric Control over HTTPS, in short calls, and nothing ever connects in. Every result it sends is on this page.

What the setup script sends, once

Item	Required?	Why it is needed	Is it secret?
The worker's public key	Required	The platform tells your worker apart from every other customer's by checking which registered key verified a signature. Without it, your worker cannot be identified at all.	No. A public key is the same class of object as the one in every TLS certificate your browser accepts.
The setup code you paste	Required	Binds this worker registration to your organization. Single-use, short-lived.	It is a credential, which is why it is never written to the worker job, a log or a transcript, and why the script takes it as a masked input.
The worker type being registered, and the signing algorithm (ES256)	Required	Tells the platform which worker this key belongs to and how to check its signatures.	No.
A token signed by the worker's key, on a re-run only	Required on a re-run	A re-run whose worker is already registered proves it holds the registered key, instead of using a second setup code, and reads what your plan includes. The token carries the key's ID, a random value used once, and a short expiry.	No. It is a signature, valid briefly and once; the private key itself is not sent.
The toolkit version	Optional	Sent so support can start from "which build are you running?" rather than a guess.	No.

The private half of the signing key is made on the workstation that runs setup and stored only in the worker job, as one of its secrets. It is not sent, not escrowed, and not recoverable by us. The worker has no other secret of yours: it signs in as its own managed identity, which has no password or key to send. A secret that is never sent to us cannot be intercepted on the way, and one we never held cannot be subpoenaed from us.

What the worker sends, once running

Item	Required?	Why	Is it your data?
Heartbeat and health state	Required	So the portal can tell "no workers" apart from "we could not ask".	No.
Running version and protocol version	Required	Version-combination support. The platform learns what is running from the worker, never from our scripts: a script that asserted it could be wrong.	No.
Configuration status: `config OK` or `config has a problem`, plus a problem code	Required	So the portal can tell you something needs attention.	Status only, never configuration content. The code is from a fixed vocabulary; it is not your values.
The inventory of your Azure estate	Required	The metadata the product exists to govern: inventory, cost and health.	Metadata about your estate, never its contents: subscription IDs, names, state and the directory each is in; resource-group and resource IDs, names, types, regions, SKUs and tags; each resource's management settings as Azure Resource Manager returns them, with definitions, bodies, payloads and containers' environment variables removed (a Logic App's trigger and action names are kept); storage container names and settings; daily cost per resource and meter; Azure Monitor metric values; and, for a resource whose detail could not be read, the error's text (for a refused or missing resource, its status and the address it called, which names the resource).
The inventory of your Fabric and Power BI estate	Required	The same.	Metadata about your estate, never its contents: capacity, workspace, domain, item and gateway IDs and names; the people the admin APIs name: capacity administrators and workspace members with their access (identifier, email address and display name), each item's creator, each semantic model's and refreshable's "configured by", and who shared a link with the whole organization; tenant settings, with the security groups they name; the data sources reports and gateways connect to (their type, server, database and path, and the credential type, never the credential); refresh and run schedules; refresh status and timing, with a failed refresh's error code and Power BI's error description, whose text can quote a value; run status, timing, and view and run counts from the activity log, its user identities removed before sending; lineage between items; sizes and table counts, and the names of each lakehouse's and warehouse's tables (with each lakehouse table's size; row counts are not collected yet); capacity usage and state changes; and, for a notebook whose definition could not be read for its language, the error's text (its status, or the address it called, which names the notebook).
Semantic-model definitions	Optional, by two tenant settings. Enhance admin APIs responses with detailed metadata returns the models' tables, columns and measures by name and description; … with DAX and mashup expressions, which needs the first, adds the DAX.	The semantic-model views: tables, columns, measures, relationships and roles.	Yes, model content: each model's tables, columns and their data types, its measures, its relationships and its security roles, as the scan returns them; with the second setting on, each measure's DAX and each role's DAX filter. The mashup (Power Query) queries the scan then also returns are dropped in your tenant. Never the rows of a table.
The problems the worker met	Required	So the portal and support can tell what failed, and whose step it is.	A fixed cause, a fixed label (for example `not-granted:capacity-metrics`), an HTTP status and the step Fabric Control asked for. Never an error message, which may name your objects.
Capacity telemetry endpoints	Optional: only when you set up capacity telemetry.	So Fabric Control knows which Eventstream to read for each capacity. The worker reads the telemetry itself, as its own identity.	No secret: for each capacity, its Fabric capacity ID and the endpoint's namespace, event hub and consumer group, as recorded in your worker job. Names only: the setup script drops the endpoint's access keys where they arrive, and no key is ever recorded or sent.
Your license key	Required for the licensed work in your plan; collection runs without it.	So the platform can tell that the worker asking for licensed work belongs to an organization whose plan includes it. The worker reads the key from its job's secrets at the start of each run and shows it with each request.	No. It is our signed statement of your plan, issued to you by the portal; it carries your organization's identifier and what your plan includes, and nothing from your tenant.

What never crosses, under any circumstance

Your data. The rows and files in your lakehouses, warehouses and semantic models, and the content of your items: notebook code, report and pipeline definitions, and Power Query (mashup) text. The worker reads names, settings, sizes and counts. The one exception is the optional semantic-model definitions above, which cross only when you turn their first tenant setting on, and their DAX only with the second.
Backup data. Backups move from your OneLake to your storage. The worker is never in the data path, which is why the platform cannot read a backup even in principle.
Any credential, secret, key or password of yours that Azure or Fabric holds as one: a secret reference, a key vault, a data source's credential (its type is sent, the credential is not). A secret written in plain sight is a different matter: in a container's command line or a health probe's header, or in a Logic App's plain parameter, it is sent with those settings. Keep secrets in secret references.
The user identities in the activity log. The worker removes them before it sends run and view counts. The people the admin APIs name, listed above, are sent.
Anything from your Key Vaults. The worker reads none of them.

Capacity telemetry endpoints are sent by name, and only when you set telemetry up: the worker reports the names recorded in your worker job, so Fabric Control can read your capacities' telemetry. The endpoints' access keys are never recorded or sent.

What is sent is described from the source; what is stored is the receiving side's. What the setup script and the worker send can be checked against their source, and is what the two tables above describe. Fabric Control stores that metadata to show it to you in the portal. If your review turns on the receiving side, ask us for that component's own statement rather than relying on this page.

How to verify this yourself, rather than trust it

You should not have to take our word for it, and the checks are yours to run:

Watch the traffic. The worker is outbound-only over HTTPS to a small, fixed set of hosts, each named in the prerequisites you receive with the toolkit, with who connects and what breaks without it. Proxy it, log it, inspect it.
Read the scripts. The toolkit is plain PowerShell, shipped as source, in your hands. There is no compiled step and nothing obfuscated. The preflight script in particular changes nothing and sends nothing: run it first and read what it does.
Check what we can reach. We hold no credential to your tenant. There is nothing for us to log in with.

Client-side checks are advisory by construction. You own the machine the worker runs on, with full administrative rights, and we design as though every client-side component will be read, modified and replayed by its host. That cuts both ways, and in your favor here: the same property that stops us relying on client-side enforcement is what lets you verify every claim on this page independently.

Opting out

The required minimum above is exactly what the product needs to function; there is nothing decorative in it. Optional items are marked as such and can be declined without breaking collection. Every optional grant is also listed in your portal, with what it unlocks and what stays unread without it, and you can remove any of them at any time.

If an item marked Required is unacceptable to your organization, that is a conversation worth having before deployment rather than after: please raise it with us.

Hand this page to your security team

It is the same list your reviewer receives with the toolkit. Then join the beta: no card, no data leaving your boundary.

Join the beta Read the security model