Stop securing the AI. Secure the data.

The more AI security discussions I have, the more I think we are starting in the wrong place.

We talk about securing Copilot, governing agents, blocking external AI services and deciding which new AI features users should be allowed to touch. All perfectly sensible things to discuss, but none of them are really the security boundary.

Copilot isn’t the security boundary. Neither is ChatGPT, an agent, or whichever AI tool turns up next month.

Your data is.

And your users are going to give AI access to it.

They will ask Microsoft 365 Copilot to summarise documents, paste customer information directly into prompts and upload spreadsheets because reading twelve rows of Excel manually is now considered an unreasonable burden on humanity. If you block one AI experience, somebody will eventually find another.

This is why I think we need to be a little more precise when we talk about AI security. Much of what we are trying to solve is still data security, except AI has made accessing, combining, summarising and moving information dramatically easier.

For years, one of our main security questions has been can this user access the data? That still matters, obviously. But it is no longer enough on its own.

We also need to ask what is this user, application or AI allowed to do with the data once access has been granted?

Those are two very different security decisions, and that distinction is where this gets interesting.

AI did not invent data leakage

Before blaming AI for every security concern, it is worth remembering that humans were perfectly capable of leaking data before ChatGPT arrived.

We emailed documents to personal accounts.
We copied customer lists into spreadsheets.
We uploaded files into random cloud services.
We shared SharePoint sites with half the organisation because somebody selected Everyone Except External Users in 2019 and nobody has wanted to touch the permissions since.
AI did not create poor data governance.

It removed the friction.

Imagine this highly sophisticated attack:

1. A user opens an Excel spreadsheet containing customer information.
2. They select thirty rows.
3. Copy.
4. Open Copilot Chat.
5. Paste.
6. Ask Copilot to identify the customers most likely to churn.

There has been no malicious hacking, no elaborate exfiltration technique and no dark room full of blinking monitors.
Just the copy/paste we have always done.

AI changes the speed and scale of an old problem. Our controls therefore need to protect documents, prompts and user actions, not merely the AI product.

Stop securing the AI product

One mistake I see organisations making is creating a separate governance programme around every AI capability.

We approve Microsoft 365 Copilot, so we create a Copilot governance programme.
Somebody discovers Copilot Studio, and off course we create an agent governance programme.

Another AI service appears, and yet another governance programme.
At some point the governance team will need a governance programme for its governance programmes.

Make the data the policy anchor.

If we understand what the information is, how sensitive it is, who should have access to it and what should be allowed to happen to it, Copilot becomes another consumer of those controls.

Microsoft Purview provides many of the pieces for this model: classification, sensitivity labels, Data Loss Prevention, Endpoint DLP, Data Security Posture Management, Audit and Insider Risk Management.

The policy starts with the information.

The architecture looks like the image to the left.

The important bit is at the top.

Corporate data.

Not Copilot.

Not the large language model.

Not whichever AI feature marketing discovered last Tuesday.

Figure 1: A data centric Microsoft AI security model: classification anchors policy, DLP controls Copilot and endpoint actions, and Purview monitoring feeds continuous improvement.

Classification is the prerequisite, not the project

Before we go any further, I am going to assume you already have a basic understanding of sensitivity labels, Sensitive Information Types and SharePoint permissions.

We have covered those subjects extensively on Agderinthe.cloud, including:

• Sensitivity label design and the mistakes organisations repeatedly make
• Automatic and recommended classification
• Creating and testing Sensitive Information Types
• SharePoint permissions and oversharing remediation

Those controls are the foundation of everything discussed here.

Labels that do not reflect business risk create poor policy decisions, and noisy Sensitive Information Types can create false positives. We see that bad SharePoint permissions give Copilot access to information that should never have been broadly accessible. So if those foundations are not in place, start there first, and for this discussion, treat them as prerequisites.

The important point is not how the label is created.

The important point is what security decision the label enables.

So if we look at it like this, consider a document called:

Project Aurora Acquisition Strategy.docx

The user has permission to open it.

User access: Allowed

The document also carries the label:

Highly Confidential

That gives us a second decision:

Copilot processing: Restricted

Same user. Same document. Same identity.

Different permitted action.

Copilot still operates within the user’s existing access permissions. Purview DLP does not replace those permissions. It can prevent Copilot from processing content that the user would otherwise be allowed to access directly.

There is another layer here too.

Sensitivity labels can enforce protection themselves through encryption and usage rights. Finding a protected file does not automatically mean an AI application can process its contents. For encrypted content, the user must have the appropriate usage rights, including the rights required to view and extract the information.

DLP therefore sits alongside label protection rather than replacing it.

Before you start

Before deploying Copilot DLP controls, make sure you already have:

• A sensitivity label taxonomy aligned with actual business risk
• Sensitive Information Types that reliably identify regulated or sensitive content
• SharePoint and OneDrive permissions reviewed for oversharing
• A test group for validation

If you need guidance on those areas, use the existing articles on Agderinthe.cloud (

This article focuses on what comes after those foundations are in place

Make Highly Confidential mean something

Suppose the organisation uses four labels:

• Public
• Internal
• Confidential
• Highly Confidential

The organisation decides that content marked Highly Confidential must not be processed by Microsoft 365 Copilot or Copilot Chat.
Now the label needs to trigger an actual security control.

Create the Copilot DLP policy

1. Open the Microsoft Purview portal.
2. Go to Data Loss Prevention -> Policies.
3. Select Create policy.
4. Select Custom, followed by Custom policy.
5. Name it something useful, such as Copilot – Restrict Highly Confidential content.
6. On Locations, enable Microsoft 365 Copilot and Copilot Chat.
7. Select Create or customize advanced DLP rules.
8. Create a rule using Content contains -> Sensitivity labels.
9. Select the Highly Confidential labels Copilot must not process.
10. Set the action to Restrict Copilot from processing content.
11. Enable the appropriate alerts and run the policy in simulation mode first.

The Microsoft 365 Copilot and Copilot Chat location is available only in a custom policy. Selecting it disables the other DLP locations for that policy, so keep Copilot rules separate from policies targeting Exchange, SharePoint, Teams or devices.

When the rule matches, Copilot does not use the protected file or email content to generate its response. The item can still appear as a citation, but its content is not used to construct the answer.
The user’s direct permission to open the item remains unchanged.

Now the user asks:
Summarise everything we know about Project Aurora.

Copilot discovers:

Project Aurora Meeting Notes.docx
Label: Internal

Project Aurora Timeline.xlsx
Label: Internal

Project Aurora Acquisition Strategy.docx
Label: Highly Confidential

Project Aurora Financial Model.xlsx
Label: Highly Confidential

The user can still open all four documents.

But the Highly Confidential documents are excluded from Copilot processing.
The user’s permissions have not changed.
The permitted use of the information has.

There are, naturally, a few catches:

• Policy updates can take up to four (or more….) hours to appear in Copilot.
• The Copilot DLP location does not support administrative units.
• In Word, Excel and PowerPoint, the policy is evaluated when the file opens. If the relevant label changes during the session, reopen the file when testing the new state.
• Email coverage has workload limitations, including support for applicable Exchange email sent on or after 1 January 2025.
• Calendar invitations are not currently supported.

DLP evaluates the text entered into the prompt. Do not assume that this control will inspect the contents of a file simply because somebody uploaded it into the conversation.

That distinction matters. A lot.

Protect the prompt as well as the document

Users do not need to attach a file to give AI sensitive information.

They can simply type it:

Customer: John Smith
National ID: 12345678901
Account: 9847291
Can you summarise this customer?

The file label rule will not help because there is no file involved.
This is where Sensitive Information Types become useful as conditions for the prompt itself.

Block a sensitive prompt

Create another rule in the Copilot DLP policy:

1. Add Content contains -> Sensitive information types.
2. Select the SITs representing information users must not submit.
3. Set the action to Restrict Copilot from processing content -> Processing prompts.
4. Run the rule in simulation before enforcement.

When the rule matches, Copilot does not return a response and does not use the prompt for internal Microsoft 365 or external web searches.

At the time of writing, Microsoft documents prompt blocking as preview functionality. Check the current Microsoft documentation and confirm that the capability has reached your tenant before designing your entire security architecture around the screenshot you saw on LinkedIn.

Allow Copilot, but block external web grounding

Not every sensitive prompt needs to be blocked completely.
A less restrictive policy can allow internal Microsoft 365 processing while preventing a sensitive prompt from being used for external web search.

Use:

1. Content contains -> Sensitive information types
2. The relevant SITs
3. Restrict Copilot from processing content -> Performing Web Searches

Copilot can continue answering from permitted internal Microsoft 365 sources, but external web search is removed as a grounding source for that interaction.

Sensitivity labels and Sensitive Information Types cannot be combined in the same rule. You can create separate rules for each condition inside the same Copilot policy.

Test before pressing the big red button

Do not build this policy on Friday afternoon, switch it directly into enforcement and disappear for the weekend. This should not need saying, but experience suggests otherwise.

At the end of the DLP policy wizard, select Run the policy in simulation mode.

Simulation mode lets you review matches without applying the blocking action. Review the simulation results, matched items and alerts before enforcement.

Your test plan should include:

1. A prompt containing a known value for each important SIT.
2. A clean prompt that should be allowed.
3. An Internal document Copilot should process.
4. A Highly Confidential document Copilot should exclude.
5. A query that finds both permitted and restricted sources.
6. A sensitive prompt with web search enabled.
7. A direct file upload, so the team understands the upload limitation.
8. Retesting after policy propagation.

Validate the results with data owners, not only the security team.
If legitimate work is blocked, fix the classifier or the rule.

Do not train users to ignore bad security controls until the controls become decorative.

Copilot did not create oversharing

If Copilot suddenly surfaces thousands of files to users, Copilot is rarely the root cause.

The problem probably existed long before AI arrived.
We have written extensively about SharePoint oversharing, permission sprawl and remediation on Agderinthe.cloud.
Copilot makes those problems painfully visible because it is very good at finding information users already have permission to access.

The permissions problem was already there, and AI just made the consequences considerably easier to see.

AI readiness is really SharePoint hygiene with a deadline.

The current Microsoft product name is Microsoft Purview Data Security Posture Management, or DSPM. The older DSPM for AI (classic) experience may still be visible, but Microsoft is moving new capabilities into the current DSPM experience.

A useful starting workflow is:

1. Open Microsoft Purview -> Solutions > DSPM.
2. Complete the initial Getting Started configuration if DSPM has not previously been configured.
3. Open Objectives and review risks and remediation plans relevant to Microsoft 365 Copilot and sensitive data.
4. Open AI observability to review AI applications, agents and sensitive interactions.
5. Go to Discover -> Activity explorer -> AI activities to investigate AI activity, sensitive information detections and DLP matches.
6. Go to Discover -> Data risk assessments to identify potential oversharing and sensitive data exposure, including SharePoint and OneDrive scenarios.
7. Review Actions -> Remediation actions for recommended controls and policies.
8. Validate remediation actions before applying them.

DSPM brings the visibility together, but it is not a substitute for enforcement.

Think of DSPM as the place where you discover what is happening, identify control gaps and decide what needs fixing next.

Protect data when it reaches the device

Copilot DLP controls what Microsoft 365 Copilot can process, but it does not magically stop somebody from opening the same information and trying another route.

• Open document.
• Copy sensitive data.
• Open browser.
• Paste.
• Hello ChatGPT.

That is where Endpoint DLP becomes relevant.

The implementation pattern is:

1. Onboard supported Windows or macOS devices to Microsoft Purview.
2. Go to Data Loss Prevention -> Settings -> Endpoint settings.
3. Under Browser and domain restrictions to sensitive data, configure the required Sensitive service domain groups.
4. Create a DLP policy scoped to Devices.
5. Add conditions using the SITs or labels appropriate to the activity.
6. Select Audit or restrict activities on devices.
7. Configure actions such as Paste to supported browsers, uploading to cloud services or copying to the clipboard.
8. Start with Audit, move selected scenarios to Block with override, and use Block for unambiguous high risk cases.
9. Review events and overrides in Activity Explorer.

This is where Endpoint DLP gets slightly annoying.

Paste to browser evaluates the pasted content independently of the classification of the source file.

It uses Sensitive service domain groups rather than the general Service domains setting. The activity can be audited, warned or blocked according to the destination and policy configuration.
Browser support also matters.
Microsoft Edge is supported natively on Windows and macOS. On Windows, Chrome and Firefox require the Microsoft Purview browser extension for the documented scenarios. On macOS, Edge, Chrome, Firefox and Safari are supported natively for this scenario.

Paste to browser performs classification locally. Classifiers that depend on advanced cloud classification, including Exact Data Match, named entities, trainable classifiers and credential classifiers, are not supported for this action.

So test the exact classifier you intend to use. Not one that looks similar. The actual one.

Microsoft Purview also supports controls for ChatGPT, Gemini and other external AI services. Those scenarios introduce additional endpoint, browser, collection and licensing decisions.

That might be in the next post, because they deserve their own article.

Detection matters too

Blocking everything is not governance, it is usually panic with a policy engine and WILL generate a lot of users doing everything wrong..

Some interactions should be allowed. Others should generate warnings, be audited or be blocked. Individual events can also become far more interesting when they form part of a larger pattern.

Audit the interaction

Microsoft Purview records supported Copilot activities in Audit when auditing is enabled. Copilot audit records can include the user, time, host application, accessed resources, sensitivity label identifiers and policy details.

For an initial investigation:

1. Open Microsoft Purview -> Audit.
2. Search for the operation CopilotInteraction.
3. Filter by user and time range.
4. Review AppHost to identify where the interaction occurred.
5. Review AccessedResources for referenced files, emails, sites and labels.
6. Review PolicyDetails where Copilot access was restricted.
7. Check AISystemPlugin.Id for BingWebSearch to determine whether public web grounding was used.
8. Export the results if deeper analysis is required.

Audit will give you the event trail, but it’s not your Copilot usage reporting system.

The standard audit search also should not be treated as a convenient window into everyone’s actual conversations with Copilot. That is far beyond what is acceptable usage.

For authorised content level investigation, use the AI activities experience in DSPM Activity Explorer or an appropriate eDiscovery workflow, with tightly controlled roles and the required collection policies.
Because giving the entire security team unrestricted access to employee AI conversations would be an interesting interpretation of governance..

Add behavioural detection

A single DLP event tells you something happened, and a pattern can tell you considerably more.

For behavioural investigation:

1. Open Insider Risk Management -> Settings -> Policy indicators.
2. Enable the relevant Generative AI apps indicators. Global indicators are disabled by default.
3. Check the prerequisites for the signals you intend to use, including browser extensions and browsing indicators where required.
4. Create a policy using the Risky AI usage template.
5. Scope users and prioritised content appropriately.
6. Configure thresholds.
7. Review alerts, activity timelines and supporting evidence.
8. Confirm or dismiss the activity based on investigation, not assumption.

Insider Risk Management is privacy aware by design. Users are pseudonymised by default, with role based access and auditing. A risk alert is a signal requiring investigation, but it’s not proof that somebody has done something wrong.

There is also one fairly substantial catch.

The standard High Severity DLP Alert indicator does not currently support alerts generated exclusively by Endpoint DLP or Microsoft 365 Copilot DLP.

Use the dedicated AI indicators and AI Activity Explorer rather than assuming every Copilot DLP event will magically become an Insider Risk alert.

A functional rollout sequence

A sensible implementation sequence is:

1. Classify

• Build a meaningful label strategy.
• Define reliable Sensitive Information Types.
• Review SharePoint permissions and oversharing.
• Use the guidance on Agderinthe.cloud rather than inventing everything again.

2. Validate

• Confirm that labels and SITs match the right content.
• Review the results with data owners.

3. Observe

• Confirm Audit is enabled.
• Configure DSPM and establish baseline visibility.

4. Simulate

• Deploy Copilot and Endpoint DLP policies in simulation or audit modes as appropriate.
• Review matches, user impact and false positives.

5. Pilot

• Test with a representative user group.
• Include ordinary business scenarios, not only security team test cases involving fake credit cards and documents helpfully named SUPER SECRET.docx.

6. Enforce

• Start with audit, warnings or restricted web grounding where appropriate.
• Move to blocking when the policy is understood and trusted.

7. Improve

• Use DSPM, Activity Explorer, Audit and Insider Risk findings to refine the controls.
• Then repeat because it’s an operational cycle.
• It is not a Copilot deployment task that gets marked complete and forgotten.
• Before rollout, verify licensing against the current Microsoft Purview service description.

Licensing across Copilot DLP, label based processing restrictions, Endpoint DLP, DSPM and Insider Risk Management is not identical. It also changes often enough that copying a licensing table into a blog post is an excellent way of making the article obsolete before Microsoft has finished rearranging the Purview portal again.

Check the current Microsoft documentation for the capabilities you intend to deploy.

And now over to our Unicorns, the SharePoint admin

Every AI governance project eventually runs into the same problem where the organisation discovers what condition its data is actually in.

• Suddenly the AI project is discussing sensitivity labels.
• Then automatic classification.
• Then Sensitive Information Types.
• Then SharePoint permissions.
• Then the SharePoint site somebody created in 2018 that for some reason contains the entire strategic history of the company and is accessible to 14,000 people.

This is not the AI project going wrong. This is the AI governance project.

If that discovery leads you into sensitivity labels, automatic classification, Sensitive Information Types, SharePoint permissions or oversharing remediation, we cover those subjects in much greater depth on Agderinthe.cloud.

This article assumes those foundations exist and focuses on what comes next:

Controlling how Microsoft 365 Copilot can interact with data you have already classified.

AI governance is data governance under pressure

As I have stated over and over and over again; AI did not create a new data security problem.
It made an existing one faster, easier to exploit and considerably harder to ignore.

Sensitivity labels, Sensitive Information Types and DLP give us different ways of understanding the data and deciding what should be allowed to happen to it. Endpoint DLP extends those decisions to managed devices, while DSPM, Activity Explorer and Audit give us the visibility to understand where data is exposed and how it is actually being used. Insider Risk Management adds another perspective by helping us identify when individual activities start forming a pattern worth investigating.

None of this is really about Copilot alone. Microsoft 365 Copilot is simply one of the applications consuming the data and the policies we have built around it. Agents are doing the same, and external AI services introduce yet another route between our users and our information. I will dig into those external AI scenarios in the next article.

This is why I think organisations need to stop measuring AI governance by how many AI tools they have approved, blocked or added to yet another governance framework. The more useful question is whether they understand their information well enough to decide what can happen to it, regardless of which AI service happens to be asking for it.

That is the shift I want us to make: stop building governance around the AI tool and build it around the data the AI wants to use.

Our users are going to use AI. We can spend our time trying to govern every new AI feature that appears, or we can make sure the data is ready for whichever one appears next..