By NHI Mgmt Group Editorial TeamBased on Cyera: “The Great DLP Reset: Securing Data in the Age of SaaS, Cloud, and AI” (May 5, 2026)

TL;DR: Legacy DLP models are breaking as data now moves across SaaS, cloud, and AI workflows that endpoint, network, and email controls cannot fully see, according to Cyera. The architectural shift is from fragmented inspection to discovery-led data control, because perimeter-era assumptions no longer match how modern information is created, shared, and governed.


At a glance

What this is: This report says legacy DLP is failing in SaaS, cloud and AI environments because fragmented inspection controls cannot keep pace with how data now moves and is reshaped across modern workflows.

Why it matters: For IAM, NHI and security teams, the shift matters because governance now depends on discovering data context and access paths continuously, not assuming a static perimeter or a fixed review boundary.


Context

Data loss prevention has traditionally relied on controls placed at the endpoint, network, or email layer. That model assumes information can be observed at stable choke points, but SaaS collaboration, cloud workflows, and AI-assisted content creation have dissolved those choke points.

For identity and security programmes, the problem is not simply more data. It is that data context now changes as access moves across users, service accounts, and AI-driven workflows, so the governance model has to start with discovery rather than inspection alone.


Key questions

Q: How should security teams close the access-trust gap in SaaS and AI environments?

A: Start by measuring where users actually work, not where the identity programme assumes they work. Security teams should inventory unmanaged apps, non-federated accounts, and AI tools, then apply policy, offboarding, and monitoring to the uncovered paths first. The goal is to make hidden access visible enough that governance can follow it.

Q: Why do SaaS file-sharing workflows make traditional DLP less effective?

A: SaaS sharing often moves data through links and permissions rather than direct file transfer, so older DLP tools may not understand the actual sharing model. That makes it hard to judge what content is exposed, who can reach it, and whether a link is being misused. Encryption and indirect sharing semantics further limit inspection, so security teams need controls built for cloud collaboration.

Q: How should security teams evaluate whether DLP is keeping up with modern data flows?

A: Start by checking whether DLP coverage matches the places data actually moves, including endpoints, cloud apps, collaboration tools, and shared secrets. If alerts rise but leak paths remain unchanged, the tool is seeing symptoms rather than controlling exposure. The strongest signal is reduced high-risk movement across the identities and channels that matter most.

Q: What should organisations do first when rebuilding DLP for cloud and AI environments?

A: Organisations should start by discovering where sensitive data is created, copied, and reused across applications and AI workflows. That gives them the context needed to prioritise controls, map access paths, and decide where legacy inspection points still work. Without that inventory, DLP redesign will remain guesswork.


Technical breakdown

Why perimeter-era DLP misses modern data movement

Legacy DLP was designed for traffic that could be inspected at a few predictable control points. In SaaS and cloud environments, data is copied, transformed, shared, and embedded across applications, which means policy engines see only fragments of the full data journey. Once AI is introduced, the problem deepens because content can be generated, summarised, and redistributed at machine speed, often outside the original control path. The practical issue is not that DLP vanished, but that its inspection point moved too late in the lifecycle to explain the data context accurately.

Practical implication: move from boundary inspection to continuous discovery and classification across the systems where data is actually created and used.

What a discovery-led data control plane changes

A discovery-led data control plane treats data identification, classification, and policy enforcement as connected functions rather than separate tools. Instead of waiting for traffic to cross a perimeter, it builds an always-on understanding of what data exists, where it sits, who can reach it, and how it is shared through SaaS, cloud, and AI workflows. That architecture is especially relevant where identity and access are dynamic, because policy decisions can then reflect live context rather than stale assumptions. This is a governance model, not just a detection model.

Practical implication: align DLP policy with data discovery, entitlement mapping, and usage context so controls can follow the workflow rather than the network edge.

Why AI changes the DLP problem, not just the scale of it

AI does not merely increase the volume of data moving through the environment. It changes how data is produced and reused, because prompts, outputs, embeddings, and summaries can all carry sensitive content into new contexts that classic DLP controls were never tuned to inspect. That creates a classification problem as much as a prevention problem: if the system cannot understand the data context, it cannot judge the risk of disclosure or reuse. For identity teams, this means access governance now intersects with content governance in ways traditional DLP never had to manage.

Practical implication: extend governance to AI-assisted data creation and sharing paths, not only to outbound exfiltration points.


Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Legacy DLP failed because it was built for fixed inspection points, not fluid data journeys. When information moves across SaaS, cloud, and AI workflows, the old assumption that security can watch the edge and infer the rest stops holding. The result is not just blind spots, but a governance model that misreads where data actually lives and how it is used. Practitioners need to treat discovery as the starting condition for DLP, not an add-on.

Discovery-led control is the right architectural response because data context is now dynamic. The value is not inspection volume, but the ability to connect classification, entitlement, and usage in one operating model. That matters for identity programmes because permissions only become meaningful when paired with the data they expose. The practitioner takeaway is that DLP and identity governance now share the same context layer.

AI turns data protection into a continuous governance problem. Prompts and generated output can create new disclosure paths without passing through the same checkpoints as email or file transfer. That means the control question shifts from 'Where did the data leave?' to 'How was the data contextualised as it moved?' The implication is that security teams must govern data reuse inside workflows, not just exfiltration at the perimeter.

The new DLP baseline is data-context-driven prioritisation, not uniform control placement. Organisations should stop assuming every data path deserves the same inspection depth. High-risk data, high-risk identities, and AI-mediated workflows need tighter discovery and faster policy resolution than low-risk collaboration. The practical conclusion is that DLP maturity now depends on how well teams map context to control intensity.

From our research library:

What this signals

Discovery-led DLP changes the control question from traffic inspection to data context. Security teams will need to understand where sensitive information is created, transformed, and reused across SaaS and AI workflows before policy can be effective. That makes data discovery and classification part of the operating model, not a separate hygiene task.

Identity governance becomes more important when data protection depends on context. Once access paths move across users, service accounts, and AI-assisted workflows, the entitlement model has to explain not just who can reach data, but how that access changes the data's risk profile. Teams should expect DLP, IAM, and data governance to converge around the same context layer.


For practitioners

  • Inventory data paths beyond the perimeter Map where sensitive data is created, copied, summarised, shared, and re-used across SaaS, cloud, and AI workflows. Use that inventory to identify where endpoint, network, and email controls no longer provide meaningful coverage.
  • Connect discovery to classification and entitlement context Tie discovery results to the identities and service accounts that can access each dataset so policy decisions reflect current usage, not stale labels or static trust assumptions.
  • Prioritise AI-mediated data flows first Focus initial DLP redesign on prompts, generated outputs, document summarisation, and cross-application sharing paths where AI changes the content lifecycle most quickly.
  • Separate high-context data from routine collaboration traffic Apply deeper inspection and tighter policy resolution to data that is business sensitive, regulated, or frequently reused in workflows, while keeping lower-risk collaboration flows lighter.

Key takeaways

  • Legacy DLP breaks down when organisations rely on fixed inspection points that no longer match how data moves across SaaS, cloud, and AI systems.
  • The core shift is toward discovery-led governance that links data context, identity context, and workflow context before policy decisions are made.
  • Security teams need to rebuild DLP around continuous discovery and classification if they want controls to follow the actual data lifecycle.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 provides the primary governance reference for this term.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.DS-10 — Data in Transit is ProtectedThe article concerns protecting data as it moves through SaaS, cloud and AI workflows.
Recommendation — Apply PR.DS-10 to protect sensitive data in motion across collaboration and AI pathways.

Key terms

  • Discovery-led Data Control Plane: A discovery-led data control plane is the governance layer that first finds where data lives, how it moves, and who or what can touch it. It continuously inventories data assets, classifies sensitivity, and applies policy decisions across storage, pipelines, APIs, and AI workflows to reduce blind spots and enforce control.
  • Data Context: Data context is the operational understanding of what data exists, where it lives, how sensitive it is, and which identities can reach it. In incident response, data context turns alerts into decisions by showing whether a system holds regulated records, test copies, or low-risk content. It is essential for defensible containment and notification scope.
  • AI Mediated Data Flow: Data movement that passes through an AI system on behalf of a user or process. The key issue is that the model becomes part of the handling path, so sensitive information can be transformed, retained, or forwarded in ways traditional file and email controls do not observe directly.
  • Perimeter-Era DLP: A legacy DLP approach built around endpoints, networks, and email as primary inspection points. It assumes data can be governed effectively by watching a few predictable choke points, which is increasingly unreliable in SaaS, cloud, and AI-driven environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org