Power BI Content Creator Security Planning - Who Builds What and How to Control It

When an Australian organisation asks us to look at their Power BI security, they usually expect us to start with the people reading reports. Who can see the payroll dashboard, who can see which region's sales. That matters. But in most of the tenants we audit, the bigger risk sits with the people creating content.

Content creators are the ones who connect to source systems, build semantic models, publish to workspaces and share with others. If they have the wrong permissions, or too many of them, data ends up in places it shouldn't. I've seen a finance analyst accidentally publish a model with full salary data into a workspace where 200 people had Viewer access. Nobody did anything malicious. The permissions just allowed it.

Microsoft's implementation planning guidance has a section dedicated to this, Content creator security planning. It's long and fairly dense, so I'll pull out the decisions that matter most and add what we've seen on real projects.

Decide who is allowed to create at all

The first question is simple and often skipped: who in your organisation should be able to publish content to the Power BI service?

By default, a lot of tenants let anyone with a Pro or Premium Per User licence create workspaces and publish. That's fine for a small business. For a 2,000-person organisation it leads to hundreds of personal-ish workspaces with no clear owner.

The tenant settings give you control here. You can restrict workspace creation to a security group, and you can control who can publish to the web, export data, share externally and so on. My usual recommendation:

• Restrict workspace creation to a security group. Have a light request process. The point isn't to say no, it's to know who owns what.
• Keep Publish to web off, or limited to a tiny group, unless you have a specific public reporting need. This setting has caused more genuine data incidents than anything else I've seen in Power BI.
• Think carefully about export to Excel and CSV. Turning it off completely annoys people and they find workarounds. Leaving it wide open means sensitive data walks out the door in spreadsheets. Sensitivity labels with export controls are usually the better middle ground.

Workspace roles are your main lever

Power BI workspaces have four roles: Admin, Member, Contributor and Viewer. Content creators typically sit in the top three. The differences matter more than people realise.

• Admin can do everything, including adding and removing people and deleting the workspace.
• Member can publish and update content and can add other people with Member or lower roles. They can also share items and manage the workspace app.
• Contributor can publish and update content but can't share items or manage permissions. This is the role most creators should have.
• Viewer can read content only.

The mistake we see constantly is everyone getting Member or Admin because it's easier. Then a Member adds a whole distribution list as Viewers to "just let them see it", and suddenly a workspace intended for a team of eight has 300 readers.

What we recommend: give creators Contributor by default. Keep Admin to two or three people per workspace, ideally including someone from the BI team. Use Member sparingly, for people who genuinely need to manage the app and audience.

Also, assign roles to security groups, not individuals. I know everyone says this. Almost nobody does it consistently. When someone leaves or changes teams, group-based access cleans itself up. Individual access sits there for years.

Separate data workspaces from reporting workspaces

This is one of the most useful patterns in the guidance and one we push on most projects. Put your shared semantic models in one set of workspaces, owned by data modellers. Put the reports that use them in other workspaces, owned by report creators.

Why it helps with security:

• Report creators don't need any role in the data workspace. They just need Build permission on the semantic model.
• Data modellers control the model, including row-level security, without worrying that a report author will change it.
• You can apply different access rules to each. The data workspace might have five people in it. The reporting workspace might have fifty.

Build permission is the quiet hero here. It lets someone create new reports from a semantic model, including in Excel and in other workspaces, without giving them edit rights to the model itself. It's also a permission people forget they've granted. Anyone with Build can explore the full model through Analyze in Excel, subject to RLS. So if your model contains data that shouldn't be widely browsable, be careful who gets Build, even if the polished report only shows a summary.

Row-level security and the creator gap

Row-level security works for viewers. It doesn't apply to people with Admin, Member or Contributor roles in the workspace where the semantic model lives. They see everything.

This catches organisations out regularly. They set up RLS so each state manager only sees their state's data, then give all the state managers Contributor on the workspace so they can build their own reports. Now RLS does nothing for them.

The fix is the separation I mentioned above. Keep the model in a data workspace where those managers have no role, give them Build permission on the model, and let them create reports in their own workspace. RLS then applies to them properly.

Object-level security, which hides whole tables or columns, has the same creator gap and the same fix.

Data source credentials and gateways

Content creators often need to connect to source systems. The planning questions here:

• Whose credentials does the semantic model use to refresh? If it's a creator's personal account, the refresh breaks when they leave, and the model might be pulling data with far broader access than intended. Use service accounts or, better, service principals or workspace identities where the source supports it.
• Who can use the gateway connections? Gateway connection users can be restricted. Don't add everyone. Each connection should have a defined list of users who are allowed to build on it.
• Single sign-on or stored credentials? SSO through DirectQuery passes the viewer's identity to the source, so the source's own security applies. That's great when the source has good security. It's a pain when it doesn't.

On one project for a professional services firm, we found eleven semantic models refreshing with the credentials of an analyst who had left the company eight months earlier. The account had been disabled, but the stored credentials had been updated to a shared service account by a colleague, who had full read access to the practice management database. Every one of those models had more data in it than anyone needed. Cleaning that up took a couple of weeks.

Sensitivity labels and endorsement

Two more tools I'd encourage every organisation to use:

Sensitivity labels from Microsoft Purview can be applied to semantic models, reports and dashboards. They travel with exported data into Excel, PowerPoint and PDF. You can make labelling mandatory for creators and set a default label. I'd strongly recommend this for any organisation handling personal or financial data, which is most of them given the Privacy Act obligations here.

Endorsement, meaning promoted and certified, isn't strictly a security feature, but it helps. If certified models are easy to find, creators are less likely to build their own extracts from source systems with whatever credentials they happen to have.

What's still awkward

Being honest about the rough edges:

• Permissions are spread across too many places. Workspace roles, item-level sharing, Build permission, app audiences, RLS, gateway connection users, tenant settings. Getting a full picture of who can see what is genuinely hard without scripting against the admin APIs. We usually build a small permissions inventory as part of any security review.
• Fabric adds more layers. If you're on Fabric capacity, creators can now build lakehouses, warehouses and notebooks in the same workspaces. OneLake security and item permissions add another dimension. The planning principles are the same, but the surface is bigger.
• Personal workspaces (My workspace) are a blind spot. Creators can build and share from there. Admins can see them, but most don't look. Consider whether to restrict sharing from personal workspaces.

A short checklist

If you only do a few things this quarter:

1. Restrict workspace creation and Publish to web through tenant settings.
2. Move creators from Member and Admin to Contributor where you can.
3. Switch individual role assignments to security groups.
4. Separate data workspaces from reporting workspaces for sensitive models, and use Build permission.
5. Audit semantic model refresh credentials and gateway connection users.
6. Turn on sensitivity labels with a default label.

None of this is technically difficult. It's mostly discipline and a bit of upfront planning.

Where we can help

We do Power BI security and governance reviews regularly, usually starting with a permissions inventory and a list of quick fixes. If that's useful, our Power BI consultants can help. For organisations moving onto Fabric, our Microsoft Fabric consultants handle the broader platform security planning. And if you're in a regulated sector like financial services, getting creator permissions right before you add Copilot or AI agents on top is particularly important, because those tools will happily surface anything a user has access to.

The short version: viewers get most of the attention, but creators are where security plans usually fall apart. Plan for them first.