Power BI security is layered. Workspace roles control collaboration, item and semantic-model permissions control who can use content, row-level security limits which rows some consumers can see, and sensitivity labels classify and protect information beyond the report experience. For PL-300 and DP-600, the key is choosing the correct layer instead of expecting one feature to solve every access-control problem.
Microsoft’s current Power BI service has four workspace roles: Admin, Member, Contributor, and Viewer. A critical detail is that RLS restricts Viewer users but does not restrict Admin, Member, or Contributor roles because those roles can edit the semantic model. This means workspace collaboration and data consumption should be separated deliberately when sensitive row-level restrictions matter.
Use workspace roles for collaboration responsibility
Admins manage the workspace and its access, Members have broad content-management capabilities, Contributors can create and edit content, and Viewers are primarily consumers. Assign groups rather than individuals where practical so access follows organizational roles and can be reviewed centrally.
Do not add consumers as Contributors simply because they need one extra capability. Use the least-powerful role that supports the workflow and separate workspace administration from report authorship where teams are large. Group-based assignment also makes offboarding and periodic access reviews more reliable than a long list of individual grants. Higher workspace roles expand access to workspace content and can bypass RLS expectations. Keep authoring workspaces limited to people who genuinely build or manage content, and distribute reports to larger audiences through apps or targeted sharing.
Separate workspace access from item sharing
A user does not always need workspace membership to consume a report or app. Power BI supports sharing and item permissions that can expose selected content without granting access to everything in the authoring workspace. Separate consumption from collaboration: most business users should receive a curated app or report rather than browse the workspace where models, drafts, and deployment artifacts are maintained. This reduces accidental access to draft reports, semantic models, dataflows, or operational artifacts.
Review direct sharing periodically because item-level grants can accumulate outside the main group model. When a report is replaced by an app or moved to another workspace, remove obsolete direct permissions rather than assuming the new distribution path automatically cleans them up. Track business ownership for externally or broadly shared content. Prefer security groups and app audiences for repeatable distribution patterns, and document why an individual direct grant exists when one is necessary for support or a temporary project.
Understand semantic-model permissions and Build access
A report consumer may need permission to build new reports from a shared semantic model. Reuse across workspaces can improve consistency, but it also increases dependency on the source model owner. Document support expectations, endorsement status, and change communication so downstream reports do not break when the shared model evolves. Build permission enables additional reuse scenarios such as creating downstream reports or Analyze in Excel, while Read permission covers basic consumption. Treat Build as a meaningful data-access capability rather than a harmless reporting option. A user with Build can create new reports from the semantic model and may expose fields or combinations that the original report did not display. Grant it to analysts who need reuse, not to every viewer by default.
When semantic models are reused across workspaces, tenant settings and model permissions can constrain discovery and reuse. Endorse or certify trusted semantic models so creators can identify governed sources, but remember that endorsement is a quality signal, not an authorization control.
RLS filters rows for the appropriate consumers
Row-level security roles are defined with DAX filters in the semantic model and assigned to users or groups in the service. Static RLS maps people to fixed roles, while dynamic patterns can use identity functions and mapping tables to filter data according to the signed-in user.
Test RLS with representative users and role combinations. Validate dynamic RLS mappings when users belong to several organizational units or groups, and test totals and drill paths as well as individual rows. Security rules should be deterministic and understandable enough that an owner can explain why one user can see a record and another cannot. In workspaces, RLS applies to Viewers, including Viewers who have Build permission, but it does not constrain Admin, Member, or Contributor users. If an author must be restricted to a subset of data, a higher workspace role is the wrong security design.
Object-level security protects model metadata and fields
Object-level security can restrict access to specific model tables or columns for selected roles. This is useful when a user may view most of a model but should not even discover a sensitive field such as salary, margin, or confidential classification.
RLS and OLS solve different problems. OLS can hide a table or column from a role, while RLS filters records. If sensitive fields are required only for a small audience, OLS or a separate semantic model may be cleaner than exposing the fields to everyone and relying on report authors never to place them on a visual. RLS limits rows while OLS limits objects. A report design that merely hides a column from a visual is not security because users with model access may still query the hidden field. Enforce sensitive boundaries in the semantic model or source system, not only in report layout.
Sensitivity labels classify and protect content
Power BI integrates Microsoft Purview Information Protection sensitivity labels with reports, dashboards, semantic models, dataflows, and supported files. The broader Microsoft Purview framework provides organizational classification and protection policy, while Power BI carries those labels through analytics content and supported exports.
Labels can be inherited from supported upstream sources and can propagate downstream in supported scenarios. Review tenant settings and label publishing because inheritance depends on organization configuration and supported connectivity. Manually applied labels can also have precedence rules that differ from automated inheritance, so governance teams should test the intended classification flow end to end. Classification is not the same as workspace authorization, however. A sensitivity label informs and may protect exported files, while workspace roles, item permissions, RLS, OLS, and tenant settings determine who can access the Power BI item itself.
Apps create a cleaner consumer boundary
Power BI apps let creators package selected workspace content for an audience without giving users collaborative workspace roles. Different audiences can receive different content from the same app, which helps separate authorship from consumption and reduces pressure to add every business user directly to the workspace.
App access still depends on underlying semantic-model permissions and licensing. Use app audiences to expose different report sets without duplicating entire workspaces when the security boundary allows it. Keep author-only operational reports and draft content out of consumer audiences even if they live in the same workspace. Test the consumer experience as a real target user, especially when reports use models from other workspaces, RLS roles, external identities, or composite models. Author access is a poor substitute for validating consumer permissions.
External sharing needs tenant and identity governance
Microsoft Entra B2B guest users can receive workspace roles or specific item permissions where tenant policy allows it. Use access packages, group lifecycle, or equivalent identity-governance processes when collaboration is long-lived. External access should have a business sponsor and a review date rather than persisting because the original sharing email was never revoked. External collaboration should use approved identities, groups, expiration or access review processes, and clear ownership. Guest accounts that remain after a project ends can become long-lived data-exposure paths.
Review tenant settings that control external sharing, semantic-model reuse, export, publishing, and other high-impact capabilities. Restrict “publish to web” and similar public-sharing features according to organizational policy because those mechanisms can bypass the controlled user identity model entirely. Security architecture should include tenant defaults, not only workspace configuration. Coordinate Power BI settings with Microsoft Entra groups, Purview labels, data-loss prevention, and organizational access-review processes so the analytics layer does not become a separate exception to the enterprise security model. Power BI security is partly a tenant-governance problem; a perfectly configured report can still leak data if broad export or sharing settings conflict with organizational policy.
Audit access as a lifecycle, not a one-time setup
Security changes when teams reorganize, reports move workspaces, datasets are reused, apps gain audiences, and models receive new sensitive fields. Schedule access reviews for workspace roles, direct shares, app audiences, semantic-model permissions, RLS membership, and external users. Include ownership and inactivity signals so abandoned workspaces do not retain privileged members forever. When a workspace has no accountable owner, treat that as a governance defect before new sensitive data is published into it.
Use audit logs and governance reporting to understand how sensitive content is accessed and shared. A secure Power BI environment can explain who can author, who can consume, which rows and columns they can see, how exported content is classified, and who owns each exception. Review that explanation whenever a workspace changes purpose or a semantic model gains a new sensitive subject area, because yesterday’s access pattern may no longer fit today’s data.
Service principals and automation identities need the same review as human users. A deployment or refresh identity may hold workspace roles, semantic-model permissions, or data-source credentials long after the original pipeline changes. Inventory non-human access, map each identity to an owner and purpose, and remove unused permissions so automation does not become the least visible route into sensitive Power BI content.