ChatGPT Security: Stop PII Leaks with Microsoft Purview

“Can we allow ChatGPT without allowing people to paste half the customer database into it?” is the sort of question that sounds flippant until you realise how easily it can happen.

Generative AI has created a very strange security problem. An employee may be entirely authorised to read a customer record and entirely authorised to open ChatGPT, yet the combination of those two permissions can still allow sensitive information to leave the organisation. Nothing has been hacked. No password has been stolen. The user has simply copied data from one perfectly legitimate window into another.

The obvious response is to block every AI website. This is certainly simple, in the same way that removing every wheel from a car is a simple way to prevent speeding. It also removes the useful part of the technology.

A better answer is to allow the service but control the information that can be sent to it. That is what I demonstrate in this video using Microsoft Purview Data Loss Prevention and Microsoft Edge for Business.

The problem is the data, not the website

There is an important difference between controlling access to an application and controlling what someone does with data inside that application.

Conditional Access can decide whether a user is allowed to sign in. Microsoft Intune can decide whether a device meets the organisation’s compliance requirements. Microsoft Defender for Cloud Apps can help classify cloud applications and identify whether they are managed or unmanaged. None of those controls, on their own, answers the more specific question:

Does this particular prompt contain information that the organisation does not want to send?

That is a content inspection problem, which is where Microsoft Purview Data Loss Prevention comes in.

A DLP policy can look for sensitive information types, sensitivity labels, trainable classifiers and other conditions. It then applies an action when content matches. The familiar examples are blocking a credit-card number in an email or preventing a labelled document from being copied to removable storage. Inline web traffic extends the same idea into supported cloud and AI applications.

The important point is that the policy is not merely matching the words “credit card”. Sensitive information types use evidence such as patterns, checksums, keywords and confidence levels. DLP is performing content classification, not a basic browser find operation.

What happens when the user submits a prompt?

The demonstration uses a managed Windows 11 device, Microsoft Edge for Business and a user included in an inline web-traffic DLP policy.

The flow is roughly this:

1. Purview publishes the DLP policy.
2. The policy is made available to Edge on the managed device.
3. The user enters a prompt on an unmanaged AI site such as ChatGPT.
4. Edge evaluates the text against the policy before allowing it to be sent.
5. A normal prompt is submitted.
6. A prompt containing protected information is blocked and the user sees a policy notification.
7. The event is reported back to Purview for investigation and reporting.

This is quite different from sending the entire browser session through a traditional reverse proxy. The protection demonstrated in the video is integrated with Edge for Business. Microsoft’s current Browser DLP documentation also explains that policies targeting unmanaged applications on managed devices can apply across Edge work, personal and InPrivate profiles.

That last point matters. The work profile remains the sensible place for organisational browsing, but the control should not disappear merely because someone opens a different Edge profile.

Managed and unmanaged applications

The word “unmanaged” can cause confusion here. It does not mean that nobody knows what the application is. ChatGPT is a well-known service and appears in Microsoft’s cloud application catalogue.

In this context, an unmanaged application is one that is not under the organisation’s full administrative control in the same way as its Microsoft 365 tenant or another sanctioned enterprise service.

Purview can use an adaptive application scope for unmanaged AI applications. Microsoft maintains a changing list of AI sites supported by Purview, so it is better to check the live list than build a policy around the assumption that today’s popular services will be the complete list forever.

The cloud application catalogue and the DLP policy are doing different jobs:

• The application catalogue identifies and classifies the destination.
• Purview identifies the sensitive content and applies the rule.
• Edge provides the in-browser enforcement point on the managed device.
• Intune helps deliver the supporting device and browser configuration.

It is a collection of Microsoft services working together, which is either elegant integration or another excuse to keep several admin portals open, depending on how generous you are feeling that morning.

Building the policy

In the Purview portal, the policy begins under Data Loss Prevention > Policies > Create policy. The location used in the video is Inline web traffic, followed by a custom policy.

Microsoft documents the current process in Help prevent sharing via Microsoft Edge for Business to unmanaged AI apps.

The main choices are:

• The cloud or AI applications to protect.
• The users or groups included in the rollout.
• The sensitive information types or other classifiers to detect.
• Whether text, files or both should be restricted.
• Whether the user can override the block.
• Which notifications and alerts should be generated.
• Whether the policy starts in simulation or enforcement mode.

For the demonstration I use a credit-card-number sensitive information type. It is a convenient test because recognised test card numbers are readily available and the policy result is easy to understand. In a production environment, the useful list is likely to be much broader: UK National Insurance numbers, passport details, bank information, credentials, internal project names, custom sensitive information types and sensitivity labels may all be relevant.

Do not begin by turning on every classifier for every employee. A policy that blocks normal work every few minutes will soon become a policy that users try to avoid. Start with a test group, use simulation, examine the matches and tune the rule before wider enforcement.

Why the supporting Intune policies appear

One of the less obvious parts of the setup is that enabling browser protection can create supporting Microsoft Edge and Intune configuration, together with included and excluded user groups.

These objects exist because detecting a sensitive prompt is only useful if the browser can reliably enforce the decision. The supporting configuration establishes the protection and helps reduce obvious bypass routes. Microsoft advises against casually editing the automatically created configuration. The Microsoft Edge configuration for Purview DLP explains what Purview creates and how it is used.

The group shown in an automatically created Intune policy is not necessarily a second copy of the scope configured inside your DLP rule. The policy scope in Purview remains the place to decide which users the DLP rule applies to; the generated objects provide the underlying browser protection.

After changing the policy, allow time for synchronisation. On the device, confirm that Windows is joined and managed, synchronise the work account, restart Edge and inspect:

edge://management
edge://policy

If the DLP rule is correct in the portal but nothing happens in the browser, the problem is often policy delivery rather than the sensitive information condition itself.

Testing the control

A useful test proves both sides of the rule.

First send an ordinary prompt:

Explain the difference between Azure Policy and Azure RBAC.

That should be allowed. The objective is not to make ChatGPT unusable.

Next, use demonstration data that matches the sensitive information type. Never use a real customer record simply to prove that your data-loss control works. A recognised payment-card test number is enough.

The expected outcome is:

Normal prompt
→ Allowed

Prompt containing protected information
→ Detected in Edge
→ Blocked before submission
→ User notification displayed
→ Event reported to Purview

Test with a user who is included in the policy and, just as importantly, with a user who is not. Then repeat the test in the Edge profiles your users might actually open. Security controls have an unfortunate habit of working perfectly in the exact scenario used by the administrator and nowhere else.

DLP and DSPM are related, but not the same thing

The video also looks at Data Security Posture Management for AI.

Microsoft Purview Data Security Posture Management for AI provides a central view of AI usage and data risk. It helps an organisation discover AI applications, understand where sensitive information may be involved and identify recommended controls.

DSPM provides the visibility and posture-management layer. The DLP policy performs the real-time allow or block decision in this scenario.

A simple way to remember the relationship is:

• DSPM helps you discover and understand the risk.
• DLP defines what should happen when protected content is detected.
• Edge enforces the browser decision.
• Activity Explorer and alerts provide evidence of what happened.

Be deliberate when enabling collection of AI prompts and responses. Collecting content can be useful during an investigation, but it also creates another body of potentially sensitive data that must be governed properly.

What about Chrome, Firefox and applications outside the browser?

The Edge integration is the cleanest part of this particular demonstration, but users do not restrict themselves to the browser you would prefer them to use.

Purview Endpoint DLP and supported browser extensions can provide controls for Chrome and Firefox. The activities and enforcement model are not identical to inline Edge protection, so they should be tested as separate scenarios rather than assumed to behave in exactly the same way.

For broader coverage across browsers, applications and unmanaged destinations, Microsoft also provides Purview Network Data Security through supported SASE, SSE and secure-browser integrations.

This produces three possible layers:

• In-browser protection through Edge for Business.
• Endpoint controls for activities such as paste and upload.
• Network data security for broader traffic paths.

No single layer automatically covers every route. A proper design starts with the ways data can actually leave the organisation, then selects controls for those routes.

Allow AI, but put a seatbelt on it

The attraction of this approach is that it avoids the false choice between allowing AI without control and blocking AI completely.

Employees can still ask ChatGPT to explain Azure Policy, draft a generic document or help with a piece of code. What they cannot do is send information that matches the organisation’s protection policy without the browser intervening.

That does not make generative AI risk disappear. Screenshots, mobile devices, unmanaged endpoints, deliberate obfuscation and applications outside the protected path all need consideration. DLP is a control, not a force field.

It does, however, place a useful decision at exactly the point where a simple mistake can become a data disclosure. The user receives immediate feedback, the sensitive prompt is stopped before submission and the security team receives an event it can investigate.

The correct question is therefore not “Should we block ChatGPT?” It is “What information are we prepared to let people send to it, and how will we enforce that decision?”

Microsoft Purview gives us a practical answer.

Watch the full demonstration above, or open it directly on Mike in the Cloud.