Your Data Has a Back Door. GSA and Purview Are the Deadbolt

You know that feeling when you leave the house and suddenly wonder, “Did I lock the back door?” That little sting of uncertainty. Now imagine that same feeling, except instead of your house it is your organization’s sensitive data, and instead of the back door it is every browser, AI chatbot, and random cloud storage service your users touch on any given Tuesday.

Sure, Endpoint DLP and Edge for Business can catch sensitive uploads through the browser, and if you have those configured, you are already in a good spot. What about desktop applications, APIs, add-ins, and all the other non-browser pathways that move data off your network? That is the gap, and that is exactly where GSA file policies come in.

By combining Microsoft Purview Data Loss Prevention with Microsoft Entra Global Secure Access (GSA), you can now inspect and control sensitive file traffic at the network layer. Think of it as finally installing that deadbolt on the back door.

In this post, I will walk you through everything you need to know, from the architecture to each step of the configuration. So grab your coffee (or something stronger), and let’s lock that door.

A Quick Refresher: What is Global Secure Access?

If you have been following along with my previous blogs on GSA, you already know the basics. The short version is that Microsoft Global Secure Access is Microsoft’s Security Service Edge solution, combining Entra Internet Access (Secure Web Gateway) and Entra Private Access (Zero Trust Network Access) under one umbrella. For this blog, we are focused specifically on Entra Internet Access and its File Policies capability, which brings Purview content inspection directly into the network traffic path.

Under the Hood: How GSA File Policies Actually Work

Before we start clicking through the portal, it helps to understand what is happening behind the scenes. Trust me on this one, knowing the architecture makes troubleshooting a whole lot easier down the road.

The network content filtering solution with file policies brings together two major Microsoft services:

Microsoft Purview’s data classificationservice which understands sensitive information types, sensitivity labels, and content scanning.
Global Secure Access’s identity-centric network security policies which evaluate user identity and real-time risk as traffic flows through the service edge.

Together, they create an identity-centric, policy-driven DLP layer at the network. Here is how the traffic flows at a high level:

A user on a managed device (with the GSA client installed) attempts to upload a file to an internet destination.
Traffic is tunneled through the Global Secure Access service edge via the Internet Access traffic forwarding profile.
If TLS inspection is enabled, HTTPS traffic is decrypted at the edge.
The file policy evaluates the file against configured rules, looking at MIME type, Purview sensitivity label, or sensitive content scan.
The policy takes action: Allow, Block, or Scan with Purview.
Alerts and incidents are surfaced in Microsoft Purview and Microsoft Defender.

This is a powerful complement to what Endpoint DLP and Edge for Business already provide. While those tools handle browser-level enforcement exceptionally well, GSA file policies extend that protection to traffic from desktop applications, APIs, add-ins, and anything else that touches the network. It is defense in depth at its finest. The back door, the side door, and that window someone left cracked open are all finally covered.

Two Flavors of File Policies

GSA file policies come in two modes. Basic file policy blocks files based on MIME type alone, no Purview license required. Scan with Purview goes deeper, evaluating sensitivity labels, sensitive information types That second option is where the real power is, but it does require a Purview license and a pay-as-you-go subscription (more on that later).

Now, I will be the first to admit that Purview is a massive product. When I really need to go deep on the data security side, I lean on smart friends like Matt, who is a Purview MVP, a fellow Marine vet, and runs an excellent blog over at severian.ghost.io. If you are getting serious about sensitivity labels and DLP policy design, his content is a goldmine. Having a solid understanding of your labels and SITs will make this whole setup significantly more effective.

Before You Start: Prerequisites

Before we get our hands dirty with configuration, let’s make sure the foundation is in place. I have been down this road enough times to know that skipping prerequisites is a recipe for frustration.

Licensing

Microsoft Entra Internet Access (included in the Entra Suite) – required for all GSA Internet Access features.
Microsoft Purview license – required only if using the Scan with Purview action. Basic file policy does not require it.

Worth noting: The upcoming Microsoft 365 E7 license bundles both Entra Suite and Purview into a single SKU alongside M365 E5, Microsoft 365 Copilot, and Agent 365. So if your organization is looking at E7, you will already have the licensing covered for everything we are configuring in this blog. For those still on E5, the Entra Suite is available as a standalone. Either way, just make sure the right licenses are assigned before you start building policies.

Device Requirements

The Global Secure Access client must be installed on end-user devices.
Devices must be Microsoft Entra joined or Microsoft Entra Hybrid joined.
GSA Client version 1.7.376.0 or later.

Let’s Get to Work: The Configuration Walkthrough

Alright, here is where the fun begins. The configuration breaks down into six major steps. I will walk through each one so there are no surprises.

Step 1: Enable Internet Access and Configure TLS Inspection

First things first. Sign into the Microsoft Entra admin center and navigate to Global Secure Access > Connect > Traffic forwarding. Enable the Internet access profile. More on this in my blog located here.

Next up is TLS Inspection. I will not spend a ton of time on this step. Microsoft provides a script located here that really helps. DO NOT skip TLS Inspection. Yes, you…. I’m talking to you.

Important: The root certificate must be distributed to all managed endpoints via Intune or Group Policy, so browsers trust the dynamically generated leaf certificates created by GSA during inspection.

Step 2: Install and Verify the GSA Client

Again, this is pretty straightforward and covered in a previous blog post.

Step 3: Create the File Policy

Now we are getting to the good stuff. Sign into the Entra admin center as a Global Secure Access Administrator and navigate to Global Secure Access > Secure > File policies. Select + Create Policy.

On the Basics tab, give your policy a descriptive name (something like FP-Block-Sensitive-GenAI-Uploads) and add a description that reflects the business justification. Then select Next.

On the Rules tab, select + Add rule and configure it as follows:

Field	Value
Name	e.g., Block Confidential uploads to AI sites
Priority	e.g., 100 (lower numbers = higher priority)
Status	Enabled
Action	Scan with Purview (or Block for Basic policy)
Activities	Upload
File types	Select desired MIME types (PDF, DOCX, XLSX, etc.)
Destination	Add specific FQDNs or web categories (e.g., AI sites)

A quick note on those action options. Allow permits the file transfer, which is useful for explicit exceptions. Block denies the transfer immediately based on MIME type alone, which is your Basic policy option. Scan with Purview passes the file to Purview for content inspection based on sensitivity labels or sensitive information types. That last one is where the real magic happens.

When selecting Scan with Purview, you can configure the Purview-side conditions in your DLP policy to match on sensitivity labels (e.g., Confidential, Highly Confidential), and sensitive information types (e.g., Credit Card Number, U.S. Social Security Number).

After configuring your rules, select Next, review your settings on the Review tab, and select Create.

Step 4: Configure the DLP Policy in the Purview Console

Now we need to flip over to the other side of this equation. Remember, the GSA file policy we just created with the “Scan with Purview” action is essentially saying, “Hey Purview, take a look at this file and tell me what to do.”, but if there is no DLP policy waiting on the Purview side, nobody is home to answer the door. This is where a lot of people get tripped up, so let me walk you through it.

Enable Pay-As-You-Go Billing

Before you can use network data security features in Purview, your Global Admin needs to activate Purview pay-as-you-go billing. The good news is that no charges apply for the GSA integration during public preview, so you are not going to get a surprise invoice. However, you still need to configure it before any of the network DLP features light up. More information here Learn about Microsoft Purview billing models | Microsoft Learn

Create the Inline Web Traffic DLP Policy

With the integration in place, it is time to create the actual DLP policy that will evaluate files GSA sends over. Here is the walkthrough:

In the Purview portal, navigate to Data loss prevention > Policies > + Create policy.
Select Inline web traffic as the scenario. This is the specific option that connects to GSA’s file policy engine.

Then select Custom from the Categories list and Custom policy from Regulations.

Give your policy a name and description. Something like “Block Sensitive File Uploads via GSA” works. Keep it clear enough that future you will not have to guess what it does.
Select + Add cloud apps. Switch to the Adaptive app scopes tab and choose All unmanaged AI apps. You can also add destinations here if you want to target specific cloud storage services or other SaaS apps.

On the Choose Where to Enforce the Policy settings page, be sure to select Network to allow GSA to do its thing.

Configure the DLP Rule

This is where you define what Purview should actually look for. Select + Create rule and give it a unique name.

Under Conditions, select + Add condition > Content contains. From here you can add Sensitive info types (like Credit Card Number, U.S. Social Security Number, ABA Routing Number, or any custom SITs your organization uses) as well as Sensitivity labels (like Confidential or Highly Confidential). Set the Group operator to “Any of these” so the rule triggers if any of the conditions match.

Under Actions, select + Add an action > Restrict browser and network activities. You will see File Uploaded to or shared with cloud or AI apps, select Block.

Configure your alert settings. I recommend enabling alerts for admin notification so your security team can see when policies trigger. You can set thresholds to avoid alert fatigue.
Save the rule, make sure its status is On, and select Next.

On the final page, I strongly recommend setting the policy to Simulation mode first. Run it for a few days and review the results in Activity Explorer before flipping it to enforcement.

You can filter Activity Explorer by enforcement plane set to “network” to see only the events generated by your network DLP policies. This makes it much easier to isolate GSA-related hits from your other DLP activity.

Step 5: Link the File Policy to a Security Profile

Security profiles are the glue between filtering policies and Conditional Access policies. Think of them as the middleman that ties everything together. A single security profile can contain multiple filtering policies (web content, file, TLS inspection, threat intelligence), and multiple Conditional Access policies can reference the same security profile.

Navigate to Global Secure Access > Secure > Security profiles.
Select an existing security profile or create a new one.
Switch to the Link policies view.
Select + Link a policy > Existing File policy and choose the file policy you created.

Be sure to leave spacing of roughly 100 between priority numbers across policies in a profile (e.g., 100, 200, 300). This gives you room to insert new policies later without having to renumber everything. Future you will appreciate it.

Step 6: Configure the Conditional Access Policy

The Conditional Access policy is what delivers the security profile to your users. Without this step, the file policy has no user scope. It is essentially the bouncer at the door, making sure everything gets enforced for the right people.

Navigate to Conditional Access and create a new policy with a meaningful name (e.g., CA-GSA-FilePolicy-SensitiveData).
Under Assignments, select your target users and groups. For initial rollout, scope to a pilot group.
Under Target resources, select All internet resources with Global Secure Access.
Under Session, select Use Global Secure Access Security Profile and choose the security profile linked to your file policy.

Set the policy to Report-only first to validate behavior, then switch to On once you are confident everything looks right.

Put It to the Test

After the CA policy propagates it is time to see if our deadbolt actually works. Open a test file containing sensitive data (a great free resource is dlptest.com/sample-data.pdf) and attempt to upload it to a destination covered by your policy. If everything is configured correctly, the upload will be blocked.

To verify, navigate to Global Secure Access > Monitor > Traffic logs and check the Transactions tab. Filter by Action or policyName to confirm the correct policy triggered the block. For Purview scan alerts, check Data loss prevention > Alerts in the Purview compliance portal, and review incidents in Microsoft Defender XDR.

The Fine Print: Known Limitations

Since this feature is still in public preview, here are the key limitations to be aware of (taken directly from the Microsoft Docs):

Network content filtering doesn’t support text. It only supports files.
Multipart encoding isn’t supported, so file policy doesn’t work for such applications. For example, Google Drive uses multipart encoding for file upload.
Compressed content is detected in ZIP format. The content isn’t decompressed.
True file type detection might not be 100% accurate.
Destination applications that use WebSocket, such as Copilot, aren’t supported.
Top level and second level domains don’t support wildcards (like *, *.com, *contoso.com) while configuring FQDNs.

Locking Up: Bringing It All Together

The combination of Global Secure Access and Microsoft Purview file policies gives you a network-layer enforcement point that is identity-aware, risk-adaptive, content-intelligent, and centrally managed. Even if some AI vendors have their own built-in guardrails, defense in depth still wins. Your users are not going to stick to one tool, so your protection should not be either.