Using Microsoft Purview to Find Files Containing Passwords and Credentials

Passwords have a habit of finding their way into places where they should not be.

  • An Excel workbook containing service accounts.
  • A project handover document with an admin password.
  • A script containing an API key.
  • A configuration file with a connection string.

These are not password-protected files. They are normal files where somebody has written a password, username, API key, token or another credential directly into the content.

Microsoft Purview already has built-in credential detection that can help us find this type of data.

And importantly, if the objective is simply to find these files, we do not need to start by creating a DLP policy.

We can start with Data Explorer.

Let’s take a look.

Credential detection in Microsoft Purview

Microsoft Purview includes a number of built-in Sensitive Information Types, usually shortened to SITs, specifically designed to identify credential patterns.

A good starting point is All Credential Types.

This is a bundled Sensitive Information Type that includes detectors for things such as:

  • General passwords
  • User login credentials
  • Microsoft Entra credentials
  • Client secrets
  • API keys
  • Access tokens
  • Connection strings
  • Shared access signatures
  • Service-specific credentials

There are also individual credential SITs including:

  • General Password
  • User Login Credentials
  • Microsoft Entra user Credentials
  • Microsoft Entra Client Secret
  • Azure SQL Connection String
  • Azure DevOps Personal Access Token
  • GitHub Personal Access Token
  • Client Secret / API Key

This means we can start broad and then narrow the search down if required.

There is an important limitation

Before going any further, there is something worth understanding.

Purview is not a magic password scanner.

It does not simply look through every document and somehow know that a random piece of text is a password.

The credential Sensitive Information Types use supported patterns, keywords and contextual evidence to identify credentials.

For example, something structured like:

username=admin;password=SomePassword

is much more aligned with the documented credential detectors than somebody writing:

The password for the old system is bluechair

Microsoft also documents that the General Password Sensitive Information Type uses English-only password-related keywords.

So this approach can help identify credentials, but it should not be treated as a guarantee that every password somebody has ever written into a document will be found.

Step 1: Test the credential Sensitive Information Type

Before searching production data, it is worth seeing how the credential detection actually works.

In the Microsoft Purview portal:

  1. Go to Information Protection.
  2. Select Classifiers.
  3. Select Sensitive info types.
  4. Search for All Credential Types.
  5. Open the Sensitive Information Type.
  6. Select Test.
  7. Upload a test file containing fake credential values.
  8. Review the results.

I would create a few simple test files containing things such as:

  • A fake username and password
  • A password assignment in a script
  • An XML configuration containing a password
  • A fake API key
  • A fake connection string
  • Normal business text that should not match

Do not use real credentials for testing.

The idea here is simply to understand what Purview is capable of detecting before looking at production data.

Step 2: Open Data Explorer

Now we can see what Purview already knows about the data.

In the Microsoft Purview portal:

  1. Go to Solutions.
  2. Select Information Protection.
  3. Select Explorers.
  4. Select Data Explorer.

Data Explorer provides visibility into content that Purview has classified using things such as Sensitive Information Types and sensitivity labels.

Rather than creating another policy just to discover the data, we can use the classification information that Purview already has.

Step 3: Search for credential information

Within Data Explorer, search for the credential Sensitive Information Type.

A good place to start is:

All Credential Types

This gives us the broadest view of content that Purview has classified as containing supported credential patterns.

From there, we can start drilling into the results.

For example:

All Credential Types

Then: SharePoint

Then: Site

Then: Folder

Then: File

The same approach can be used with OneDrive.

This gives us a way of working from the classification down to the actual location of the file.

Step 4: Narrow the search

All Credential Types is useful for the initial discovery because it covers a large number of credential types.

But sometimes we might want to be more specific.

Instead of searching for everything, we could search for individual Sensitive Information Types such as:

General Password

or: User Login Credentials

Or perhaps we are specifically interested in secrets used by applications: Microsoft Entra Client Secret

Or development credentials: GitHub Personal Access Token

Or database credentials: Azure SQL Connection String

This is where the built-in credential Sensitive Information Types become really useful.

We can start broad and then narrow the investigation depending on what we find.

Step 5: Investigate the files

Once we have identified a file, the next step is to determine whether the match represents a genuine credential.

There are separate permissions within Purview for this.

The Data Explorer List viewer role allows an administrator to see items and their locations.

The Data Explorer Content viewer role provides additional access to the content of those items.

That second permission is obviously sensitive.

If somebody can investigate files containing credentials, they may potentially be able to see the credential itself.

Access to this capability should therefore be limited to the people who genuinely need it.

There is another limitation worth knowing about.

Credential scanning classifiers do not currently support:

  • Contextual summary
  • Redacted preview
  • Match feedback
  • Not a Match feedback

That means credential matches need to be investigated carefully.

Step 6: Remediate what you find

Finding the file is only the start.

If a genuine credential is discovered, a remediation process could look something like this:

  1. Confirm that the match is a genuine credential.
  2. Identify the system or service associated with it.
  3. Rotate or revoke the credential.
  4. Remove the credential from the document.
  5. Replace it with an approved reference to a secrets-management platform.
  6. Review who had access to the file.
  7. Investigate relevant activity if required.

The important part here is rotate or revoke the credential.

Simply deleting the password from the document does not mean the credential has not already been seen or copied.

What about DLP?

This is where I think the distinction becomes important.

If the requirement is:

“Show me files that Purview has identified as containing credentials.”

Start with Data Explorer.

There is no need to create a DLP policy just to perform that discovery.

But once we have established that credentials are being stored in documents, the next question becomes:

How do we stop this happening again?

That is where Data Loss Prevention becomes useful.

A DLP policy can use the same credential Sensitive Information Types as conditions.

For example:

Content contains > Sensitive information types > All Credential Types

The policy could then be used to:

  • Generate alerts
  • Notify users
  • Display policy tips
  • Monitor activity involving the content
  • Apply restrictions where appropriate

So I see the two capabilities as solving slightly different problems.

Data Explorer helps us understand what is already there.

DLP helps us introduce controls around what happens when that type of data is detected.

Taking it further with DLP

Once the initial discovery has been completed, a custom DLP policy could be created.

In the Microsoft Purview portal:

  1. Go to Solutions.
  2. Select Data Loss Prevention.
  3. Select Policies.
  4. Select + Create policy.
  5. Select Custom.
  6. Create a Custom policy.
  7. Select the required locations.
  8. Create an advanced DLP rule.
  9. Add the condition Content contains.
  10. Select Sensitive info types.
  11. Add All Credential Types or the individual credential SITs required.

I would start any new policy in simulation mode.

This allows the policy conditions to be evaluated before introducing enforcement.

Once the results have been reviewed, the policy could then be tuned and appropriate alerts, notifications or restrictions introduced.

Advanced classification scanning and protection must be enabled when credential scanning Sensitive Information Types are used with Endpoint DLP.

This can be configured from:

Data Loss Prevention > Overview > Data loss prevention settings > Endpoint settings > Advanced classification scanning and protection

The Devices location can then be included within the DLP policy.

  1. Go to Solutions.
  2. Select Data Loss Prevention.
  3. Select Policies.
  4. Select the existing DLP policy and select Edit policy.
  5. Ensure Exchange email, SharePoint sites, OneDrive accounts and Devices are selected as locations.
  1. Edit the existing advanced DLP rule containing All Credential Types or the individual credential sensitive information types.
  2. Add the condition Content is shared from Microsoft 365 and select with people outside my organization.
  3. Under Actions, select Restrict access or encrypt the content in Microsoft 365 locations.
  4. Select Block users from receiving email or accessing shared SharePoint and OneDrive content.
  5. Select Block only people outside your organization. This prevents the document being sent externally through Exchange or shared externally through Teams, SharePoint or OneDrive.
  6. Set User notifications to On.
  7. Enable Notify users in Office 365 services with a policy tip.
  8. Customise the policy tip with a message such as: A password or credential is believed to have been detected in this document. This action has been blocked to prevent the document leaving the organisation. Remove the credential and try again.
  1. Ensure User overrides are not enabled so the user cannot bypass the restriction.
  2. Under Incident reports, enable Send an alert to admins when a rule match occurs.
  3. Add the required administrators or security team under Send email alerts to these people.
  4. Create a separate advanced DLP rule for Devices using the same credential sensitive information types.
  5. Under Actions, select Audit or restrict activities on devices.
  6. Set supported exfiltration activities such as uploading to restricted cloud services, copying to removable USB devices, copying to network shares, printing, copying to the clipboard, transferring through restricted applications, Bluetooth and RDP to Block.
  1. Enable User notifications for the endpoint rule and use the same credential-detection message.
  2. Configure the endpoint rule to send an alert to the required administrators when the rule is matched.
  3. Save the rules and select Turn the policy on immediately.
  4. Test the policy by attempting to send the document to an external Exchange recipient, share it externally through Teams and transfer it using the configured endpoint activities.
  5. Confirm that the transfer is blocked, the user is informed that a credential may have been detected and the administrator receives the DLP alert.

The important thing is that DLP comes after we understand the problem, rather than creating a DLP policy simply because we want to search the data.

Licensing

An E5 licence is required to use credential scanning Sensitive Information Types.

This is worth checking before planning the solution.

Summary

There are really two parts to this.

Finding the problem

Use the built-in credential Sensitive Information Types with Data Explorer.

A simple starting point is:

All Credential Types > SharePoint / OneDrive > Site > Folder > File

Then investigate the matches and remediate genuine credentials.

Preventing the problem

Once we understand what is being stored and where, we can introduce Data Loss Prevention using the same credential Sensitive Information Types.

That gives us the ability to move from simply discovering credentials to alerting, educating users and potentially restricting what can happen when credentials are detected.

So the approach becomes:

  1. Test the credential Sensitive Information Types.
  2. Use Data Explorer to see what Purview has already classified.
  3. Search using All Credential Types.
  4. Narrow the investigation using individual credential SITs where required.
  5. Investigate genuine matches.
  6. Rotate or revoke exposed credentials.
  7. Remove credentials from the files.
  8. Consider DLP if ongoing monitoring or prevention is required.

Sometimes the simplest place to start is not another policy.

It is looking at what Purview already knows about your data.

Note: When configuring DLP policies, keep in mind the service limitations of Purview. Particularly the 2 million character scanning limit for file content. If your environment has many files like this, consider deploying auto labelling policies based on file criteria that is likely to occur earlier in the file, then targeting DLP policies at the labels.

Microsoft Learn references

Microsoft Intune Deployment Plans in Preview

Intune deployment plans are now in public preview. Why? Because repeatedly changing group assignments to move a rollout along is a faff, and this gives us a reusable way to stage it.

Start in Devices > Manage devices > Deployments. Create a plan with your test, pilot and broader groups, then set the wait between rings. The plan holds the rollout pattern; a deployment uses it to deliver one app or policy. I would begin with a harmless settings catalog change on test devices.


Watch out for existing assignments. They remain on the underlying app or policy, so a pre-existing broad assignment can defeat your carefully staged deployment plan. If a group assignment collides with an existing payload assignment (payload being the underlying app or policy), Intune places the deployment in an error state and prevents further rollout until the conflict is resolved.

The preview supports Windows Win32 apps, Enterprise App Catalog apps, settings catalog policies and endpoint security policies. For apps, it supports Required installations, not Available or Uninstall. Enterprise App Catalog auto-update is not supported with deployments.

This of course does not replace the need to test the payload changes yourself before you send it to your deployment plan! You can pause, resume or cancel deployments, but cancelling a deployment doesn’t automatically act as a rollback, so consider how you’ll recover devices that have already received the change.

https://learn.microsoft.com/en-us/intune/device-management/deployments/overview

Understanding the Autopilot Lifecycle in Microsoft Foundry

Autopilot agents in Microsoft Foundry are digital workers that operate under two identities: an agent identity and an agent user account.

The agent identity is the standard Entra identity used for authentication and governance. The additional user account is what makes an agent an autopilot agent. It gives the agent its own email, calendar, OneDrive, Teams presence, and a place in the organisation chart. This allows the agent to participate naturally in Teams chats, access SharePoint, respond to events, and work with groups rather than only individuals.

Without this user account, an agent can only perform Microsoft 365 actions on behalf of a signed‑in user, which is limiting in collaborative or event‑driven scenarios. The autopilot model resolves this by giving the agent a persistent identity that fits into everyday organisational workflows.

The lifecycle begins with the Blueprint layer. Developers define the agent’s purpose, capabilities, and boundaries, then publish the blueprint. This becomes the template for every instance created later and is effectively the agent’s job description and technical specification.

The Instance layer is where managers hire agents from that blueprint. Each instance receives its own identity, is onboarded into a team, and is granted access to the resources it needs. This is where the agent becomes operational and able to work within Microsoft 365 surfaces such as Teams and SharePoint.

Above both sits the Fleet layer, owned by tenant administrators. This is where approval, policy, consent, licensing, and oversight are applied. The fleet view provides visibility across all agents in the tenant and ensures they comply with organisational rules.

The lifecycle follows a predictable sequence:

✅ Provision – Azure administrators set up the Foundry platform and assign developer permissions.

✅ Build and publish – developers define and test the blueprint.

✅ Approve and configure – tenant administrators review the blueprint, apply policy, and decide who can hire agents from it.

✅ Hire – managers create an instance and give it a role.

✅ Onboard – access managers or team leads grant the agent the resources it needs.

✅ Operate – the agent performs its work, with managers and teammates observing and adjusting as required.

✅ Offboard – when the agent is no longer required, the manager removes it.

✅ Retire or delete – tenant administrators or developers stop new hires or remove the blueprint entirely.

The strength of this model is in its clarity. Each role has a defined responsibility. Autopilot agents become part of the organisation’s operational structure rather than isolated experiments, making them easier to govern, secure, and scale.

Further reading: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/autopilot-lifecycle

Purview Auto-labelling at enterprise scale – 20M-item simulations, 50,000 sites

Simulations now cover up to 20 million items and 50,000 sites via adaptive scopes, policies can be edited without re-running simulation, and new audit insights show coverage and processing activity.

This removes the ceiling that forced large-estate labelling designs into artificial site batches – revisit your simulations and rollout plans you scoped around the old limits.

Scroll down to the Auto-labelling bit to read more: https://www.microsoft.com/en-us/security/blog/2026/09/24/whats-new-in-microsoft-security-september-2026/

Intune Compliance will soon detect shadow AI

Intune Admins, AI governance is coming to you too muh hahaha 😁

On the Intune roadmap: Admins will be able to define a list of prohibited local agents (OpenClaw is the named example); detection flips the device to non-compliant and Conditional Access bites until it is removed.

This is an exciting endpoint-side control customers can point at for shadow AI agents – expect it in every AI-governance workshop

Roadmap Link: https://learn.microsoft.com/en-us/intune/whats-new/in-development#mark-windows-devices-noncompliant-when-prohibited-ai-agents-are-discovered

Foundry Model Router’s new preview feature: Session affinity for Chat Completions

Chat Completions API now allows you to pass an opaque session ID and the router attempts to keep the same eligible model across conversation turns, expiring after 30 minutes of inactivity.

Fixes the “why did its tone change mid-conversation?” complaint on routed chat workloads and improves prompt-cache reuse

Read more, including code examples: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/model-router?tabs=foundry-responses#keep-chat-completions-requests-on-the-same-model-preview

GPT-6 Astra gets Microsoft Foundry EU Data Zone Support

🚀 Microsoft announced GPT-6 Astra in Microsoft Foundry on 3 September 2026 and Microsoft just added EU Data Zone support for Astra a few days ago 🥳

Astra’s selling point is computer use. It interprets what is on screen and interacts with approved interfaces, including workflows that never had a decent API. Updating records, navigating development tools, testing software, assembling results into a report. Microsoft’s own line is “Capability this direct demands containment”, which is unusually blunt for a launch post, and I am glad somebody wrote it down!

What they mean by containment is scoped credentials, approved resources, human checkpoints for consequential actions and activity records you can go back and read. None of that is new thinking. It is ordinary identity and access work, and it is the bit where some evangelists eyes start to drift off.

Pricing is where things get spicy: In Foundry, running a workload of 10 million input and 2 million output tokens will cost $140.00 on GPT-6 Astra compared to $56.00 on GPT-5.6 Sol

There are legacy systems out there that are crying out for automation but lack the APIs. Could Astra bridge the gap?

Read more: https://azure.microsoft.com/en-us/blog/gpt-6-astra-frontier-intelligence-for-work-now-generally-available-in-microsoft-foundry/

Block or Monitor Sensitive Data Access by a Local AI Model using Purview Endpoint DLP

As AI tools become more prevalent on endpoints, how do we ensure they don’t get their virtual hands on sensitive files? In this blog post, I’ll walk through a hands-on lab using Microsoft Purview Endpoint DLP to block a Foundry Local AI model from accessing a classified document on a Windows 11 device. I also discuss options for deploying the themes covered in production.

Scenario: We have a document that we know contains sensitive data on a Windows 11 device, labelled as Confidential. We have another document on the same device that contains sensitive data and is not labelled. We’re going to use Microsoft Foundry Local (a CLI tool for running AI models locally) to attempt to process that file. With the right Restricted App policy in Purview, the AI model’s process will be blocked from opening the file. The policy settings can also be set to only Audit so that Endpoint DLP monitors the sensitive data usage.

We’ll set up everything from scratch: enabling Endpoint DLP, tagging a file as sensitive, adding Foundry CLI as a restricted app, creating the DLP policy, and then testing the block while capturing logs and evidence. Below is a 2 minute video showing what the user experience is like:

Let’s get started!

Pre-requisites

Licensing:

  • Microsoft 365 E5 or E5 Compliance license (for Endpoint DLP).
  • Audit enabled in Microsoft Purview (usually on by default in E5 tenants).

Device:

  • Device running Windows 11 Pro, Enterprise or Education

User Rights:

  • Local administrator rights on the device (to run onboarding scripts and install Foundry CLI).
  • Purview DLP admin permissions in the tenant (to configure DLP policies and restricted apps).

Step 1: Onboard Your Windows 11 Device to Purview Endpoint DLP

First things first – your endpoint (the Windows 11 PC) needs to be known to Microsoft Purview’s DLP service. This is done by onboarding the device to Microsoft Defender for Endpoint, which in turn lights up Purview Endpoint DLP capabilities. If you’ve already got the device in Defender for Endpoint, you’re likely set. If not, here’s how:

  • Generate an onboarding package: In the Purview portal (purview.microsoft.com), go to Settings > Device onboarding > Onboarding. Choose Windows 10/11 and download the onboarding script or the MSI package. (For Intune-managed environments, you can download an onboarding policy for MEM.)
  • Run the onboarding script: Copy the script to the Windows 11 PC (or use Intune to deploy). Run it as administrator. It will configure the device and register it with your tenant’s Defender for Endpoint. A reboot might be required.
  • Verify onboarding: After a few minutes, check the Devices list in the In the Purview portal, go to Settings > Device onboarding > Devices. You should see your device listed as onboarded. You can also run sc query sense in an elevated command prompt on the PC to see if the Defender for Endpoint sensor (“Sense” service) is running – a good sign.

If the device shows up and is active, congrats – you now have an endpoint that Purview can protect with DLP policies. (“Enrolment” complete! ✓)

Note: Ensure the Windows user you’ll test with has an E5 Compliance licence assigned (since Endpoint DLP is an E5 feature). Also, enabling Auditing in Purview (via purview.microsoft.com > Solutions > Audit) is required so that all actions get logged. In an E5 tenant, audit is typically on by default.

Step 2: Prepare a Sensitive File to Protect

We need a file that our DLP policy will treat as sensitive. This could be any document containing confidential info or explicitly labelled as such:

  • Create a test file: For example, I opened Notepad and entered some dummy personal data:
Employee Salary List (Confidential)

Name: John Doe – Salary: £70,000

Credit Card: 4111 1111 1111 1111

Save this as SensitiveData.txt on the device. The credit card number will trigger built-in DLP detectors.

  • Create a second test file and apply a sensitivity label: Copy the text into a Word document but remove the credit card number. If you have sensitivity labels published (like “Confidential” or “Highly Confidential”) we can use these, otherwise you will need to publish a new Purview Information Protection sensitivity label. I saved a copy as SensitiveReport.docx and applied my “Confidential” label.

Now we have two files that are definitely sensitive. Purview can identify them either via the sensitivity label metadata or by scanning the content (e.g. detecting that 16-digit number as a credit card number).

Step 3: Mark Foundry Local CLI as a Restricted App

This is the pivotal configuration: telling Purview that the Foundry Local CLI is not allowed to touch protected content. Foundry Local is invoked via the foundry command. Under the hood, that’s an executable (on Windows it is foundry.exe). We’ll add that to the restricted apps list:

  • In the Purview portal, go to Settings > Data Loss Prevention > Endpoint DLP Settings > Expand Restricted apps and app groups.

Click Add an app:

  • App name: Give a friendly name like “Foundry Local CLI”.
  • Windows executable name: This must match the process name. In this case, type foundry.exe (the CLI later installed via winget uses this command). No need for a path, just the exe name.
  • (No need to fill Mac info for our Windows scenario.)
  • Auto-quarantine: Leave this unticked. (Auto-quarantine is more for things like Dropbox apps – not needed here, we just want to block.)

Hit Save. You should now see “Foundry Local CLI (foundry.exe)” in the Restricted apps list.

Ensure the entry is there. The default behaviour for restricted apps (unless overridden by policy) is to audit. We will enforce the block via policy next. The settings page will look like this:

Now Purview knows about the Foundry CLI. Next, we’ll configure the actual DLP policy rule that leverages this.

Step 4: Create a DLP Policy to Block Restricted App Access

We’ll create a custom DLP policy that targets our sensitive info and blocks any restricted app (like foundry.exe) from accessing it. Here’s how:

  • In the Purview portal, go to Data Loss Prevention > Policies > Create Policy > Data stored in connected sources.
  • Choose Custom policy. Name it something like “Block Sensitive Data to Foundry Local AI”.
  • On Assign admin units select Next.
  • On Locations: Tick Devices (we want this on endpoints), and untick all the other options.
  • To the right of the ticked Devices > Edit the scope, IMPORTANT: Only apply this to your test groups
  • Name the rule “Sensitive content” and add conditions.:
    • Click Add condition > Sensitive info types. Pick “Credit Card Number” and set it to at least 1 instance. (Our file has one, so that’ll hit.) You could also add “UK National Insurance Number” or whatever fits your content. Each added type is an OR by default (any one matching triggers the rule).
    • Additionally, add Sensitivity label as a condition. Select the label Confidential. Now the rule will trigger if the file has that label OR matches an SIT. You can have multiple conditions; by default it’s “Any condition matches”.
    • Tip: If using multiple, ensure to group accordingly if needed. In our case, Credit Card OR Confidential label is fine.
  • Scroll to Actions > Select Audit or restrict activities on devices.
  • set File activities for all apps to Apply restrictions to a specific activity
  • Select Copy to clipboard > Block. Untick all the other options. I’ll explain why we need this later in the post.
  • Under App access restrictions > Tick Access by restricted apps > Select Block. This corresponds to any app we put in the restricted list trying to open the file.
  • Toggle “User notifications” on for endpoint. This ensures the user sees a popup when the policy triggers. You can customise the message if you like (“Blocked: confidential data can’t be used with this app”) but it’s optional.
  • For the lab, I toggled on Alerting for this rule. This way, when it triggers, an alert is generated in Purview (useful to demonstrate logging). Set it to alert every time or just the first time – up to you.
  • Choose Turn the policy on immediately (not simulation mode) since we want the block to actually happen now. Click Submit and let it publish.

It can take a long time for policy changes to take effect, anywhere from 1 to 24 hours. The DLP agent on the device will download the new policy in the background. So, time for a break!

Step 5: Run Foundry Local CLI and Attempt to Access the File

Time for the fun part – will our AI model be thwarted by DLP? Let’s simulate a user (us) trying to feed the sensitive file into the local AI model:

  • Install Foundry Local on the Windows device by running the below command
winget install Microsoft.FoundryLocal
  • Open Command Prompt (as the regular user, not admin). Start a model by running a command:
foundry model run phi-4-mini

This tells Foundry Local to run a small instruction-following model (phi-4-mini). It will download the model if not already cached, then start an interactive session

You’ll see some logs of model loading, then a prompt like Foundry > indicating it’s ready for input.

Press Ctrl + C to exit the foundry prompt

Now we will test our DLP policy:

  • Test A: Redirect the unlabelled file into Foundry: Type the command (replacing the file location with your file’s location):
foundry model run phi-4-mini < "C:\Users\AlexWilber\OneDrive - Contoso\Documents\SensitiveData.txt"

This uses shell redirection to pass the file content as input to the model.

  • Result – Blocked! The command line reported that Access to the file is blocked. I immediately got a Windows notification in the bottom-right: “Blocked: Confidential data can’t be used in this way”. Bingo! The foundry.exe process was prevented from reading SensitiveData.txt.
  • In the Purview portal > Solutions > Data Loss Prevention > Explorers > Activity Explorer > Search for an activity called ‘DLP rule matched‘. Open the match for your device and the file you tried to access. Below are the details for this blocked action
Click an image to expand

Test B: Redirect the labelled file into Foundry: Type the command (replacing the file location with your file’s location):

foundry model run phi-4-mini < "C:\Users\AlexWilber\OneDrive - Contoso\Documents\SensitiveReport.docx"

This uses shell redirection to pass the file content as input to the model.

  • Result – Blocked!  The command line reported that Access to the file is blocked I immediately got a Windows notification in the bottom-right: “Blocked: Confidential data can’t be used in this way”. The foundry.exe process was prevented from reading SensitiveReport.docx.
  • In the Purview portal > Solutions > Data Loss Prevention > Explorers > Activity Explorer > Search for an activity called ‘DLP rule matched‘. Open the match for your device and the file you tried to access. Below are the details for this blocked action
Click an image to expand

Test C: Copy/Paste: We know that foundry.exe cannot read the files directly. But what if your user wanted to copy and paste the sensitive content in to the AI model’s prompt? To prevent this we have used a sledgehammer. Due to a limitation of Purview Endpoint DLP, there is no Purview option to Block pasting data into foundry.exe when it is accessed via the command line. We must block the data being copied into the clipboard in the first place.

Suppose we had a local application that uses a local AI model under the hood, like a chat bot. That app is accessed via a web front end using Edge browser. We could set our DLP policy to block 'Paste to supported browsers' so that we don't have to completely block the ability to Copy the data to the clipboard.

Remember in our DLP policy we blocked Copy for all apps? Well, this is the sledgehammer! No application on this device will be able to copy our sensitive data in to the clipboard (the Credit card number from the unlabelled text file or data from the labelled Word document).

To test this, we open SenstiveData.txt and try to copy the Credit Card number. It is blocked.

We try the same with any data in SenstiveReport.docx and it is also blocked.

This is indeed a sledgehammer as it impacts how the user can work with data that they may have a legitimate need to copy and paste into different applications. Instead, you could use a Block with override policy setting that allows the user to proceed with the Copy after they have been warned not to use it with the local AI model.

Lastly, go to Purview portal > Solutions > Data Loss Prevention > Alerts. Here we see the Low priority alerts we configured to trigger in the DLP policy.

Additional Notes and Observations

  • Foundry Local CLI specifics: Currently, Foundry’s model run command doesn’t have a built-in “open file” parameter (it’s geared for interactive chat2). We simulated file input via shell redirection.
  • Scope of policy: We applied the policy to all devices/users for simplicity. In production, you could scope it to specific users or device groups. For instance, maybe only apply to users in a particular department initially, or exclude certain test machines.
  • Audit vs Block: We went straight to blocking to demonstrate the feature. A best practice is to start with Audit mode to see how often an event would trigger. If you had run our policy in Audit, then Foundry would have received the data but the event would still be logged as “Access by restricted app (Audit)”. After confidence, you flip to Block. For a lab/demo, Block is more dramatic to show 😃.
  • Limitations: This solution prevents direct file access or copying. It doesn’t cover a scenario where a user might manually re-type info or if they took a screenshot and fed that to an AI (that’s a different vector – though Purview can also block screen captures of labelled content if you disable the Copy permissions in Access Controls in the sensitivity label).
    The policy does not differentiate which model is running – it blocks the Foundry CLI entirely from those files. In some orgs, you might eventually allow certain vetted models but not others; currently, the control is at the app level rather than model granularity.

Conclusion

We successfully showed that Microsoft Purview Endpoint DLP can safeguard sensitive files from being processed by a local AI model. By configuring foundry.exe as a restricted app and creating a DLP policy to block its access to classified data, the system prevented the data from ever leaving its file – the AI got nothing.

This lab mirrors real-world concerns: employees might be tempted to use powerful local AI tools (like Foundry, chat bot clients, etc.) with work data. With proper DLP controls, you can permit the benefits of AI while mitigating the risks of unauthorised use of AI with sensitive information.

If blocking is not your priority but monitoring is, then you can leverage Endpoint DLP in Audit mode which feeds alerts to the Purview portal. Then use Purview Insider Risk Management policies to detect risky behaviour, such as an application that uses local AI opening many documents that contain sensitive information when that is not normal for how the AI model was intended to be used.

Happy labbing, and stay secure while you innovate!

Windows 11 Snap Layouts – Multitasking Tool Overview

💡 Many organisations are completing their Windows 11 rollouts, and the improved Snap layouts feature is one I see underused for multitasking. Despite being around since Windows 10, I encounter many people who are unfamiliar with it.
I’ve made a short video showing how Snap layouts work and why they’re a highlight for anyone juggling multiple apps. If you’re new to Windows 11 or just want to get more organised, this is worth a look.

Let me know if you’ve found other Windows 11 features that help you work smarter.

M365 Copilot & Your Data: 4 Common Misconceptions

Since Microsoft 365 Copilot landed, I’ve had many conversations with businesses who are anywhere from just starting on their journey with it to being advanced users. I have listed here some common misconceptions I hear about data and M365 Copilot. Most of them boil down to one thing, misunderstanding what Copilot actually is and how it works under the bonnet.

In this post I talk about the paid license M365 Copilot that is typically used by businesses, not the free, personal Microsoft Copilot.

So let’s clear the air. Here are four common misconceptions I’ve heard, and the real story behind each one.

Misconception 1: “When I buy Copilot, I get my own private AI model”

Nope, that’s not how it works.

When you license Copilot, you’re not spinning up your own personal GPT instance tucked away in a private server. What you’re actually getting is secure access to a shared large language model hosted in Microsoft’s cloud. Think of it like renting a lane on a motorway, you’re using the same infrastructure as everyone else, but your data stays in your own vehicle.

Microsoft’s architecture is designed to keep your data isolated. Your prompts and context are processed securely, and your content is never used to train the model. So while the model is shared, your data isn’t.

Misconception 2: “My data never leaves my tenant”

This one’s a bit trickier. Your data does reside in your tenant, but when you use Copilot, the relevant bits of it are sent to Microsoft’s cloud-based AI models for processing.

That means your prompt and the context Copilot gathers, emails, files, chats and so on, are securely transmitted to the nearest available AI compute cluster. If that cluster’s busy, your data might be routed to another Microsoft datacentre, possibly in another country. But if you’re in the EU, Microsoft guarantees that your data won’t leave the EU boundary.

So yes, your data leaves your tenant, but it stays within Microsoft’s secure cloud, and within the rules.

Misconception 3: “Copilot can access all ‘Anyone’ share links in my organisation”

Not quite.

An ‘Anyone’ link, the kind that lets anyone with the link view a file, doesn’t automatically make that file searchable. For Copilot to surface content from an ‘Anyone’ link, the user must have redeemed the link, meaning they’ve clicked it and accessed the file.

Until that happens, Copilot treats the file as off-limits. It operates strictly within the context of the user’s permissions. So if you haven’t clicked the link, Copilot won’t see it, even if the link exists somewhere in your tenant.

Also worth noting, ‘Anyone’ links are risky. They’re essentially unauthenticated access tokens. Anyone can forward them, and there’s no audit trail. Use them sparingly.

Misconception 4: “Copilot only sees my data if I attach it to the prompt”

Wrong again.

Copilot doesn’t wait for you to upload a document or paste in a paragraph. It automatically pulls in any content you already have access to, emails, OneDrive files, SharePoint docs, Teams chats, calendar entries, the lot.

This is called grounding. When you ask Copilot a question, it searches your Microsoft 365 environment for relevant context, then sends that along with your prompt to the AI model. If you’ve got access to a file that answers your question, Copilot will find it, no need to attach anything manually.

That’s why data access controls are so important. If a user has access to sensitive content, Copilot can use that content in its responses. It won’t override permissions, but it will amplify whatever the user can already see.

Final Thoughts

M365 Copilot is powerful, but it’s not magic. It works within the boundaries of Microsoft 365’s architecture, permissions and security model. Understanding those boundaries is key to using it safely and effectively.

If you’re rolling out Copilot in your organisation, make sure your users understand what it can and can’t do and make sure you know how to protect your data.

Further Reading