Protect the users against themselves

As you all should know by now, I’m not particularly impressed by the state of data governance and information security I see out there. In fact, “appalled” is usually closer to the mark.

Yet again, I feel the need to say something that makes everyone a wee bit uncomfortable.

Let’s be painfully honest: most data leaks today aren’t caused by mysterious hooded hackers in dark basements. They are caused by perfectly well-meaning employees pasting the wrong thing into the wrong AI tool at the wrong time.

That isn’t malice. That is human behaviour at scale.

Humans are fallible, lazy, and look for shortcuts. Pretending this won’t happen in your organisation is the fastest way to guarantee a meeting with the Information Security manager.

People are curious. They are busy. They are under immense pressure to deliver. AI promises speed, polish, and magic fixes.

So, when Dave in Sales pastes your entire customer Q3 prospect list into a public chatbot to “clean up the wording”, that isn’t sabotage. That is a productivity shortcut with catastrophic side effects.

Protecting Users Against Themselves

Protecting users against themselves is no longer optional; it is basic hygiene. If your data is crappy and unsecured, your organisational value is crappy. It’s that simple.

The good news, if you can call having to configure four separate massive platforms “good news”, is that this isn’t a single-tool problem. There is no magic “Stop Stupid” switch in Microsoft 365. You solve this with orchestration across Microsoft Purview, Entra, Defender, and Intune.

Separately, they generate nice reports for you to ignore. Together, they are dangerous in the best possible way.

We solve this problem not with hope, but with architecture. There is no single toggle for data safety; instead, we have to build a cage using Microsoft Purview, Entra, Defender, and Intune.

1. Microsoft Purview (The Data)

Let us start here, because everything else revolves around it. Purview gives you visibility into where your sensitive data actually lives, rather than where you fondly imagine it lives.

• Sensitive Information Types find personal data and business secrets.
• Sensitivity Labels add context and instruct the platform on how to behave.
• DLP Policies decide where that data is allowed to travel.

This is the moment where you stop guessing and start enforcing. If a document is labelled “Confidential”, it should not quietly stroll into a consumer AI service at lunchtime.

2. Entra (Identity & Access)

Data without identity controls is just wishful thinking. Entra decides who gets access, from where, and under what conditions.

Conditional Access turns intention into enforcement. Is the user on a trusted device? Are they compliant? Are they signing in from a risky session at 3 in the morning from a country they’ve never visited? If you let any identity from any device reach sensitive data without friction, you have already lost the argument.

3. Intune ( The Devices)

Devices matter more than most people want to admit. Intune is how you stop unmanaged laptops and mobile phones from becoming a shadow IT freight train.

• Compliance Policies: Encryption enabled. Up-to-date patch level. No jailbroken nonsense.
• App Protection Policies: Ensure company data stays inside protected applications.

You cannot copy it into consumer apps. You cannot casually export it to wherever you fancy. This isn’t about punishment; it’s about steering behaviour by design.

4. Defender (The Watchdog)

Add Defender to the mix, and things get properly interesting.

• Defender for Endpoint watches what actually happens on the device physically.
• Defender for Cloud Apps sees what users are doing across SaaS services.

This is how you discover that someone is suddenly uploading gigabytes of data to an unknown AI service you’ve never heard of. When these signals feed into each other, the security posture immediately tightens based on actual risk. No sternly worded emails. Just physics blocking network packets.

The Uncomfortable Truth

There is a cultural reality hiding underneath all of this:

If your only control is “training”, you are trusting human memory over reality.

People forget. People hurry. People panic on deadlines. Guardrails exist because good intentions are not a security strategy.

How to Achieve Nirvana

We are going to assume, and yes, I know what assumption is the mother of all….., that you have read our previous posts.

Before you attempt the above, ensure you have:

1. Defined your Sensitive Info types and Sensitivity labels.
2. Established a decent baseline of Conditional Access policies.
3. Got your Identity management spot on.

If not, go do that first. None of the following will save you if your foundations are rotten.

• How to fix the FUNDAMENTAL flaw in Conditional Access (Part 1 – Introduction and coverage gaps) – A…
• How to fix the FUNDAMENTAL flaw in Conditional Access (Part 2 – the 5 steps of hardening) – Agder i…
• How to fix the FUNDAMENTAL flaw in Conditional Access (Part 3 – miscellaneous tips) – Agder in the …
• A DIY Purview Journey for Small Admin Teams: Copilot Starts with You – Agder in the cloud
• Get Copilot ready(-ish) – Sensitive info types – Agder in the cloud
• Get Copilot ready(-ish) – with labels – Agder in the cloud
• Get Copilot ready(-ish) – with retention policies – Agder in the cloud
• Automate labeling of sensitive information – Agder in the cloud

So, when we have defined what we want to protect, we can move on with the magic.

The steps

Step 1: Onboard Devices and Enable Defender

Before you can control anything, you need all user devices managed and reporting in. This is non-negotiable.

1. Enrol devices in Intune: Ensure all corporate PCs are enrolled. Intune will deploy the Defender for Endpoint sensor to them. You should be using Intune’s Endpoint Security policies to onboard Windows 10/11 devices automatically. (In Defender’s portal, this is the “Onboard devices” step, where Intune is a listed option).
   • Intune cannot deploy the Defender sensor until it has permission to talk to your Defender tenant.
2. Go to the Intune Admin Center (intune.microsoft.com).
3. Navigate to Endpoint security > Microsoft Defender for Endpoint and look at the Connection status. If it says “Enabled“: You are good.
   • If it says “Not enabled” or “Unavailable”:
     • Click the link on that page that says “Open the Microsoft Defender for Endpoint admin console” (this takes you to security.microsoft.com).
     • In the Defender portal, go to Settings > Endpoints > Advanced features
     • Scroll down to Microsoft Intune connection and toggle it On.
     • Click Save preferences.
     • Go back to the Intune tab and refresh. It should now say Enabled

Step 2: Create the Onboarding Policy

1. Now that the bridge is built, you must tell Intune to push the “Onboard” command to your devices.
2. In Intune, go to Endpoint security > Endpoint detection and response.
3. Click Create Policy.
   • Platform: Windows 10, Windows 11, and Windows Server
   • Profile: Endpoint detection and response
4. Name: e.g., “Defender for Endpoint Onboarding”.
5. Configuration Settings:
   • Find the setting: Microsoft Defender for Endpoint client configuration package type.
   • Select: Auto from connector.
   • Note: This tells Intune to automatically grab the onboarding blob from the connection you made in Phase 1. You do not need to upload a script manually.
6. Assignments:
   • Select Add all devices (or a specific group of corporate devices if you are testing).
7. Review + Create.

Step 2: Integrate MDE with Defender for Cloud Apps

Next, wire up Defender for Endpoint with Microsoft Defender for Cloud Apps (MDCA). This combo lets you discover cloud app usage (including sneaky AI web apps) without needing clunky log uploads or outdated firewalls.

1. In Microsoft 365 Defender portal:
   • Go to Settings –> Endpoints -> Advanced features.
   • Turn on Microsoft Defender for Cloud Apps integration.
   • Crucially, turn on Custom network indicators. This is the bit that lets Defender actually block domains that Cloud Apps flags as dodgy.

2. In Defender for Cloud Apps settings:
   • Go to Settings -> Cloud Apps -> Cloud Discovery -> Microsoft Defender for Endpoint.
   • Turn on Enforce app access. Do not forget this tick box, or nothing will actually get blocked.
   • Choose your bypass settings (e.g., how long a user can override a warning, if you are feeling generous).

This feature is the magic that uses the MDE signals to actually block access to unsanctioned apps at the device’s network layer. MDCA also lets you set up custom redirect URLs for when users hit a blocked app; feel free to send them to an intranet page gently explaining that feeding confidential data to random AI is a sackable offence.

Note: MDCA Cloud Discovery needs a few weeks to gather decent data. Microsoft says 7-30 days. You need to wait while the system builds an inventory of the shadow IT zoo your users are currently frolicking in.

Step 3: Find out which AI tools people actually use

After a week or two, it’s hunting time.

1. In Defender go to Cloud Apps, then to Cloud Discovery -> Dashboard.
2. Open the Discovered apps report.
3. Filter by Category: Generative AI.

Prepare to be horrified. You will likely find entries for ChatGPT or similar with significant traffic volume. MDCA even shows you data exchanged (e.g., “839 MB upload”). Pray that wasn’t your source code.

Review the risk details for your own amusement. MDCA’s catalog shows compliance info. Use this as ammunition when management asks why you blocked their favourite toy: “We blocked it because it lacks basic encryption standards and had a breach last March, Karen.”

Now here’s the kicker: the all-seeing eye of Microsoft is apparently short-sighted. Because my demo environment is ‘too small’, the Generative AI category is completely MIA, and the apps we know we used are nowhere to be found. I consulted my favourite Purview Superstar, and he confirmed the hilarity: apparently, if you aren’t leaking data at a massive enterprise scale, the system simply can’t be bothered to wake up and catch you

So, naturally, my demo environment doesn’t showcase the Generative AI category. I even tried scouring Microsoft’s own documentation for a decent screenshot to save the day, absolutely no luck there either! So you’ll just have to use your imagination to picture the horror.

Step 4: Classify AI Apps

Time to move from passive observation to active decision-making. In this list, where we now see different apps (imagine it being under Generative AI category).

The list show different risk scores:

Step 5: Turn on enforcement and test it

Before you send the smug email to leadership, test it.

1. Double check that Enforce app access is on in MDCA settings.
2. On an onboarded Windows device, try to open an app you marked as unsanctioned (e.g., public ChatGPT) in Edge. You should see a block page from Defender.
3. If it doesn’t work, check your integration toggles and ensure the device network protection is in block mode, not just audit mode.

Step 6: Use Purview Endpoint DLP to stop the actual data paste

Network blocks are nice, but new AI sites pop up daily. Purview Endpoint DLP is where you say: “I don’t care which shiny new chatbot you found; if this data is sensitive, it does not leave the clipboard.”

1. Check prerequisites: Ensure devices are onboarded to Purview (usually happens with MDE onboarding). For non-Edge browsers, you’ll need to deploy the Microsoft Purview extension via Intune.
2. Create an Endpoint DLP policy:
   • In Purview, go to Data loss prevention -> Policies -> Create policy.
   • Choose Custom and select only Devices as the location.
3. Define conditions: Select the sensitivity labels or Sensitive Info Types you want to protect.
4. Under Actions:
   • Choose to restrict browser and network activity.
   • Crucially, select: “Text sent to or shared with cloud or AI apps” and “File uploaded to or shared with cloud or AI apps”.
5. Set the action: Set to Block (or Block with override if you trust your users to have a good reason).

Start in simulation mode. Let it run, review the alerts, and tune the noise before you flip the switch to ‘On’ and face the wrath of users who can no longer paste confidential memos into the web.

Step 7: Close the mobile loopholes

You know someone will just say, “Fine, I’ll use my phone.” Time to ruin that plan too.

1. Enrol corporate phones in Intune and deploy Defender for Endpoint for Mobile.
2. Use App Protection Policies (MAM). This is vital. Configure them so corporate data in managed apps (Outlook, Teams, OneDrive) cannot be cut/copied/pasted into unmanaged, personal apps like the ChatGPT iOS app.
3. If needed, block specific AI apps on corporate phones using Intune app policies (easier on Android).

You won’t get the same granular level of control as on Windows, but you remove the easy route.

What you end up with

After all this clicking, you have something defensible. When the auditor or the Board asks what you are doing about “the AI risk”, you don’t just mutter about a training video.

• Intune ensures devices are managed.
• Defender discovers the tools and blocks the network traffic to the dodgy ones.
• Purview Endpoint DLP stops the actual sensitive data leaving the device clipboard, regardless of the destination URL.

You haven’t banned AI. You’ve just made it significantly harder for your organisation to accidentally donate its intellectual property to become free training data for someone else’s model.