Network vs. Cloud vs. Endpoint DLP: What Each One Can See

All three have the same goal: stop sensitive data from leaving. What differs is where each one looks, and that follows how the way data leaves has changed.

Network DLP came first, when most data left through a handful of gateways: the mail server, the web proxy, the firewall. Cloud DLP followed when data started moving inside SaaS applications without ever crossing the corporate network. Endpoint DLP has become necessary as work moved onto the laptop itself, into desktop applications, local AI tools, and agents, often on networks the company does not control.

Each shift left the earlier tools seeing less. Network DLP can only inspect traffic it can decrypt, and applications that refuse inspection end up on the proxy’s bypass list, where their traffic goes uninspected. Cloud DLP only sees the applications it integrates with, and nothing after a file is downloaded.

At Bold, we build on the device side of this, so we see what network and cloud controls miss. The applications that move the most sensitive data are often the same ones on the bypass list, and a growing number of them are desktop AI tools.

In this article, we’ll cover network, cloud, and endpoint DLP, where each one can and cannot inspect, and how to tell which gap you have.

Key Takeaways

• Network and cloud DLP have largely merged: Both now usually run from the same cloud-delivered platform, and both inspect data somewhere other than the device. Endpoint DLP is the one that works differently.
• Some applications refuse network inspection: Applications that pin their certificates reject the proxy's substitute certificate, and the standard fix is a bypass rule that permanently excludes that traffic.
• Cloud DLP only sees what the platform shows it: It governs data inside integrated SaaS applications and has no view of a file once someone downloads it.
• Some activity never reaches the network or the cloud: USB transfers, printing, pasting into a local application, and moving files on the device are visible only from the device.
• Network and cloud tools see a destination, not the context behind it: Neither can see which local application sent the data, which account is signed in, or where the file came from on the device.
• Network and cloud inspection need a connection: When a laptop is offline, neither can inspect or enforce anything on it.
• Most organizations need more than one: Email gateways and server-to-server traffic belong to network DLP, and sharing inside SaaS belongs to cloud DLP. Endpoint DLP does not replace either.

Why This Distinction Matters Now

The three conditions network inspection depends on are under pressure at the same time. More applications pin their certificates. Desktop AI applications and local agents create traffic that either never crosses a gateway or crosses it encrypted in a way the gateway cannot read. And laptops spend a large share of working hours off the corporate network, where boundary controls do not apply.

The data moving through those gaps is also the hardest to classify. Source code, financial models, and strategy documents get pasted directly into AI tools, and pattern-matching classification was never able to recognize that material reliably.

What Is Network DLP?

Network DLP is a category of data loss prevention that inspects traffic in transit and enforces policy at a point between the user and the destination.

It is the original form of DLP. When it was designed, the approach was straightforward: route traffic through a known set of gateways, inspect the contents, and block or alert on a match. Email went through a mail gateway. Web traffic went through a proxy. File transfers crossed a firewall. Inspecting at those points covered the main ways data left.

The question network DLP exists to answer is: is sensitive data crossing this boundary, and should it be allowed through?

It is typically owned by network security or a security engineering team, often shared with the data security team that writes the policies.

Core components of network DLP:

• Enforcement points: Inspection happens at web proxies, mail gateways, and firewalls, or at a cloud-delivered service that does the same job without on-premises hardware.
• TLS inspection: The gateway decrypts traffic so its contents can be examined, then re-encrypts it. This only works if the device trusts a certificate the gateway presents in place of the real one.
• Content inspection: The system classifies the decrypted contents, usually through regex, keyword matching, and matching against known documents.
• Policy enforcement: Based on what it found and where the data was going, the tool blocks, quarantines, encrypts, or alerts.
• Logging and reporting: Everything that crossed the boundary gets recorded, which is still one of network DLP's strengths for compliance.

Network DLP covers channels that are not a device at all. Email sent from a server, server-to-server transfers, and traffic from systems where you cannot install software all fall under it.

What Is Cloud DLP?

Cloud DLP is a category of data loss prevention that governs sensitive data inside cloud platforms and SaaS applications, usually through API integrations rather than by sitting in the traffic path.

It exists because a lot of data movement stopped crossing the corporate network. A file shared from one person's Drive to an external address, or synced between two cloud services, never passes a corporate gateway.

The question cloud DLP exists to answer is: is sensitive data inside our cloud applications being shared, stored, or moved in ways policy does not allow?

It is typically owned by cloud security or data security, often alongside the team that administers SaaS applications.

Core components of cloud DLP:

• Platform integration: The tool connects to Microsoft 365, Google Workspace, Salesforce, and similar applications through their APIs to see content and activity inside them.
• Content inspection: It scans the files, messages, and records the platform holds.
• Sharing and permission controls: It finds and fixes external shares, public links, and access that is broader than it should be.
• Policy enforcement: It acts through the platform's own controls, quarantining files, revoking shares, applying labels, and blocking sends.

Cloud DLP only sees what the platform can show it. Content stored in a SaaS application is in scope. A copy of that content downloaded to a laptop is not, because the platform has no record of what happens to it after that.

What Is Endpoint DLP?

Endpoint DLP is a category of data loss prevention that classifies sensitive data on the device, monitors how it is accessed and moved, and enforces policy locally.

It became necessary as work moved onto laptops. The corporate network stopped being where most activity happened, first with cloud adoption and then with remote work. Sensitive data now lives on devices that connect from home networks, public networks, or no network at all.

The question endpoint DLP exists to answer is: is sensitive data on this device at risk of leaving, through any path?

It is typically owned by the data security team or an insider risk program.

Core components of endpoint DLP:

• Local classification: The tool identifies sensitive data on the device, either by matching known patterns or, in newer tools, by reading content for meaning.
• Coverage of every path off the device: Policy applies to uploads, email clients, USB and removable media, printing, clipboard activity, network shares, Bluetooth and AirDrop, local file operations, and prompts and file uploads into AI tools.
• Application context: The tool can see which application started an action, what launched it, and whether a person or an automated process was behind it.
• Local enforcement: Decisions happen at the moment of the action, ranging from logging to warnings, coaching toward an approved alternative, redirects, and hard blocks.
• Offline operation: Whether the tool keeps working without a connection depends on whether classification runs on the device or calls out to a cloud service.

The nuance on the endpoint

Endpoint DLP products all install software on the device, but they differ in how much of the work happens there. At one end, the software on the device collects activity and sends content to the vendor’s cloud for classification, then waits for a verdict. Many products marketed as AI-powered endpoint DLP work this way: the AI runs in the cloud, and the endpoint software forwards data to it. At the other end, classification and enforcement both happen on the device.

‍

The difference shows up at the moment of the action. A product that classifies in the cloud has to send the content out and wait for an answer, which is often too slow to block a paste or an upload before it completes. When the laptop is offline, it either stops protecting data or falls back to older, simpler rules. A product that classifies on the device can decide immediately, with or without a connection.

‍

Bold sits at the second end. It classifies data on the device, stores policy there, and makes enforcement decisions locally. That is what makes real-time prevention possible, rather than detection after the data has already left.

What each layer misses on its own

Network DLP misses what it cannot reach or read. That includes encrypted traffic from applications that refuse inspection, activity that never creates traffic, and anything that happens while a laptop is offline.

Cloud DLP misses what happens outside the applications it integrates with. That includes SaaS tools nobody connected, unsanctioned applications, and every copy of a file after it is downloaded to a device.

Endpoint DLP misses what never touches a managed device. That includes email sent from servers, server-to-server transfers, sharing that happens entirely inside a SaaS platform, and devices where the organization cannot install software, such as a contractor's personal laptop.

Those gaps overlap very little, which is why mature programs usually run more than one. What has changed is how much of the problem sits on each side.

Network vs. Cloud vs. Endpoint DLP: The Real Differences

The table below compares what each one can and cannot see. The sections after it cover the gaps that matter most.

The sections below take those differences one at a time: encryption, local activity, context, downloads, connectivity, desktop AI apps, and how network and cloud DLP have converged.

Encrypted traffic: network DLP has to decrypt it, cloud and endpoint DLP do not

Network DLP reads traffic by decrypting it, which only works if the application accepts the gateway’s certificate in place of the real one. Applications that use certificate pinning refuse, the connection fails, and the usual fix is to add them to the SSL bypass list, where their traffic is never inspected. Your proxy’s bypass list is a direct record of what network DLP cannot see.

Cloud DLP avoids this by reading content through the platform’s API. Endpoint DLP avoids it by reading data on the device before the application encrypts it.

Local activity: only endpoint DLP sees what stays on the device

Copying a file to USB, printing, pasting into a local application, renaming a file, and an AI agent reading a folder all happen without network traffic or a cloud application. Network DLP has nothing to inspect, and cloud DLP has no record to read.

Endpoint DLP sees all of it, because it runs where the activity happens. That matters most in departing-employee cases, where removable media and printing are common paths.

Context: network and cloud DLP see the destination, endpoint DLP sees the source

Network and cloud DLP see the destination, the content, and the account or session. They do not see which local application sent the data, whether a person clicked something first, or where the file came from on the device. Network DLP also cannot tell a company account from a personal one on the same domain.

Without that context, alerts take longer to review. Endpoint DLP has it at the moment of the action.

Downloads: cloud DLP covers the platform, endpoint DLP covers the copy

Cloud DLP governs a file while it sits in an integrated application. Once someone downloads it, the platform has no record of the copy, and the same is true of any SaaS tool nobody connected.

Endpoint DLP picks up where that record ends, recognizing the file when it arrives on the device and applying policy wherever it goes next. We cover the same handoff in DSPM vs. DLP.

Connectivity: network and cloud DLP need one, endpoint DLP can work without

Network DLP needs a path to the inspection point, so its decisions arrive after a round trip, often too late to block. When a laptop is offline, neither network nor cloud DLP can inspect or enforce anything on it.

Endpoint DLP has the same problem if it sends content to a cloud service for classification. The question to ask a vendor is whether classification and enforcement both happen on the device.

Desktop AI apps: the case that tests all three

Desktop AI applications run locally, may refuse inspection, often have no integration a cloud DLP can connect to, and receive pasted content rather than file uploads. The content is also the hardest to classify with pattern matching: source code, financial models, and customer records.

Endpoint DLP that classifies content by meaning addresses both problems, because it sees the paste on the device and recognizes what was pasted.

Convergence: network and cloud DLP now share a platform

Security service edge (SSE) and secure access service edge (SASE) platforms deliver network inspection and cloud application control from one policy engine. For most buyers, network and cloud DLP are now two functions of a single product.

Endpoint DLP developed separately, as work moved into desktop applications and AI agents. The useful question is less which categories you own and more whether anything covers the device.

When you need each

You need network DLP when:

• You need to inspect email at the gateway, which endpoint DLP does not replace.
• You have server-side or server-to-server data flows with no device to install software on.
• You have compliance requirements met by boundary logging and reporting.
• You have contractor or unmanaged devices where you cannot install software, so network control is the only option.

You need cloud DLP when:

• Sensitive data lives inside SaaS platforms and the risk is how it gets shared.
• External sharing, public links, and overly broad permissions inside cloud applications are concerns.
• You need to fix problems inside the platform, such as revoking a share or quarantining a file.

You need endpoint DLP when:

• Your SSL bypass list includes applications that handle sensitive data.
• USB, printing, clipboard, and local file activity have no coverage.
• Employees regularly work off the corporate network.
• Desktop AI applications and local agents are in use and nothing inspects what goes into them.
• You need to know which application started an action and whether a person was behind it.

Most organizations need at least two. The layers cover different positions, and mature programs combine them. What has changed is the balance. More of the problem now sits on the device, and it is the layer most programs cover least.

The Bottom Line

The difference between network, cloud, and endpoint DLP is where each one can inspect, not which channels a datasheet lists. Network inspection needs traffic to exist, to pass a controlled point, and to be readable. Local activity removes the first condition, offline laptops remove the second, and pinned or encrypted applications remove the third.

Cloud DLP covers sharing and permissions inside SaaS applications well, and it has no view of data once it reaches a laptop.

Network and cloud controls still matter. Email gateways, server-side flows, and sharing inside SaaS platforms are real, and endpoint software does not cover them. But an organization that inspects only at the network and in the cloud is covering less of how data moves each year, and the part it misses is where AI tools run.

Bold covers the device. It runs AI locally on the endpoint to classify data by meaning, see local files, clipboard, USB, printing, and desktop applications, tell human activity apart from AI-agent activity, and enforce at the moment of the action without a cloud round-trip or a network connection. [Talk to Bold] to see what is moving on your endpoints that your network and cloud tools never inspected.

FAQ

Do I need endpoint DLP if I already have network DLP?

If your employees use laptops, yes. Network DLP cannot see USB transfers, printing, clipboard activity, local file activity, or traffic from applications that are pinned, bypassed, or never connect to the network. Those paths show up regularly in departing-employee incidents.

Can network DLP inspect AI tool usage?

Partly. Browser-based AI usage that passes through an inspecting proxy is visible. Desktop AI applications often pin certificates or add their own encryption, and content pasted into a prompt may not look like a file upload to the tool. Seeing local AI applications and agent activity requires visibility on the device.

What is certificate pinning and why does it break DLP?

Certificate pinning means an application only accepts a specific certificate it already expects, instead of trusting the device's list of certificates. Network inspection works by substituting the gateway's certificate, so a pinned application rejects it and fails to connect. The usual fix is a bypass rule, which permanently excludes that application's traffic from inspection.

Is cloud DLP the same as network DLP?

They now usually come from the same product, since SSE and SASE platforms deliver both from one policy engine. They still work differently: network DLP inspects traffic in the path, and cloud DLP connects to SaaS platforms through their APIs. Both work off the device, which is the difference that matters most for coverage.

What is the difference between cloud DLP and endpoint DLP?

Cloud DLP governs data inside SaaS platforms such as Microsoft 365, Google Workspace, and Salesforce, through their APIs. Endpoint DLP governs data on the device: local files, clipboard, USB, printing, and desktop applications. Cloud DLP stops seeing a file once it is downloaded. Endpoint DLP starts there. Most organizations need both, since each covers data the other cannot reach.

Does endpoint DLP work offline?

It depends on where classification runs. A product that sends content to a cloud service for classification stops protecting data when the connection drops, or falls back to outdated policy. A product that classifies and enforces entirely on the device keeps working without a connection.

Does endpoint DLP replace network DLP?

No. Email gateway inspection, server-side flows, and devices where you cannot install software belong to network DLP. The two cover different positions, and the endpoint share of the problem has grown because more work happens on the device.

How do I find out what my network DLP is missing?

Three checks, none of which require a vendor. Pull the SSL bypass list from your proxy and treat it as a list of uninspected applications. Check whether any policy covers USB transfers, printing, and clipboard activity. Then estimate how much of your employees' working time is spent off the corporate network, since boundary controls do not apply during that time.