Can Microsoft Purview Block Sensitive Data Sent to ChatGPT and Claude? A Look at Entra Global Secure Access

Most organizations have spent considerable time securing the information employees access through Microsoft 365. They've implemented sensitivity labels, configured DLP policies, restricted external sharing, and invested in protecting data stored in SharePoint, OneDrive, and Exchange. These controls have become a familiar part of enterprise security, but they don't necessarily provide the same protection when someone takes information out of those environments and shares it with an external AI service.

An employee might copy part of a confidential document into ChatGPT or upload a customer spreadsheet to Claude without considering what happens to that information once it leaves the organization's managed environment. In most cases, they're simply using tools that help them do their jobs, often without realizing that the organization's existing data protection policies may not apply to those interactions.

Microsoft Purview can block supported sensitive data uploads and text submissions to ChatGPT, Claude, and other unmanaged AI applications when integrated with Entra Global Secure Access. However, enforcement depends on traffic forwarding, TLS inspection, user identity association, and correctly configured DLP policies. Microsoft's implementation also has a documented 3 MB inspection limit and can fail open when inspection cannot be completed, so it shouldn't be treated as comprehensive protection against AI-related data loss.

In September 2026, Microsoft announced general availability of its Purview Network Data Security integration with Entra Global Secure Access. The integration allows organizations to inspect supported network traffic, identify sensitive information, and apply DLP policies before that information is transferred to unmanaged cloud and AI services.

It's an interesting development because it moves some data protection decisions beyond the traditional boundaries of Microsoft 365 and managed browsers. However, getting it working requires more than enabling another DLP policy, and there are some important limitations administrators need to understand before relying on it.

How Microsoft Purview DLP works with Entra Global Secure Access

Microsoft Purview already provides several methods of protecting information shared through browsers, endpoints, and Microsoft 365 applications. Network Data Security extends those capabilities by integrating with a Secure Access Service Edge (SASE) solution. In this case, Microsoft Entra Internet Access, part of Global Secure Access, handles the network traffic, while Purview evaluates the information being transferred against configured DLP policies.

Consider an employee using a managed Windows device to upload a PDF containing customer information to ChatGPT. If the device is correctly configured, Global Secure Access can route the relevant HTTPS traffic through Microsoft's security service edge. TLS inspection allows the service to inspect the content being transferred, while a matching content policy submits the information to Microsoft Purview for classification. Purview evaluates the content against the organization's DLP policy and returns a decision that Global Secure Access can enforce, potentially blocking the upload before the file reaches its destination.

The same approach supports text submitted through AI prompts, file uploads, and other supported HTTP and HTTPS interactions. Coverage isn't necessarily limited to browser traffic either, since Microsoft documents support for applications, APIs, and add-ins, provided the traffic meets the inspection and identity requirements. Having an application installed on a managed endpoint doesn't automatically mean every interaction with it can be inspected.

Microsoft Purview Network Data Security capabilities at a glance

These capabilities reflect the documented Global Secure Access implementation as of October 2026. Actual coverage depends on the destination, content format, traffic type, and configuration. Microsoft's network content filtering documentation provides the current implementation details and limitations.

Licensing and prerequisites for Purview Network Data Security

There are several dependencies to consider before attempting to configure the integration, starting with licensing. According to Microsoft's current documentation, Network Data Security with Global Secure Access requires either Microsoft 365 E7 licensing or an eligible Purview E5 license combined with Entra Internet Access licensing.

Organizations already using Microsoft 365 E5 shouldn't assume they have the complete solution without checking their specific entitlements, particularly where Purview and Entra components have been licensed separately. Microsoft also documents a different billing model for supported non-Microsoft SASE and secure browser integrations, so the licensing requirements shouldn't be treated as interchangeable.

From a technical perspective, you'll need Global Secure Access with the Internet Access forwarding profile configured, a supported managed endpoint running the Global Secure Access client, and TLS inspection with the appropriate certificate trust chain. You'll also need sufficient administrative permissions to configure Global Secure Access, Conditional Access, and Microsoft Purview DLP.

For this walkthrough, I'd use a Microsoft Entra joined Windows 11 device, a dedicated test group, and two AI applications such as ChatGPT and Claude. The Global Secure Access client supports Microsoft Entra joined and hybrid joined Windows devices, but using a fully joined device keeps the initial deployment focused on inspecting and enforcing network traffic rather than troubleshooting hybrid identity configurations.

I'd also recommend using synthetic data throughout testing. The objective is to establish whether the controls can recognize and prevent sensitive information from leaving the device, without creating an actual data disclosure during validation.

Step 1: Configure Global Secure Access traffic forwarding and TLS inspection

Start in the Microsoft Entra admin center at https://entra.microsoft.com and navigate to Global Secure Access. Enable the Internet Access traffic forwarding profile for your pilot users, install the Global Secure Access client on the test device, and verify that it is connected and acquiring the appropriate traffic.

The client includes an Advanced Diagnostics tool that can confirm whether Internet Access forwarding rules are present. I'd validate this before creating any content policies, because a correctly configured DLP rule isn't going to be particularly useful if the relevant traffic never reaches the inspection service.

Next, configure TLS inspection. Most traffic exchanged with services such as ChatGPT and Claude uses HTTPS, meaning Global Secure Access may be able to identify the destination without necessarily seeing the content of the request. TLS inspection allows the service to examine eligible encrypted traffic so sensitive information types and other classification conditions can be evaluated.

Microsoft provides a TLS inspection configuration tutorial covering certificate creation, inspection policies, certificate trust, security profiles, and Conditional Access assignments. For a pilot, I'd create a dedicated TLS inspection policy rather than immediately enabling broad inspection across the organization.

This configuration has operational implications, particularly for applications using certificate pinning or services that don't tolerate TLS interception. Microsoft maintains system-generated bypass rules for certain destinations, and additional exceptions may be required for applications experiencing compatibility issues. Those exceptions need careful consideration because traffic excluded from TLS inspection won't receive equivalent content-level protection.

Step 2: Create a Global Secure Access content policy

Once traffic forwarding and TLS inspection have been validated, navigate to Global Secure Access > Secure > Content policies and create a new content policy for the test environment.

For the rule action, select Scan with Purview. Global Secure Access also supports basic content filtering that can block certain file or text types without involving Purview, but that isn't the same as inspecting a document for confidential information or identifying sensitive data entered into an AI prompt.

Scan with Purview sends supported content for evaluation against the classification conditions and enforcement actions defined in Microsoft Purview. Configure the activities and content types requiring inspection, including supported file uploads and text submissions, then restrict the initial destinations to a small number of applications.

For a narrowly scoped ChatGPT file upload test, Microsoft documents several relevant endpoints:

• https://chatgpt.com/backend-api/files
• https://chatgpt.com/backend-api/files/process_upload_stream
• *.oaiusercontent.com

These are Microsoft's documented examples as of October 2026 and shouldn't be considered an exhaustive or permanent list of every endpoint ChatGPT uses. For Claude or other AI applications, identify the applicable URLs and FQDNs from current traffic and validate that the policy captures the intended requests. Simply adding an application's homepage domain doesn't guarantee that its API interactions and file uploads are covered.

Web categories can also be used as policy destinations, provided the corresponding Global Secure Access web filtering configuration is present.

Once the content policy has been created, associate it with an appropriate Global Secure Access security profile. For a targeted deployment, create or configure a Conditional Access policy for the pilot group, select All internet resources with Global Secure Access as the target resource, and apply the security profile using the Use Global Secure Access Security Profile session control.

At this stage, the network configuration is in place, but Purview still needs a corresponding DLP policy to evaluate the information and determine which actions should be allowed or blocked.

Step 3: Configure Purview DLP to block sensitive AI prompts and uploads

Navigate to https://purview.microsoft.com and open Data Loss Prevention > Policies > Create policy. Select Inline web traffic and create a custom policy, choosing either specific unmanaged AI applications or the adaptive scope for All unmanaged AI apps.

I'd begin with selected applications and a limited user group rather than apply the policy broadly. This makes it easier to identify which interactions are being evaluated and reduces the chance of disrupting legitimate business processes while the configuration is being validated.

On the enforcement locations page, enable Network and non-Microsoft secure browsers, then create an advanced DLP rule using the Content contains condition. For the initial test, select a sensitive information type that can be reliably reproduced with synthetic data, such as a test credit card number. Sensitivity labels can also be used as conditions, provided the content format and encryption characteristics allow the label to be evaluated.

Under Actions, select Restrict browser and network activities and configure the activities that should be protected:

• Text sent to or shared with cloud or AI apps.
• Files uploaded to or shared with cloud or AI apps.

Both can be configured with the Block action.

The Purview activities should correspond to the content types selected in Global Secure Access. If one policy is configured to inspect file uploads while the other only evaluates text submissions, the resulting behavior may not be what the administrator expects.

I'd also configure incident reporting and alerts so the security team can investigate policy violations without having to search manually through multiple monitoring interfaces.

For the initial deployment, I'd use simulation mode to establish what the policy detects before enabling enforcement. Microsoft supports simulation as part of the DLP deployment process, although actual blocking behavior still needs to be verified with enforcement enabled in the isolated pilot.

One final configuration detail worth reviewing is how policy conditions are combined. Selecting sensitive information types and sensitivity labels within an appropriate Any of these condition allows either to trigger the rule, whereas unnecessarily restrictive combinations can result in the policy matching much less information than intended.

Microsoft provides a documented unmanaged AI DLP configuration scenario, which is useful for comparing the finished policy against the intended conditions, activities, and enforcement settings.

Step 4: How to test ChatGPT and Claude DLP enforcement

With the network and DLP policies applied, start by creating a supported PDF containing synthetic information designed to trigger the configured DLP rule. Using the managed test device, open ChatGPT and attempt to upload the document.

If the content matches the rule and enforcement is operating correctly, Global Secure Access should prevent the transfer. Microsoft's documented example describes ChatGPT displaying an error when an upload is blocked, although the exact user experience may vary with the application and request type.

Next, upload an ordinary PDF containing no matching sensitive information. Assuming no other security policy prevents the transfer, that file should be allowed.

I'd expand the testing beyond these two examples because a successfully blocked upload only demonstrates that a particular inspection path is working. It doesn't establish that every method of interacting with the same AI application receives equivalent protection.

Recommended validation matrix

The matrix describes tests to perform, not results from a completed tenant deployment.

The final scenarios are particularly useful for understanding the difference between a DLP policy being configured and the actual level of protection being provided. I'd also repeat selected tests using different browsers or supported desktop applications because the way content is transferred can affect whether inspection occurs.

After completing each test, review the results in Global Secure Access > Monitor > Traffic logs and correlate them with the corresponding Purview DLP alerts and Activity Explorer events. I'd examine the destination, user, request, enforcement action, and available inspection status rather than simply checking whether an alert was generated.

Microsoft documents a PurviewStatus field in the Global Secure Access traffic logs that can help identify requests where Purview inspection was skipped. That field is particularly useful when evaluating potentially uninspected transfers and should be included in the testing process.

An absence of DLP alerts shouldn't automatically be interpreted as proof that no sensitive information was transferred. I'd verify that the relevant traffic was acquired, the policy was applied, and the inspection process completed before making any conclusions about coverage.

Microsoft Purview Network DLP limitations and fail-open behavior

There are several documented limitations that change how I would position the solution, particularly where an organization expects DLP to prevent sensitive information from reaching external AI services under all circumstances.

What happens when Purview cannot inspect the content?

Microsoft's Global Secure Access documentation explicitly states that Scan with Purview can fail open when inspection cannot complete, including situations involving oversized payloads and internal inspection errors.

The Global Secure Access implementation currently documents a 3 MB maximum for content submitted through Scan with Purview, covering both text and file content. Microsoft's broader Network Data Security documentation includes some different limits, so I'd use the implementation-specific value when planning and validating this integration.

Requests that skip inspection because of these conditions may be allowed to continue. Microsoft provides the PurviewStatus field in Global Secure Access traffic logs to help identify skipped inspections, making it an important field to review during both deployment validation and ongoing monitoring.

This is a significant consideration if the organization's expectation is that confidential documents cannot be uploaded to an external AI service. Where the consequences of an uninspected transfer are unacceptable, a separate network-level restriction may be appropriate rather than depending entirely on a content inspection decision.

An important distinction is that fail-open behavior during unsuccessful Purview inspection isn't universal to every Global Secure Access failure condition. Microsoft separately documents fail-closed behavior when network content filtering API rate limits are exceeded. Those scenarios shouldn't be confused when investigating unexpected allow or block results.

Can all AI application traffic be inspected?

Not all application traffic is equally visible. Microsoft documents limitations around files encoded within JSON, transfers split into multiple encrypted requests, and certain WebSocket interactions. File-type filtering in Global Secure Access content policies doesn't apply to WebSocket traffic in the same way as ordinary requests, although text content type evaluation within WebSockets is supported.

Some unmanaged AI applications also use encoded content or dynamically generated endpoints, which can complicate policy enforcement. I'd therefore validate each application and interaction method rather than assume that a broad application category or URL pattern provides complete coverage.

Does Purview require a Microsoft Entra identity?

For Scan with Purview, Microsoft requires the inspected traffic to be associated with a Microsoft Entra user identity. Requests that cannot be mapped to an Entra user aren't forwarded to Purview for inspection.

This becomes particularly relevant when considering automation, background processes, and AI agents. A managed device may generate traffic from several applications and processes, but that doesn't mean every outbound connection can be associated with the user identity required for Purview inspection.

Can Purview inspect encrypted and image-based PDFs?

Microsoft's documentation states that OCR isn't currently supported for traffic submitted through this Global Secure Access integration. An image-only PDF containing sensitive information may therefore evade content-based classification if no readable text or applicable metadata is available.

Similarly, an encrypted document may expose a sensitivity label or other metadata that can be evaluated, while the document's actual contents remain unavailable for inspection. Organizations relying exclusively on sensitive information type detection need to account for these scenarios, particularly where image-based documents and encrypted files are routinely exchanged.

How do TLS bypasses and alternative network paths affect protection?

TLS inspection exceptions, unsupported traffic types, unmanaged endpoints, and devices outside the configured forwarding scope can all affect coverage.

QUIC traffic is another consideration because Global Secure Access Internet Access doesn't currently support it in the same way as TCP-based HTTPS. Microsoft documents blocking outbound UDP port 443 as one method of encouraging compatible browsers to fall back to TCP, although I'd test the operational impact before introducing that restriction into production.

Browser and client configuration also deserve attention, particularly secure DNS behavior and any settings affecting how traffic is acquired. The objective is to verify that the requests you're expecting to inspect are actually reaching the correct enforcement point.

Employee privacy and AI interaction monitoring

There's an additional consideration when organizations start inspecting how employees interact with external AI services.

Purview Network Data Security supports collection policies that provide visibility into AI usage and sensitive information matches. When content capture is explicitly configured, the solution can capture conversations between a user and an AI application, potentially giving investigators considerably more information than a normal DLP alert indicating that a confidential document was blocked.

Before enabling that functionality, I'd establish who can access the collected information, why it needs to be retained, how long it will be available, and whether the collection is consistent with the organization's privacy and compliance requirements.

For most initial deployments, I would focus on sensitive information detection, policy enforcement, and incident metadata rather than collecting complete employee conversations by default. The additional visibility may be valuable for a legitimate investigation, but it shouldn't automatically become the standard operating configuration simply because the capability exists.

How I'd approach a production deployment

I wouldn't start by blocking every generative AI application. There are legitimate business uses for ChatGPT, Claude, and other AI services, and an overly restrictive policy may encourage employees to find alternative ways to complete their work.

Instead, I'd begin with a controlled deployment designed to establish how employees are using external AI applications, which destinations are involved, and what types of sensitive information are being shared. That information would help determine which applications should be permitted, which data classifications require enforcement, and where additional restrictions might be necessary.

I'd then introduce enforcement for specific high-risk information types and sensitivity labels, starting with departments handling regulated, confidential, or commercially sensitive information. During this phase, I'd also validate the documented limitations rather than concentrating exclusively on whether the expected blocking tests succeed.

In particular, I would want to understand what happens when content cannot be inspected, whether the same application behaves differently across browsers and desktop clients, and whether protection remains effective when files are encrypted, encoded, or transferred through unsupported methods.

For environments already using Microsoft Defender for Endpoint and Purview Endpoint DLP, these network-based controls should complement those investments rather than automatically replace them. Endpoint controls, browser protections, and network inspection operate at different enforcement points, each with its own prerequisites and limitations.

Combining them provides more opportunities to prevent inappropriate data movement, but the controls still need consistent policy design and testing. An organization can have several DLP technologies enabled and still have significant gaps if nobody has validated how they work together.

My recommendation

Microsoft's integration of Purview with Entra Global Secure Access is a useful addition to the options available for protecting sensitive information shared with third-party AI services. Being able to inspect supported network traffic and make a DLP decision before a prompt or document reaches an external application addresses a problem that traditional Microsoft 365 controls don't always cover.

However, I wouldn't describe it as a complete solution to AI-related data loss. The documented inspection limits, fail-open behavior, dependency on TLS inspection, and requirement for user identity association all need to be factored into the design, particularly where the organization has regulatory obligations or contractual restrictions governing where information can be shared.

For organizations already invested in Microsoft Purview and Entra, I'd recommend evaluating the integration through a controlled pilot. Start with known sensitive information types, establish a small number of supported AI destinations, and test both allowed and blocked interactions before expanding the deployment.

I'd be particularly interested in the requests that don't generate the expected DLP result, because they can tell you more about the actual level of protection than the tests that behave exactly as intended. Understanding those exceptions allows the organization to decide whether additional endpoint, browser, or network restrictions are necessary.

Ultimately, enabling a policy isn't the same as demonstrating that sensitive information is protected. The measure of an effective implementation is understanding which interactions are covered, which aren't, and what happens when the inspection process fails.

That's the level of assurance I'd want before telling an organization that it has control over the information employees share with external AI services.