A Power BI report can look correctly restricted while an elevated workspace role, Build permission, a shared semantic model, an app audience, a direct grant, an external guest, a service principal, or a public embed creates another route to the data. A list of workspace members is therefore not a security audit. The useful question is whether a named identity can reach a specific report, semantic model, row, object, export, or downstream connection through any permitted path.
Datrick builds this answer from supported tenant, identity, metadata, permission, and activity evidence. AI can classify findings, explain complex access paths, group similar exceptions, and draft owner attestations. Deterministic rules calculate effective access and policy violations. No model should grant, revoke, approve, or reinterpret access without an accountable reviewer and a validated change plan.
Do you have sensitive models, external users, inherited permissions, or RLS rules that nobody can confidently explain? Start with the workspaces where an access mistake has the highest business impact.
Define the security contract before testing access
Identify the tenant, workspaces, apps, reports, semantic models, Fabric items, source systems, identities, business units, external organizations, sensitivity classes, and time period in scope. Define expected personas, data boundaries, export rules, sharing policy, exception authority, evidence retention, acceptable outage, and remediation approval. Without an approved expectation, an access graph can show what exists but cannot determine what is wrong.
| Security layer | Evidence to collect | Risk the audit must resolve |
|---|---|---|
| Identity | Users, guests, groups, nested membership, service principals, managed identities, account status, owner, sponsor, and expiry. | Departed user, unmanaged guest, stale application, nested group surprise, or no accountable sponsor. |
| Workspace and item access | Admin, Member, Contributor, Viewer, item grants, direct access, sharing links, reshare, Read, Write, and owner assignments. | Elevated role bypasses intended RLS, broad direct grant, inherited access, or permission without business need. |
| Semantic model | Read, Build, Reshare, Write, RLS roles, OLS, dynamic identity rules, XMLA access, cross-workspace use, and downstream reports. | Build enables unintended data exploration, role membership is wrong, or one model exposes more than its report interface suggests. |
| Distribution | Apps and audiences, external B2B sharing, subscriptions, Teams or SharePoint use, secure embeds, Publish to web codes, exports, and APIs. | External exposure, stale audience, public content, forwarded extract, or channel that owners do not monitor. |
| Source and connection | Gateway, cloud connection, DirectQuery or SSO identity, source roles, credentials, service accounts, and data-source privacy. | Power BI restriction conflicts with source authorization, shared credentials overexpose data, or test results use the wrong identity. |
| Context and evidence | Sensitivity labels, endorsement, criticality, lineage, activity events, tenant settings, access reviews, incidents, exceptions, and approvals. | Sensitive content has weak controls, dormant access is retained, or a policy exception has no owner or expiry. |
Calculate effective access, not configured access
Resolve every user, group, guest, and application to the permissions it receives across workspace roles, item access, apps, links, semantic models, and sources. Preserve the provenance of each edge: a direct grant and a nested group membership can produce the same visible access but require different remediation. Record when evidence was collected because group membership, sharing links, and app audiences change independently.
Microsoft documents an important RLS boundary: RLS applies to users assigned the Viewer workspace role, while Admin, Member, and Contributor roles have edit permission and are not restricted by RLS. A user who is correctly assigned to an RLS role can still see unrestricted data through an elevated workspace role. The audit should flag this conflict and test the effective experience, not merely confirm that the RLS role exists.
Build permission also deserves separate review. It can support Analyze in Excel, creation of new content from a semantic model, and access patterns that go beyond viewing a curated report. Report layout, hidden fields, filters, and app navigation customize the experience; they are not substitutes for RLS or object-level controls. Test representative users against the semantic model, not only against one report page.
Test RLS as a security control
Inventory every static and dynamic RLS role, its DAX expression, table relationships, identity function, membership source, deployment process, and owner. Check overlapping roles because additive membership can broaden access. Trace how a user's UPN or other identity reaches the authorization table, including casing, aliases, guest identities, service accounts, and environment-specific mappings.
Create positive and negative test cases for representative personas: expected rows, forbidden rows, totals, drillthrough, exports, Analyze in Excel, subscriptions, downstream reports, and cross-workspace models. For DirectQuery or single sign-on, include source-system behavior because Microsoft notes limitations in the built-in “Test as role” experience. Retain the query, identity, model version, expected result, observed result, and reviewer decision.
Audit external sharing and public exposure
External sharing requires more than listing guest users. Review tenant settings, invitation and sponsor status, direct recipients, sharing links, app audiences, semantic-model sharing, Build and reshare rights, subscriptions, embeds, activity, sensitivity, and expiry. Microsoft notes that external recipients must authenticate for normal sharing and that only the intended identity can use a specific-person link, but broad permissions and stale guests still require governance.
Search explicitly for Publish to web embed codes. Microsoft warns that Publish to web makes content and underlying model data available to anyone on the internet without authentication. It is not a secure sharing mechanism. Each code should have an owner, approved public-data classification, tenant-policy basis, and recurring review; unapproved exposure should follow an incident-aware removal process.
Build a controlled security-review workflow
| Component | Responsibility | Required control |
|---|---|---|
| Read-only collectors | Collect scanner metadata, roles, item permissions, users, groups, apps, RLS, sharing, tenant settings, labels, lineage, and activity. | Least-privilege service identity, secret rotation, pagination, raw retention, extraction time, and collection-health monitoring. |
| Effective-access graph | Connect identities and nested groups to workspaces, items, models, roles, apps, links, sources, and external organizations. | Stable identifiers, edge provenance, source timestamp, unresolved membership, and no inferred grant presented as fact. |
| Deterministic policy engine | Compares calculated access with approved role, sensitivity, sharing, Build, RLS, guest, service-principal, and exception rules. | Versioned policy, scoped applicability, effective dates, test cases, and approved exception with owner and expiry. |
| AI security analyst | Groups findings, summarizes paths, proposes likely cause, drafts owner questions, and explains remediation alternatives. | Evidence citations, uncertainty, redaction, prompt and output logging, and no permission-changing authority. |
| Attestation and approval | Routes findings to data owners, workspace owners, security, compliance, external-user sponsors, and platform administrators. | Named decision maker, due date, business reason, conflict handling, exception expiry, and escalation. |
| Controlled remediation | Changes group membership, role, direct access, app audience, Build, sharing, RLS, embed, or source permission. | Impact preview, approval, backup, rollback, change window, user communication, and separation of duties. |
| Independent validation | Recalculates access and runs persona tests after the change. | Different reviewer or automated control, negative tests, downstream checks, audit trail, and residual-risk acceptance. |
Remediate the permission path, not only the visible symptom
If a user has excessive access through three paths, removing one direct grant does not close the finding. Produce a before-and-after path for each affected identity and item. Prefer maintainable group-based assignments where policy supports them, but first resolve nested group ownership and lifecycle. Do not automatically replace all direct access; some break-glass, service, or exception patterns can be legitimate when approved and monitored.
Sequence changes to avoid breaking production reports and integrations. Removing Build can affect analysts, Analyze in Excel, composite models, and downstream report authors. Changing a workspace role can alter publish, refresh, app, and deployment duties. Updating RLS can change every report connected to the model. Revoking an external guest can affect multiple Microsoft 365 resources outside Power BI. The runbook should name dependencies, communication, rollback, and acceptance tests.
Validate from the user's effective context after every wave. Recollect permissions, resolve group membership, rerun positive and negative tests, inspect activity, and confirm the intended business workflow still works. Close a finding only when the prohibited path is gone and the required path remains available.
Prioritize findings by reachable data and business impact
- Critical: public exposure, unrestricted access to regulated data, compromised identity, or unauthorized external access with confirmed sensitive reach.
- High: elevated role bypassing RLS, broad Build or reshare on sensitive models, stale privileged service principal, or unmanaged external access.
- Medium: direct grant sprawl, unused access, unclear ownership, overlapping RLS roles, weak expiry, or missing negative tests.
- Control gap: incomplete evidence, scanner failure, unresolved nested group, missing source permission, or activity history too short to support a decision.
Do not use an AI confidence score as risk severity. Severity should derive from verified access, data sensitivity, action capability, external exposure, activity, business criticality, compensating controls, and the consequence of misuse. Unknown evidence is a control gap, not proof of safety.
Run a two-to-four-week Power BI security assessment
- Define critical content, expected personas, sensitive data, external organizations, policy sources, decision owners, and remediation authority.
- Configure read-only tenant, metadata, identity, permission, and activity collection; verify completeness and retain raw evidence.
- Build the identity-to-content graph across workspace, item, app, semantic-model, RLS, sharing, service-principal, and source paths.
- Apply versioned rules for elevated roles, Build, direct grants, guests, public exposure, stale identities, RLS conflicts, and expired exceptions.
- Test representative internal, external, privileged, and restricted personas with positive and negative expected results.
- Validate findings with data, workspace, security, and business owners; distinguish violation, accepted exception, and missing evidence.
- Execute one approved remediation wave with dependency checks, communication, rollback, and separation of duties.
- Recalculate effective access, retest user outcomes, and deliver the baseline, risk register, remediation backlog, runbooks, evidence model, and recurring review cadence.
Start with a bounded set of critical workspaces if tenant access is complex. The first assessment should prove the evidence and remediation method before expanding. Tenant-wide security reviews can then operate as a recurring managed control, with event-driven checks for leavers, new guests, elevated role changes, public embeds, sensitive models, and service-principal changes.
Frequently asked questions
How do you audit Power BI permissions?
Collect workspace roles, item permissions, direct and link-based sharing, app audiences, semantic-model permissions, Build rights, RLS roles, external guests, service principals, tenant settings, identity status, sensitivity, lineage, and activity. Resolve users and nested groups, calculate effective access for each critical item, compare it with approved policy, validate findings with owners, and retest access after approved remediation.
What is included in a Power BI row-level security assessment?
A useful assessment reviews role definitions, DAX filters, static and dynamic membership, identity mapping, workspace roles, Build and reshare permissions, app and direct access paths, source-system authorization for DirectQuery or SSO, service-principal behavior, test cases, negative tests, and evidence that each representative persona sees only the intended rows and objects.
Does Power BI RLS apply to workspace administrators?
No. Microsoft documents that RLS applies to users assigned the Viewer workspace role, while workspace Admin, Member, and Contributor roles have edit permission on the semantic model and are not restricted by RLS. A security audit must therefore review elevated workspace roles as separate access paths.
How do you audit external sharing in Power BI?
Review tenant sharing settings, Microsoft Entra B2B guests, direct access, sharing links, app audiences, semantic-model sharing, reshare and Build permissions, subscriptions, embeds, Publish to web codes, identity status, activity, sensitivity, owner approval, and expiry. Verify access using representative external identities and remove exposure only through an approved, reversible change process.
How long does a Power BI security audit take?
A focused assessment of critical workspaces can often produce an effective-access baseline, validated findings, and a prioritized remediation plan in two to four weeks. A tenant-wide program takes longer when there are many nested groups, external guests, direct grants, app audiences, cross-workspace models, service principals, missing activity history, or business-owner attestations.
Official implementation references
- Microsoft row-level security guidance for Power BI
- Microsoft Power BI workspace roles and Build permission
- Microsoft Power BI sharing and external-user guidance
- Microsoft Power BI Publish to web security warning
- Microsoft Fabric metadata scanning overview
- Microsoft Power BI Admin Activity Events API
Start with the models where excessive access would create a real incident. Datrick can establish effective access, validate RLS and sharing, prioritize findings, and run a controlled remediation wave.