TL;DR: 39.7% of data employees share with AI tools is sensitive, while endpoint-based AI agents grew 509% in 2025, according to Cyberhaven research, underscoring why legacy blocking and content-only DLP cannot govern machine-speed data flows effectively. The security issue is no longer whether employees will use AI, but whether organisations can apply policy without losing visibility or control.
At a glance
What this is: This is an analysis of how modern DLP changes the governance model for AI adoption by adding endpoint visibility, data lineage, and risk-based policy enforcement.
Why it matters: It matters because IAM, NHI, and security teams increasingly need controls that govern human, machine, and agent-driven data movement without relying on blunt blocking that drives shadow AI and audit gaps.
By the numbers:
- 39.7% of the data employees share with AI tools is sensitive.
- 509% in 2025.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
👉 Read Cyberhaven's analysis of modern DLP for AI adoption and data governance
Context
Modern AI adoption creates a governance problem because data now moves through chat assistants, coding copilots, and endpoint-based agents faster than traditional DLP was designed to inspect. The core issue is not AI usage itself, but whether organisations can see sensitive data before it is transformed, copied, or exfiltrated through tools that employees bring into the workflow.
That matters directly to identity and access governance because AI tools behave like controlled data consumers, and endpoint-based agents can bypass browser and network controls entirely. For IAM and NHI teams, the question becomes how policy follows the user, the workload, and the agent across approved and shadow channels without turning every AI interaction into a blocking event.
Key questions
Q: How should security teams govern employee AI use without blocking productivity?
A: Start with visibility into sanctioned and shadow AI use, then apply runtime policies that inspect intent and context rather than only keywords. The goal is to allow legitimate work while preventing sensitive data from leaving controlled boundaries. Teams usually need ownership, approved models, and enforceable logging before they can scale access safely.
Q: Why do traditional DLP controls struggle in cloud and AI workflows?
A: They rely too heavily on static rules, shallow content inspection, and limited context. In cloud and AI workflows, the same data can be safe in one destination and risky in another, so controls that ignore role, classification, and usage patterns either overblock or miss the real problem.
Q: What do security teams get wrong about blocking AI tools outright?
A: They assume network blocking creates control, but users often shift to personal devices, browser workarounds, or OS-level agents that bypass those restrictions. Blocking can reduce visible risk while increasing shadow AI and making the governance problem harder to measure.
Q: Which controls matter most when AI tools touch privileged data?
A: The most important controls are access classification, secrets governance, telemetry, and restrictions on where sensitive data can be processed. If an AI workflow can reach privileged data, then access review alone is not enough. The organisation also needs monitoring that shows what the tool actually did.
Technical breakdown
Why legacy DLP fails in AI-driven workflows
Legacy DLP was built for static content inspection and predictable transfer points such as email, web uploads, and removable media. AI changes the problem because a file can be summarised, rephrased, or combined with other data before leaving the endpoint, which means the original content is no longer the only risk signal. If the control cannot see the data at the point of use, it cannot enforce policy on the transformed output or the downstream destination.
Practical implication: move beyond network-only inspection and verify that controls can inspect AI activity at the endpoint.
How data lineage changes the control model
Data lineage tracks where content originated, how it changed, and where it travelled. That is materially different from keyword matching or simple classification because the same source code, customer record, or contract clause can carry different risk depending on the destination and the surrounding context. Lineage gives security teams an evidentiary trail for audit, incident response, and policy enforcement, especially when AI tools are rewriting or restructuring the content.
Practical implication: require lineage-aware controls if your AI governance program must survive audit or incident review.
Why endpoint-level visibility matters for AI agents
Endpoint-based AI agents operate at the operating system layer, so browser proxies and cloud gateways will miss a growing share of activity. That is a governance gap, not just a telemetry gap, because the control plane never sees the data flow in the first place. In identity terms, the agent becomes a data consumer that needs policy attached to its runtime behaviour, not just to the application it uses.
Practical implication: ensure endpoint telemetry is part of any AI governance design that must cover shadow AI and agentic workflows.
NHI Mgmt Group analysis
Modern DLP is becoming the enforcement layer for AI governance, not a perimeter add-on. The article describes a shift from broad blocking to policy-based control, and that shift reflects a broader market reality: employees are already using AI tools across sanctioned and unsanctioned channels. For practitioners, the lesson is that AI governance fails when the control model assumes one network path and one application boundary.
AI data leakage is now an identity-adjacent governance problem as much as a content problem. Once employees paste sensitive material into AI systems, the issue is no longer only what the content is, but who accessed it, through which endpoint, and under what policy. That puts AI usage closer to IAM, NHI, and access governance than many security programmes currently recognise, especially where approved and shadow tools coexist.
Data lineage is the named control concept that separates defensible AI governance from reactive blocking. Lineage gives organisations the ability to trace origin, sensitivity, and destination across transformations that legacy DLP cannot see. In governance terms, that creates an auditable chain of custody for AI-era data movement, which is the difference between policy that exists on paper and policy that can be proved in practice.
The false choice between AI adoption and security is a programme design failure, not a technology law. Blocking tools at the firewall shifts behaviour to unmanaged endpoints and personal channels, while permitting everything without inspection creates compliance and breach exposure. The better frame is controlled enablement, where security owns the rules and the business keeps moving within them.
What this signals
AI governance is converging with identity governance because the same policy questions now apply to users, workloads, and AI-driven data consumers. Organisations that already struggle with secrets visibility and access hygiene will find that endpoint AI usage multiplies the number of places where governance can fail, especially when shadow tools bypass the approved control path.
Data lineage discipline: the next maturity step for AI security is not simply more blocking but better traceability across origin, transformation, and destination. That aligns closely with how identity teams think about lifecycle control, except the object being governed is now a sensitive data flow rather than just an account or token. For readers running identity-heavy programmes, this is a sign to bring IAM, NHI, and AI governance into one operating model.
The practical signal is that procurement decisions should increasingly ask whether a DLP control can see endpoint-based AI agents, not just browser sessions. Teams that cannot answer that question are likely to accumulate unmanaged AI usage, opaque exceptions, and weak evidence for auditors and boards.
For practitioners
- Map AI data flows by endpoint, not just by network path. Inventory where employees use chat assistants, copilots, and endpoint-based AI agents, then verify whether your current controls can see those flows outside browser traffic. Treat unmanaged endpoints and personal devices as first-class governance blind spots.
- Classify AI-use data by destination and context. Apply different policy outcomes for source code, customer PII, contract text, and unclassified content, and distinguish approved tools from shadow AI. The same payload can carry different risk depending on where it is going and whether the user is authorised to send it there.
- Require lineage for high-risk AI interactions. Preserve origin, transformation, and destination metadata for sensitive content that enters AI systems so you can support audit, investigation, and policy proof later. If the control cannot explain why a decision was made, it will not stand up in a review.
- Separate governance ownership from enforcement. Let the business define which AI use cases are allowed, but keep policy enforcement inside security and compliance so exceptions are measurable. This reduces shadow approval paths and keeps AI adoption from turning into a series of ad hoc local decisions.
Key takeaways
- Modern DLP is shifting from passive inspection to active governance for AI-era data movement.
- Endpoint-based AI usage creates visibility gaps that network controls alone cannot close.
- Identity, data lineage, and context-aware policy now need to work together if AI adoption is to remain auditable.
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, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | AI data movement and sensitive content protection align with data security outcomes. |
| NIST SP 800-53 Rev 5 | AC-6 | Context-aware policy enforcement reflects least-privilege access to sensitive data. |
| NIST AI RMF | MANAGE | AI governance here is about controlling risk in operational use. |
| ISO/IEC 27001:2022 | A.5.15 | Access control governance applies to who can move sensitive data into AI tools. |
Use MANAGE to operationalise controls that reduce AI data leakage without blocking legitimate use.
Key terms
- Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- Context-Aware Policy: Context-aware policy is a control model that decides access based on current conditions, not just preassigned entitlement. For AI agents and other non-human identities, this means privileges, tool use, and monitoring expectations can change as the task, environment, or risk signal changes.
What's in the full article
Cyberhaven's full blog covers the operational detail this post intentionally leaves for the source:
- Endpoint visibility requirements for AI-native DLP deployments across SaaS and OS-level agents
- Data lineage implementation details for tracing origin, transformation, and destination across AI workflows
- Policy examples for allowing approved AI use cases while blocking or prompting on sensitive data
- Practical governance framing for CIO, CFO, and security ownership decisions
👉 Cyberhaven's full post covers endpoint controls, data lineage, and AI policy enforcement details
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners building disciplined identity controls across modern security programmes.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org