Most organisations that have invested in data loss prevention believe they have the problem reasonably under control. Endpoint agents are deployed, network monitoring is in place, and policies govern how data moves across managed infrastructure. What many have not fully confronted is that the majority of sensitive data in a modern finance or software organisation no longer moves through infrastructure they manage. It moves through a browser.
The move to SaaS has redrawn where data lives and how it travels. Employees access customer records in Salesforce, financial data in NetSuite, source code in GitHub, and internal documentation in Notion, all through a browser, all generating data interactions that traditional DLP tools were never designed to see. Legacy approaches built for network perimeters and managed endpoints have a structural blind spot at precisely the layer where most data handling now happens.
The problem has a second dimension that has grown more acute in the past twelve months. Employees are using generative AI tools like ChatGPT, Copilot, Gemini and others as part of their daily workflows, and they are feeding those tools with whatever data they need to complete the task in front of them. Proprietary code, customer information, financial projections, internal communications. The data flows into a public tool outside the organisation’s boundary, often without the employee understanding the exposure they are creating, and without any policy control in place to detect or prevent it.
The Distance Between Policy and Enforcement
Most organisations have policies that nominally address this. Acceptable use policies prohibit inputting confidential data into public AI tools. BYOD policies attempt to define boundaries around personal devices. MDMs broadly solve this issue but restrict users to specific technologies like Edge and CoPilot (via InTune). The practical reality is that these policies are almost entirely unenforceable at the browser level with traditional security tooling.
There is no mechanism to inspect what an employee types into a ChatGPT prompt, no visibility into whether a contractor on an unmanaged device is downloading sensitive files through a SaaS interface, and no reliable way to prevent personal accounts from being used to access business applications.
The distance between what policy says and what is technically enforced is where data loss actually occurs. In environments operating under GDPR, or financial services organisations subject to DORA, that distance carries real regulatory consequences. Demonstrating control over data handling requires evidence that controls were technically enforced at the point of interaction.
Moving the Control Plane to Where Data Is Actually Touched
The logical response is to move the control plane to where data interaction actually happens like the browser itself. Rather than trying to infer what happened to data after it left a managed network, browser-native DLP applies policy at the moment a user accesses, inputs, downloads, or shares data through a SaaS application.
This means detecting and blocking sensitive data being entered into AI tools in real time, before it leaves the organisation’s boundary.
It means enforcing posture checks on unmanaged and BYOD devices before granting access to business applications, and applying read-only controls, download restrictions, and clipboard policy for sessions that pass those checks. It means ensuring that access to sanctioned applications requires authentication through the organisation’s identity infrastructure, not through personal accounts that bypass corporate controls entirely. And it means maintaining the audit trail that compliance frameworks require, a log of what was accessed, edited, downloaded, and shared, with enough fidelity to satisfy regulators and support incident investigation.
This is the architecture that SURF Security is built around. Rather than sitting at the network layer and attempting to reconstruct what happened to data after the fact, SURF operates as an enterprise browser and extension that enforces DLP policy at the data interaction layer, where SaaS data is actually accessed and manipulated. For organisations in finance and software that need to demonstrate real control over sensitive data in a SaaS-heavy environment, that is where security architecture needs to reach.
What Effective SaaS DLP Actually Requires
The organisations that manage this well have moved beyond thinking about DLP as a network or endpoint problem. They have mapped where sensitive data actually flows, which SaaS platforms hold it, which user roles interact with it, and which interaction types carry the most risk. They have configured policies that are context-aware rather than binary, applying different controls based on user role, device posture, and the nature of the interaction rather than simply blocking or allowing at the application level. And they have implemented real-time inspection that acts at the moment of interaction rather than detecting violations after the data has already moved.
Browser-native DLP is not about adding another security layer. It is about ensuring that the control layer exists at the point where the risk actually sits. For most organisations, that is the browser and right now, most security architectures leave it largely unprotected.
