Defender for Cloud Apps with Power BI - Stopping Sensitive Data Walking Out the Door

A while back a client in financial services asked us a fairly blunt question. "If one of our analysts exported the full customer list from Power BI to Excel on their last day, would we know?" The honest answer was: eventually, maybe, if someone happened to go looking through the activity log. That's not a great answer when APRA's CPS 234 expects you to have controls over information assets, and when the Privacy Act penalties in Australia have grown teeth over the last few years.

This is the gap Microsoft Defender for Cloud Apps is meant to close for Power BI. Microsoft's guidance on Defender for Cloud Apps for Power BI covers the planning side well. I want to add what we've learned from actually turning it on for clients, including the bits that annoyed users and the bits that genuinely caught problems.

What it actually does for Power BI

Defender for Cloud Apps is Microsoft's cloud access security broker. For Power BI, it gives you three main capabilities.

Session control in real time. Using Conditional Access App Control, user sessions in the Power BI service get routed through Defender for Cloud Apps acting as a reverse proxy. That lets you apply session policies as people work, like blocking the download of a report or export of data when that content carries a particular sensitivity label.

Activity policies and alerts. You can define policies that raise alerts on particular activities: someone sharing a report with an external user, someone changing workspace permissions, a burst of exports in a short time window.

Anomaly detection. Defender for Cloud Apps has built-in anomaly policies that look for behaviour out of the ordinary, like a user logging in from two countries an hour apart, or mass downloads that don't fit their normal pattern.

The Power BI activity log already records most of these events. The difference is that the activity log tells you after the fact, if someone looks. Defender for Cloud Apps can tell you in close to real time, and in the case of session policies, actually stop the action.

The sensitivity label dependency

Here's the thing a lot of people miss. The most useful session policies depend on Microsoft Purview sensitivity labels being applied to your Power BI content. If you want a rule like "block downloads of anything labelled Highly Confidential", you first need your semantic models and reports labelled.

In our experience most organisations haven't done this properly. They might have labels configured for Office documents, but Power BI content is unlabelled or everything is sitting at the default "General" label. So the first project often isn't Defender at all. It's getting a labelling approach in place for Power BI: default labels on new content, inheritance from data sources where it's supported, and a sensible process for who can downgrade a label.

If you skip this step, your session policies have nothing to key off, and you end up writing broad rules that block things for everyone. Which brings me to the next point.

Be careful with blanket blocks

I've seen security teams get enthusiastic and set a session policy that blocks all exports from Power BI. Within about two days the help desk has a queue full of finance analysts who can't do month-end reconciliations because they can't export to Excel any more.

Power BI users export data. A lot. Some of that is bad practice that should be fixed by better reports, but a lot of it is legitimate work. A blanket block mostly teaches people to find workarounds, like copying visuals or screenshotting tables, and that's worse for you because now there's no audit trail.

What works better:

• Target session policies at labelled content only, starting with your most sensitive classification
• Scope policies to specific groups where it makes sense, like contractors or users on unmanaged devices
• Use monitor-only mode first for a few weeks so you can see what would have been blocked before you actually block it
• Tell people before you turn on blocking, and explain why

The monitor-first approach is the one I'd push hardest. It costs you nothing and it tells you exactly how disruptive the real policy will be.

The user experience changes

When a session is routed through Defender for Cloud Apps, users will notice. The URL in their browser changes to include a .mcas.ms suffix. Some users find this alarming and report it as a phishing attempt, which is actually a reasonable instinct. Communicate the change before you roll it out.

There can also be a small performance hit, since traffic is going through a proxy. In most cases it's barely noticeable, but on heavy reports with lots of visuals some users have told us it feels slower. Worth testing with your heaviest reports before a wide rollout.

The bigger limitation is coverage. Session control applies to browser sessions in the Power BI service. It doesn't cover Power BI Desktop, and it doesn't control what happens in the mobile apps the same way. So if your threat model is "a determined insider wants to take data", Defender for Cloud Apps is one layer, not the whole answer. You'll still want tenant settings that restrict who can export, who can use Analyze in Excel, and who can build reports from a semantic model, plus Purview data loss prevention policies for Power BI.

Licensing, briefly

This is often where the conversation slows down. To use Defender for Cloud Apps with Power BI you need Defender for Cloud Apps licensing for the users you want to protect, and Conditional Access needs Microsoft Entra ID P1 or higher. Many larger organisations already have these through Microsoft 365 E5 or E5 Security add-ons and just haven't switched the features on.

That last point is worth checking. More than once we've found a client paying for E5 who had no idea they already owned the tooling for this. Ten minutes in the admin centre can save a procurement process.

Who owns it?

The organisational side is as tricky as the technical side. Defender for Cloud Apps usually belongs to the security team. Power BI belongs to the BI team or a Power BI administrator. Sensitivity labels belong to whoever runs information governance, if anyone does.

For this to work, those groups have to agree on a few things:

• Which labels trigger which policies
• Who gets the alerts, and who is expected to act on them
• What the escalation path is when an alert fires at 7pm on a Friday
• How exceptions get approved when a business user has a legitimate need

The alert routing question matters more than people expect. If alerts go to a shared security inbox nobody checks, you've bought an expensive logging tool. If they go to the Power BI admin who has no authority to investigate an insider risk issue, you've created a different problem. We usually recommend alerts go into the security team's existing incident process, with the Power BI admin as a consulted party who can explain what the activity actually means.

What it's caught for clients

To make this less abstract, here are a couple of real situations (details changed) where this tooling earned its keep.

At a professional services firm, an anomaly alert flagged a user who had exported data from a dozen reports in under an hour, well outside their normal pattern. It turned out to be a resigning employee pulling client lists. Without the alert, nobody would have known until clients started getting calls from a competitor.

At a healthcare organisation, an activity policy picked up a report containing patient-level data being shared to an external email address. It was an honest mistake (wrong email in an autocomplete), but because the alert came through within minutes, the share was revoked before the recipient opened it. Under the Notifiable Data Breaches scheme, the difference between "caught in minutes" and "found three weeks later" is significant.

Neither of these needed fancy configuration. They needed the basics turned on and someone watching the alerts.

Where I'd start

If you're running Power BI with sensitive data and haven't looked at this, here's the order I'd suggest:

1. Check what licensing you already have. You might own it.
2. Get sensitivity labels applied to your Power BI content, starting with the most sensitive semantic models.
3. Turn on the built-in anomaly and activity policies for Power BI and route alerts somewhere they'll be seen.
4. Set up a Conditional Access policy to route Power BI sessions through Defender for Cloud Apps for a pilot group.
5. Run session policies in monitor mode for a few weeks, then move to blocking for the most sensitive labels.

It's not a huge project when done in that order. Most of the effort is in the labelling and the organisational agreements, not the technology.

If you'd like help planning Power BI security and governance, our Power BI consultants do this kind of work regularly, and we work with a lot of clients in regulated sectors through our financial services practice. We're also seeing the same questions come up around AI tools accessing business data, which is why we put together our approach to secure Claude deployments. The principle is the same: know where sensitive data is going, and have controls that actually fire when it goes somewhere it shouldn't.