Because encryption protects stored data, not data that has already been decrypted for use. Once a user or AI system can read the content, it can be copied, pasted, uploaded, or forwarded through trusted channels. The failure is a boundary problem, not a cryptography problem.
Why This Matters for Security Teams
Endpoint encryption is valuable, but it is often misapplied as a data-loss control when it is really a storage protection measure. Once content is decrypted for legitimate use, the risk shifts to the application layer, the user session, and any connected workflow that can move data elsewhere. That is why security teams should treat encryption as one layer in a wider data protection strategy, not as a substitute for access governance, monitoring, or egress control.
This matters even more in environments where AI tools, browser-based work, or synced collaboration platforms can access sensitive content at speed. A user does not need to defeat encryption to leak data if they can submit it into a chat window, synchronise it to a personal device, or route it through a sanctioned SaaS channel. Guidance from NIST Cybersecurity Framework 2.0 places equal weight on protection, detection, and response, which is the correct mental model here. In practice, many security teams encounter data leakage only after a trusted endpoint session has already been used to move the data out of policy boundaries, rather than through intentional cryptographic failure.
How It Works in Practice
At rest, full-disk or file-level encryption protects data if a device is lost, stolen, or powered off. That is important, but it does not control what happens after decryption. When a user signs in, the operating system, applications, and sometimes AI agents can access plaintext in memory, render it on screen, and copy it into other systems. From that point onward, leakage is usually about permissions, workflow design, and exfiltration paths.
Security teams typically reduce this risk by combining several controls:
- Restricting who can access sensitive files, folders, repositories, and shared drives.
- Using DLP, CASB, and browser controls to inspect or block risky uploads, shares, and copy actions.
- Applying least privilege and just-in-time access so users see only what they need for the task.
- Monitoring for anomalous transfers, mass downloads, and unusual synchronisation behaviour in SIEM and XDR.
- Setting clear policy for unmanaged devices, personal cloud accounts, removable media, and messaging tools.
For AI-heavy workflows, the exposure widens because data can be embedded into prompts, retrieved through connectors, or routed into downstream tools. That is why current guidance suggests treating AI systems as data-handling endpoints, not just analytics services. The CISA insider threat guidance is relevant because many leakage events look like legitimate user activity until correlation reveals the exfiltration pattern. Encryption still protects the device, but it does not stop a permitted session from becoming a transfer channel. These controls tend to break down when sensitive data is widely accessible across cloud apps and collaboration tools because the trust boundary moves faster than policy enforcement.
Common Variations and Edge Cases
Tighter endpoint and application controls often increase user friction, support effort, and exception handling, so organisations must balance leakage reduction against operational speed. That tradeoff becomes sharper in engineering, legal, finance, and customer support teams where legitimate sharing is frequent and narrowly timed.
There is also no universal standard for this yet when AI agents are involved. If an agent can retrieve documents, summarise records, or trigger downstream actions, the key question is not whether the endpoint is encrypted, but whether the agent has bounded access, auditable behaviour, and revocable credentials. The OWASP Top 10 for Large Language Model Applications is useful here because prompt injection, insecure output handling, and excessive agency can turn a trusted tool into a leakage path. In parallel, the OWASP AI Security and Privacy Guide helps teams think about validation and data-handling boundaries beyond device encryption.
Some environments also make enforcement harder by design. Shared workstations, virtual desktops, unmanaged BYOD, and high-latency remote access can weaken clipboard control, session monitoring, or DLP inspection. In those cases, current guidance suggests focusing on conditional access, data classification, and telemetry rather than assuming the endpoint can be fully trusted. Encryption remains necessary, but it is only effective against loss of the device or offline access, not against authorised use that becomes unauthorised disclosure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Protects data at rest, but this question shows why that alone is insufficient. |
| MITRE ATT&CK | T1041 | Data exfiltration over trusted channels is the core leakage pattern here. |
| NIST AI RMF | GOVERN | AI systems handling plaintext need governance, accountability, and bounded use. |
| OWASP Agentic AI Top 10 | Agentic workflows can leak data through prompts, tools, or excessive authority. |
Use encryption for stored data, then add access and monitoring controls for active sessions.
