Securing Copilot in Power BI: Semantic Model Permissions and Sensitivity

Copilot in Power BI allows analysts and operational staff to ask questions in natural language and receive narrative summaries, visuals and calculated insights drawn from a semantic model. For organisations in mining, resources and broader enterprise settings, this capability shortens the distance between a business question and a defensible answer. It also raises a governance question that technical and decision-making readers must resolve before deployment: how do you ensure that a conversational interface never surfaces data a user was never permitted to see in the first place?

The reassuring principle is that Copilot does not bypass the security model built into the semantic layer. It operates on top of the same permission boundaries that already govern Power BI, which means the controls you configure at the model level continue to apply when a user phrases a request as a sentence rather than a filter. Understanding how row-level security, object-level security and sensitivity labels interact with Copilot is therefore central to enabling natural language analytics without leaking restricted operational data.

How Copilot Interacts With the Semantic Model

When a user prompts Copilot, the response is generated from the semantic model as that specific user, not as an unrestricted service account. This matters because the model already carries the definitions, relationships and security rules that determine what any given identity can query. Copilot inherits those rules, so a summary it produces reflects the same filtered view of data the user would obtain through a conventional report or a direct query.

This design places responsibility squarely on the quality of the underlying model. A well-defined semantic model with clear measures, sensible relationships and correctly scoped security produces trustworthy Copilot output, while a permissive or poorly governed model produces the opposite. Treating the semantic model as the authoritative control point, rather than attempting to restrict language prompts after the fact, is the sound approach for regulated and safety-sensitive environments.

Row-Level Security and Object-Level Security

Row-level security, commonly abbreviated as RLS, restricts the rows a user can see within a table based on their identity or role membership. In a resources context, this could mean that a site supervisor sees production, haulage and equipment records for their own operation, while a corporate analyst sees an aggregated national view. Because Copilot answers as the signed-in user, a natural language request such as a summary of tonnes moved this week returns only the rows that user is entitled to, and the narrative it generates reflects that filtered subset without exposing figures from other sites.

Object-level security, or OLS, operates at a different granularity by controlling access to entire tables or columns rather than individual rows. This is valuable where the existence of a field is itself sensitive, such as cost rates, contractor commercial terms or personnel identifiers embedded in operational data. When a table or column is hidden from a user through OLS, Copilot cannot reference, summarise or infer values from that object for that user, because the object is effectively absent from their view of the model. Combining RLS and OLS allows precise separation of both the values within a dataset and the structural elements a user is permitted to work with.

Sensitivity Labels and Classification

Sensitivity labels, applied through Microsoft Purview Information Protection, classify content according to its confidentiality and attach protection that travels with the data. A label applied to a semantic model can carry through to reports and to content exported from Power BI, which supports consistent handling of information as it moves between systems and users. For organisations that must demonstrate a documented classification scheme to auditors or regulators, labels provide a visible and enforceable expression of data handling policy.

Labelling complements permission controls rather than replacing them. Where RLS and OLS determine what a user can access, sensitivity labels influence how that information may be used, shared and protected once it leaves the confines of a report. This layered arrangement helps ensure that a Copilot-generated summary carrying restricted operational insight retains its classification and associated protections if a user copies or exports it, reducing the risk that sensitive material is redistributed without appropriate safeguards.

Practical Guidance for Secure Deployment

Before enabling Copilot for a workspace, review the semantic models it will draw upon and confirm that security roles are defined, tested and mapped to the correct identities in your directory. Validation should include signing in as representative users, or using role testing features, to verify that filtered views return exactly the data those users should see and nothing more. Descriptive table names, clear measure definitions and documented relationships also improve the accuracy of Copilot responses, because the assistant relies on this metadata to interpret intent correctly.

Governance should extend beyond the model to the surrounding tenant and workspace configuration. Administrators can control where Copilot is available, align its use with existing data loss prevention and information protection policies, and monitor activity through audit logging. Establishing a clear ownership model for semantic models, combined with periodic review of security roles and label assignments, keeps controls current as operations, personnel and reporting requirements change over time. Approached this way, natural language analytics becomes an extension of an existing security posture rather than a new and unmanaged exposure.

References

• Row-level security (RLS) with Power BI
• Data protection in Power BI with sensitivity labels
• Overview of Copilot in Power BI