powerbi v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-powerbi-bearer-token

Custody

customer_vault

Injection

header (Authorization)

A Microsoft Entra ID (Azure AD) access token for the Power BI API, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the access token. Token issuance is external: the deployment's custody job obtains tokens from the Microsoft identity platform token endpoint (login.microsoftonline.com/{tenant}/oauth2/v2.0/token) using a confidential client — a service principal authenticating with client credentials and requesting the single scope 'https://analysis.windows.net/powerbi/api/.default' — and writes the resulting token under this reference before expiry. Authorization honesty, corrected: for service principals Microsoft recommends assigning NO Power BI API permission scopes on the app registration — the documented scopes (Dataset.ReadWrite.All, Workspace.ReadWrite.All and similar) are DELEGATED permissions for signed-in-user flows and are never used by a client-credentials service principal, so this pack does not prescribe them as the SP's governing permissions. The service principal's real authorization is (1) the tenant setting 'Allow service principals to use Power BI APIs', which the tenant administrator must enable (optionally scoped to a security group containing the SP), and (2) a workspace role — Member or Admin for the write operations — on each workspace it governs; workspace assignment is the real blast-radius control. Expiry and revocation: access tokens are short-lived (about an hour) and an expired value fails closed with a 401; the custody job must refresh proactively — the injector injects the stored value verbatim and performs no token lifecycle itself. Note carefully, distinguishing issuance from authorization: disabling the app registration stops NEW token issuance, but removing the service principal from a workspace does NOT block issuance — tokens keep being minted while the app registration lives, and workspace removal only means a (still bearer-valid) token's calls against that workspace fail authorization. Already-issued tokens are never invalidated by either step and remain usable until they expire, so the token lifetime is the effective revocation window. Least privilege: with no API scopes on the app registration, least privilege is exercised through workspace roles — add the service principal to only the workspaces this integration governs, with the minimum role that covers the enabled capabilities, and restrict the tenant setting's allowed security group to the group holding this SP. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• powerbi-workspace (api, internal): https://api.powerbi.com/v1.0/myorg/groups/GROUP_ID
• powerbi-workspace-users (api, pii): https://api.powerbi.com/v1.0/myorg/groups/GROUP_ID/users

The endpoint host api.powerbi.com is a REAL shared service host — Microsoft's global Power BI API endpoint that serves every tenant — not a placeholder: do not substitute it, and do not treat its presence in the egress allowlist as an unsubstituted-pack marker. Tenant and data scoping come from the Microsoft Entra ID access token and the group (workspace) id in the path, not from the host. GROUP_ID, DATASET_ID and REPORT_ID in the paths are placeholders the deployment binds to concrete workspace and artifact ids before enabling; the /v1.0/myorg prefix is Power BI's documented tenant-relative root, and the registered capabilities address workspace-scoped operations only (My Workspace variants of the same operations are not registered). Tiering rationale: dataset refresh is registered with the deploy action at the R3 floor rather than as an ordinary execution — a refresh rewrites the data every report and dashboard built on the dataset serves to its consumers, which is deploy-equivalent; deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Adding a principal to a workspace is registered as share at the R3 floor: it grants a user, group or service principal a workspace role up to Admin, and the grant is effective until a separate removal call — an access grant cannot be un-granted by the call that made it. Documented exclusions — this pack does not register: the Admin APIs (tenant-wide as-admin scans and metadata export — organization-wide surveillance scope, a separate governance review); Post Dataset User and Put Dataset User (direct dataset-level permission grants — share-class, pending review); Take Over In Group (transfers dataset ownership to the calling user — transfer-class); Bind To Gateway In Group, Update Datasources In Group and Set All Dataset Connections In Group (gateway binding and data-source credential operations — credential-adjacent writes requiring their own review); the push/streaming dataset row endpoints (PostRows and friends — direct row writes into datasets); report clone, export and import; dataflow refresh and transactions; and GenerateToken (embed-token issuance — a credential-issuance operation, not a business capability). A documented exclusion, not an approximated capability. The Execute Queries capability is a POST-with-query-body endpoint used read-only: its body carries a DAX query and it changes nothing — see the capability's own note. Capacity behaviors documented by Microsoft are honest limits, not restrictions this pack imposes: shared capacities accept at most eight refreshes per dataset per day, and an enhanced refresh whose commitMode is partialBatch can leave the model partially loaded after a failure — Microsoft's own documentation advises transactional mode to preserve previous data.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://learn.microsoft.com/en-us/rest/api/power-bi/datasets (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/get-datasets-in-group (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/refresh-dataset-in-group (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/power-bi/reports/delete-report-in-group (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/power-bi/groups/add-group-user (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/rest/api/power-bi/datasets/execute-queries-in-group (retrieved 2026-09-21)
• https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-service-principal (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.