Data in motion and data at rest no longer explain AI data risk

At a glance

What this is: Cyberhaven argues that the data in motion versus data at rest model no longer captures AI-era data movement because the same file can jump from storage into GenAI tools without a traditional network boundary.

Why it matters: IAM, data security, and NHI teams need lineage-based visibility because control points built around static states do not explain how sensitive data is handled across prompts, assistants, and shared workflows.

By the numbers:

• Cyberhaven Labs reports an 80% year-over-year increase in data movement events into and out of GenAI SaaS from June 2025 to June 2026.

Context

Data security programs have long relied on a simple split between data at rest and data in motion, but that model depends on clear storage boundaries and visible transfer paths. AI tools weaken both assumptions because the same file can move from a repository into a prompt, an assistant, or a coding workflow without a conventional network event.

For IAM and data governance teams, the practical issue is not classification alone but whether security controls can follow the data as it crosses tools, identities, and interaction modes. That creates an identity-adjacent governance problem as well, because the access path is often mediated by human users, copilots, connectors, and service accounts rather than a single static system boundary.

Cyberhaven's example is increasingly typical for organisations adopting GenAI and agentic workflows, not an edge case.

Key questions

Q: How should security teams govern sensitive data used by AI systems?

A: Security teams should treat AI as a data consumer that needs policy boundaries, not just authentication. Classify sensitive data, define which datasets may enter AI workflows, and monitor outputs, logs, and downstream reuse. If governance stops at login, the organisation can approve access while still losing control of the data itself.

Q: Why do legacy data state controls miss AI data risk?

A: Because they assume data crosses a visible boundary such as email, network egress, or storage access. Browser paste, uploads, and connector-driven flows into GenAI tools can bypass those inspection points, so the control sees the file’s destination less clearly than its actual journey.

Q: What are the signs that data posture controls are failing in AI workflows?

A: Common signs include unexplained prompt usage, sensitive files appearing in AI tools without matching transfer logs, and investigations that can identify the file’s destination but not its intermediate hops. Those symptoms indicate the programme is seeing state, not movement.

Q: What should IAM teams do when AI workflows touch sensitive data?

A: Treat AI usage as part of the identity and access review process. IAM teams should validate who can access the data, where that data can be used, and whether the AI workflow has guardrails that match the data classification. That creates a control view that is actionable during recertification and audit.

Technical breakdown

Why the state model fails in AI workflows

The data in motion versus data at rest model assumes security tools can observe a stable boundary, such as a network edge or storage location. AI use breaks that assumption because data can be copied into prompts, browser sessions, copilots, and assistants without passing through the inspection points legacy controls were designed to monitor. The result is not that data becomes invisible everywhere, but that visibility becomes fragmented across endpoints, cloud apps, and user interactions. That fragmentation matters because security teams lose the ability to reason about the full path of a sensitive file, including where it originated and where it went next.

Practical implication: Security teams need controls that follow data movement across tools, not just controls that inspect a single transfer point.

How legacy DLP and posture tools miss AI-era movement

Legacy DLP is strongest when content crosses a known boundary in a recognizable form, such as email or network egress. It struggles when content is renamed, paraphrased, pasted, screenshot, or moved into a browser-based AI session because the original context is lost. Posture tools focused only on data at rest have the opposite limitation: they can identify overexposure in storage, but they cannot tell you whether the same data has already moved into another environment. Together, those gaps mean organisations may believe they have coverage while the actual data path remains untracked.

Practical implication: Treat AI tool usage as a lineage problem, not a boundary-inspection problem.

Data lineage as the control plane for AI-era risk

Data lineage is the continuous record of where sensitive data came from, how it moved, and who touched it along the way. In practical terms, it shifts governance from asking whether a file is currently moving or resting to asking what its full history looks like across endpoints, cloud apps, and AI tools. That is a more durable model for AI-era data governance because it preserves context after the data leaves its original system. For identity and access programmes, this also creates a clearer way to reason about delegated access, connector permissions, and the users or services that can move data into AI systems.

Practical implication: Build governance around data path visibility so prompts, assistants, and integrations do not become blind spots.

NHI Mgmt Group analysis

Data lineage is becoming the organising principle for AI-era data governance. The old state-based model was built for storage and transmission boundaries that no longer hold in browser-mediated AI workflows. When a file can move from a repository into a prompt without a network event, visibility has to shift from location to path. Practitioners should treat lineage as the durable control plane, not an optional telemetry layer.

State-based controls create false confidence in environments that use GenAI and copilots. A file can be properly encrypted at rest and still be exposed when a user pastes it into an external AI service. That does not make encryption irrelevant, but it does mean encryption and transport controls are insufficient on their own. The governance question becomes whether teams can reconstruct where sensitive data went after it left the original boundary.

Identity now sits inside the data-risk problem, not beside it. Human users, copilots, browser sessions, connectors, and service accounts all participate in moving data into AI tools. That makes access governance, delegated permissions, and NHI oversight part of the same control story as DSPM. Security teams should manage the identities that can move data as carefully as the data itself.

AI data risk exposes a lineage trust gap. Security programmes often assume they can answer where data is, but the more relevant question is how data got there and who mediated the transfer. The article shows that current controls often know the destination but not the journey. Practitioners should assume that any AI workflow without full path visibility is an incomplete governance model.

Fragmented visibility is the new failure mode. Legacy DLP, endpoint monitoring, and posture scanning each see a slice of the journey, but none reliably preserve the end-to-end context. That is why the issue is not simply more alerts, but a missing chain of custody for sensitive data. Teams should tighten governance around path reconstruction, not just event detection.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Data lineage is now a governance requirement, not a nice-to-have telemetry layer. Security teams that still organise controls around data at rest and data in motion will miss the AI-specific paths where information is pasted, uploaded, or delegated into external services. That gap is especially relevant where IAM, SaaS access, and NHI-driven connectors all participate in the same data flow.

Organisations need a chain-of-custody view for sensitive data. 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026. The same lesson applies here: if the path is invisible, the control model is incomplete.

For practitioners

• Inventory AI data movement paths Map where sensitive files enter GenAI tools, copilots, and connected assistants, including browser paste, upload, sync, and connector-based flows.
• Shift from state checks to lineage monitoring Prioritise controls that record origin, hops, and handlers across endpoints and cloud apps so investigations can reconstruct the full path of a file.
• Review delegated access into AI tools Audit the human, service, and connector identities that can move data into AI systems, then remove unnecessary permissions that expand data exposure paths.
• Tune DLP for AI-specific transfer modes Extend detection beyond traditional email and network egress to browser uploads, copy-paste, and SaaS-to-SaaS handoffs that legacy rules miss.

Key takeaways

• The two-state data model no longer explains how sensitive information moves through GenAI tools and copilot workflows.
• Legacy DLP and posture scanning can see storage state or transfer fragments, but they often miss the full path of a file once AI tools are involved.
• Data lineage gives security teams a better governance model because it tracks origin, movement, and handlers across endpoints, SaaS apps, and AI systems.

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.
• Data-in-Motion: Data-in-motion is sensitive information while it is being transferred between systems, identities, or applications. For SaaS and AI programmes, the main concern is not only where data is stored, but which identities can move it, transform it, or expose it during transit.
• Data at rest: Data at rest is information stored on disks, databases, backups, or object storage when it is not actively moving through a network or application flow. Protection usually relies on encryption, access restrictions, and strong key handling so stored information is not readable if the storage layer is exposed.
• Data Security Posture Management: Data Security Posture Management, or DSPM, is the continuous discovery and monitoring of where sensitive data lives, how it is exposed, and where policy gaps exist. Its value rises when it feeds remediation rather than generating findings alone, especially in environments where AI expands the number of data paths.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity. It helps practitioners align identity controls with the data and access paths that modern AI workflows create.