Sensitive data in Power BI: row-level, object-level and the layer beneath

Sensitive data in a report is rarely a technical problem. The problem is that nobody wrote down precisely who may see which number, and the report then has to close that gap.

Power BI has two mechanisms that help, and one layer underneath where it is actually settled.

Four layers, from report to source

Access to a report, to a field, to a row, and to the source: four different questions.

The order matters. Someone without workspace access sees nothing. Someone with access sees everything in the model by default. Row-level and object-level security narrow that. And underneath sits the question of who may reach the source data at all, which no report setting solves.

Row-level and object-level security

Limiting rows is not the same as hiding fields.

Row-level security limits which rows a role sees. A regional manager sees their own sites: same report page, different numbers. In practice you use a table that maps users to areas, so a new colleague is a row rather than a model change.

Object-level security hides entire tables or columns from a role. That is the tool for salary, purchase price or personal data. Watch the behaviour: a visual using a hidden column returns an error, not a blank. Design separate pages instead of one page that half breaks.

Where it goes wrong in practice

• Testing as an administrator. An admin sees everything, always. Test with the role viewer and with a real account from the target group.
• Exported data. Anyone who can export takes the numbers outside your permission model. Sensitivity labels and export restrictions belong to the same agreement.
• Permissions per report instead of per definition. Twenty reports with their own roles is twenty places where it can drift.
• The source is wide open. Row-level security in a report stops nobody who can reach the database or lakehouse directly.

The layer beneath

Row-level and object-level security are indispensable, but they describe per report what should have been settled elsewhere: who owns a term, which data is sensitive, and which role may reach it. Those agreements belong in the catalog of your platform, where they hold for every report and every AI agent.

That is the difference between security as a report setting and security as a property of your foundation. We build that layer with a governance model where lineage, ownership and access travel with the data itself; see Private AI for how that carries over once AI uses the same data, and what data architecture is for how the layers stack.

In short

Put the agreement on paper first, settle it in the layer beneath your reports, and use row-level and object-level security to enforce it in Power BI. Test with real accounts, because an administrator never sees what the user sees.