Every data security program still gets built around a two-state model: data in motion and data at rest. It made sense when data had a network path you could log and a storage location you could lock down. This approach makes a lot less sense now that the same file can sit at rest in Google Drive one minute and get pasted into a Claude or ChatGPT prompt the next, with no firewall event to mark the handoff. Not to mention that the same file can be duplicated, fragmented, and utilized in different ways simultaneously.
If your data security posture management (DSPM) program is still organized around state instead of movement, you already have a blind spot.
What Is the Difference Between Data in Motion and Data at Rest?
Data in motion is data actively being transferred between systems, and data at rest is data sitting in storage without being processed or moved. Data in motion includes files traveling over a network, an API call, or a sync to a cloud drive. Data at rest includes anything sitting in a database, a file server, or a SaaS repository. Security teams have historically applied different controls to each: encryption and secure transport for data in motion, access controls and monitoring for data at rest.
The technical boundary between the two states comes down to whether data is actively traversing a transmission path or holding still in a storage medium.
Data in motion, also called data in transit, covers any transfer between endpoints: a file uploaded to a cloud drive, a query passed to an application programming interface (API), a payload moving through a message queue, or traffic crossing a virtual private network (VPN). The standard controls are transport-layer encryption, typically Transport Layer Security (TLS) 1.2 or higher, along with mutual authentication between the systems on each end and integrity checks to confirm the payload was not altered in transit. Network detection tools inspect this traffic at defined points, a proxy, a gateway, or an endpoint agent, looking for patterns that match sensitive content as it crosses that boundary.
Data at rest covers anything held in persistent storage: relational and non-relational databases, object storage buckets, file shares, backups, and SaaS repositories like Google Drive or SharePoint. The standard controls are encryption at rest, usually AES-256, combined with access control lists or role-based access control (RBAC) to govern who can reach the data, and periodic audits to catch misconfigured permissions or stale sharing links. Data at rest also carries a compliance dimension that data in motion does not: retention schedules, geographic storage requirements, and audit logging obligations all apply to data sitting in a known location over time.
Both models assume a defined boundary, a network edge for data in motion and a storage location for data at rest, where security tools can inspect or control the data. That assumption holds for traditional infrastructure. It holds a lot less well once data starts moving through channels neither model was built to see.
Why the Two-State Model Breaks Down for AI Tools
The two-state model assumes movement happens over a network path a security tool can see. Generative AI tools (GenAI) and agentic AI applications broke that assumption. When an employee pastes a customer contract into ChatGPT, uploads a spreadsheet to Copilot, or connects a repository to an AI coding assistant, sensitive data moves, but it does not move the way a firewall or a legacy data loss prevention (DLP) rule expects.
Given that, according to Cyberhaven Labs, there’s been an 80% year-over-year increase in data movement events into and out of GenAI SaaS, June 2025 to June 2026, it’s clear that they way data moves through an environment is rapidly changing, with descriptors such as “at rest” and “in motion” becoming less insightful.
This is the gap strategists are actually being asked to close. Data does not stop being at risk because it left through a browser tab instead of a network egress point. It just stops being visible to tools built around the old model.
Where Legacy DLP and Posture Tools Fall Short
Most legacy DLP deployments were built to inspect easily recognizable content at a well-known boundary: email, endpoint, network egress. Legacy DLP works by matching patterns or regex against data as it crosses that boundary. Two problems follow from that old design.
First, these solutions cannot classify data by what it actually is, only by what it looks like at the moment of transfer, so file renames, screenshots, and paraphrased content routinely slip through. Second, they offer no record of where a piece of data originated or how it got to its current location, so an analyst investigating an incident is left reconstructing that history by hand.
Posture tools built purely around data-at-rest scanning have the opposite, but equally concerning, problem. These tools can tell you a file is overexposed right now, but cannot tell you how it got that way or whether it has already moved somewhere else.
What to Track Instead of Data State
The more durable question is not whether data is in motion or at rest at any given moment. It is where the data came from, what has happened to it since, and who has touched it along the way. That question holds regardless of which state the data happens to be in when you ask it.
This is the strategic shift worth making in program design: build around data's full history, not a snapshot of its current state. A file's risk profile depends on its origin, its sensitivity, and its path, not on whether it is technically "moving" at the instant you check.
How Data Lineage Closes the Gap
Data Lineage is Cyberhaven's continuous record of where sensitive data originated, how it moved, and who touched it along the way, tracked automatically across endpoints, cloud apps, and AI tools. Instead of inspecting content at a single boundary, Linea AI, Cyberhaven’s AI-engine, then follows data through its full lifecycle, so a file uploaded to an AI assistant is traceable back to the source system it came from and every hop in between.
That history is what makes Cyberhaven's platform work without the manual rule-building legacy tools require. Security architects get a single, continuous view of data risk that does not reset every time data changes state.
Data in motion and data at rest are still useful categories, but they were never built to account for how data moves through AI tools today. Programs that track data's full history, not just its current state, catch risk the two-state model misses.
See how the AI era is changing how organizations approach data security with “IDC Spotlight: Rethinking Data Security and Insider Risk for Trusted AI Adoption.”
Explore the power of data lineage.
Frequently Asked Questions
Is data pasted into an AI prompt "in motion" or "at rest"?
It is in motion at the moment it is submitted, but most security tools built for data in motion cannot see it because the transfer does not follow a traditional network path. This is why AI tool usage needs coverage beyond the standard two-state model.
Do DLP tools protect data used in ChatGPT or Copilot?
Legacy DLP tools built around network and endpoint boundaries generally cannot see data entering AI tools through browser uploads or copy-paste. Coverage requires visibility into the AI tool itself, not just the network path leading to it.
What is data lineage in data security?
Data lineage is a continuous record of where sensitive data originated, how it has moved, and who has accessed it, tracked across its full history rather than at a single point in time.
How is data lineage different from data classification?
Data classification labels what a piece of data is at a given moment. Data lineage tracks where that data has been and how it got there, which classification alone does not capture.
Why does the data in motion vs. data at rest model matter less for AI risk?
Because AI tools move data in ways that do not map cleanly to either state. A file can be at rest one moment and processed by an external model the next, with no clear boundary crossing for legacy tools to catch.
.avif)
.avif)
