TL;DR: Legacy DLP fails when data moves across SaaS, encrypted messaging, personal cloud and AI tools, because file-level inspection, keyword matching and disconnected policies cannot follow modern exfiltration paths, according to Cyberhaven. The architectural shift is from content-only control to lineage-aware enforcement across endpoint, cloud and AI surfaces.
NHIMG editorial — based on content published by Cyberhaven: DLP Buyer's Guide: 8 Criteria for Evaluating Data Loss Prevention Solutions
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams evaluate DLP for AI and SaaS-heavy environments?
A: They should test whether DLP follows data across apps, accounts and formats rather than only scanning files at a perimeter.
Q: Why do personal accounts create a DLP governance gap?
A: Because the application may be approved while the account is not.
Q: What breaks when DLP cannot track data lineage?
A: Policies become reactive and brittle.
Practitioner guidance
- Map every exfiltration channel to one policy engine Test whether cloud, email, endpoint, browser, copy and paste, encrypted messaging and AI tool interactions are enforced by the same policy engine rather than separate controls.
- Require lineage-aware classification before production rollout Validate that sensitivity context survives copy and paste, format changes, application transitions and compression so that policies follow the data instead of the file.
- Separate corporate and personal account risk paths Confirm that the platform distinguishes managed enterprise accounts from personal accounts in the same application, including sanctioned AI tools and collaboration services.
What's in the full article
Cyberhaven's full DLP buyer's guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step evaluation questions for policy coverage across copy/paste, USB, email, browser activity and AI tools
- Practical guidance on how to test policies against historical user activity before going live
- Implementation considerations for endpoint agents, DSPM integration and forensic evidence storage
- Examples of how real-time coaching and override workflows change incident handling
👉 Read Cyberhaven's DLP buyer's guide on modern evaluation criteria →
Modern DLP and shadow AI: what do security teams need to evaluate?
Explore further
Modern DLP has become an identity and account-governance problem, not just a content-inspection problem. The article correctly shows that the same sanctioned application can represent very different risk depending on whether a user is in a corporate or personal account, or whether an AI system is handling the data. That shifts DLP from a file policy exercise into a control that depends on account context, device context and session context. Practitioners should read this as a warning that DLP and identity governance now overlap materially.
A question worth separating out:
Q: Should organisations treat shadow AI as a security risk or an innovation issue?
A: Treat it as both, but govern it first as a security risk. Shadow AI becomes dangerous when it can reach data, call APIs, or make decisions outside approved control paths. Security teams should build intake and review processes that allow safe experimentation without leaving identities and permissions unmanaged.
👉 Read our full editorial: Modern DLP needs data lineage, AI coverage and one policy engine