Data In Use

What Data in Use Means in Security Terms

Data in use is the live, active state of information while it is being read, transformed, analysed, or rendered by a user, application, or workload. Security becomes harder here because the data is no longer static at rest or simply traversing a network path, it is inside a running trust boundary where identity, process context, memory, and execution controls all matter at once.

This is why data in use is often treated as the most difficult confidentiality state to protect. The defensive problem is not only where the data lives, but which authorised session, runtime, or workload is allowed to touch it, and under what conditions that access can be observed, constrained, or revoked.

Why Data in Use Is Harder to Protect Than Data at Rest or in Transit

At rest, storage controls can focus on disks, object stores, or databases. In transit, encryption and channel protection can reduce exposure on the wire. Data in use is different because it must be decrypted and available to some executing context, which creates a window where memory inspection, process compromise, abuse of authorised access, or hostile runtime conditions can expose the content.

That makes data in use protection a problem of controlled computation as much as confidentiality. Techniques such as confidential computing, trusted execution environments, and homomorphic encryption are designed to narrow what the hosting environment can see, but each approach has trade-offs in performance, compatibility, operational complexity, and assurance boundaries.

Confidential AI and GPU Enclaves Guide shows how runtime isolation and attestation are used to protect active AI workloads that process sensitive data.

Homomorphic Encryption Guide explains a different model in which computation is performed on protected data without exposing it in the usual plaintext form.

Where Exposure Commonly Arises

Exposure usually appears when a live process has too much trust, too broad a privilege set, or too little isolation from the surrounding platform. A compromised application, a mis-scoped operator session, shared tenancy, weak memory protections, or poorly governed helper services can all create paths to data that should only exist transiently inside a narrow execution context.

For modern AI and analytics workloads, the risk is amplified because models, prompts, temporary caches, feature stores, and inference services may all touch the same sensitive inputs. The practical question is not just whether data was encrypted, but whether the runtime boundary that handled it was actually strong enough to keep the host, neighbouring workloads, and administrative paths from seeing it.

NIST AI Risk Management Framework is useful when active data processing occurs inside AI systems that need governance, traceability, and controlled behaviour at runtime.

NIST Privacy Framework helps frame the governance impact of live data handling, especially where classification, minimisation, and processing purpose matter.

How Organisations Reduce Risk While Data Is Active

Practitioners reduce risk by shrinking the trusted computing base, narrowing who or what can access the live workload, and validating that the runtime boundary behaves as expected. In practice that means combining isolation, attestation, least privilege, workload segmentation, and careful secret handling so the system can process data without broadly exposing it to operators or adjacent systems.

For high-value workloads, the control objective is to make access to active data conditional, explicit, and as short-lived as possible. That is especially important when live data includes customer records, credentials, model inputs, payment information, or regulated data that becomes more dangerous the moment it is decrypted for processing.

NIST SP 800-207 Zero Trust Architecture aligns well with live-data protection because it treats each access decision as a policy decision rather than a one-time network trust grant.

ISO/IEC 42001:2023 AI Management System Standard is relevant where live data is processed by AI systems and the organisation needs formal governance over how that processing is controlled.

Risk and Threat Considerations

Data in use is attractive to attackers because compromise at this stage can reveal the exact information that encryption and storage controls were meant to shield. If an adversary reaches the running process, a privileged session, or a weakly isolated enclave boundary, they may intercept plaintext, manipulate outputs, or abuse legitimate runtime access without ever needing to break the underlying storage protection.

Failure mechanism: The usual failure mode is not a broken cipher, but a broken trust boundary around the live computation, including overprivileged access, memory exposure, weak isolation, or compromised runtime control.

Impact: The result can be theft of sensitive records, model secrets, business data, or regulated content, plus secondary compromise of sessions, tokens, or downstream systems that relied on the same runtime.

Practitioner Guidance

Why practitioners should care: Data in use protection is a runtime governance problem, not just an encryption problem. Teams should decide which workloads truly need enclave-style protection, which can rely on tighter access control, and where operational complexity would outweigh the confidentiality gain.

What to watch for: Pay attention to shared hosts, broad admin access, long-lived sessions, and processing paths that expose live data to components that do not need to see it. Those are the places where “protected at rest” often fails to translate into “protected while active.”

Practitioner takeaway: Treat the live execution boundary as the real security control, because that is where policy either follows the data or loses it.

Related resources from NHI Mgmt Group

• How should security teams use data context during a ransomware incident?
• How should security teams use sensitive data discovery to reduce AI risk?
• Who is accountable when an AI agent accesses sensitive data it was not meant to use?
• What breaks when staff use consumer AI with patient data?