How do organisations reduce exposure for data in use?

Why This Matters for Security Teams

Data in use is the hardest stage of the data lifecycle to harden because the application must decrypt it to process it. That creates a narrow but high-value attack window for workloads, service accounts, and agents that can read memory, invoke APIs, or chain privileged actions. Static encryption helps at rest and in transit, but it does little once a trusted runtime can access plaintext.

The practical risk is not only theft of a single record. It is the exposure created when excessive privileges, long-lived secrets, and weak runtime isolation let more workloads decrypt more data than necessary. NHIMG research shows that 97% of NHIs carry excessive privileges, which is why exposure during processing often reflects identity design failures rather than encryption failure. See the Ultimate Guide to NHIs — Key Research and Survey Results for the broader pattern.

For teams adopting zero trust, this shifts the question from "Is the data encrypted?" to "Who and what can decrypt it, for how long, and under what runtime conditions?" Current guidance from NIST Zero Trust Architecture and the Anthropic report on AI-orchestrated cyber espionage both reinforce that runtime access control matters more when software behaves dynamically. In practice, many security teams discover data-in-use exposure only after a privileged workload has already reused access that was never meant to persist.

How It Works in Practice

Reducing exposure for data in use means constraining decryption to the smallest possible set of trusted runtimes and then making that access temporary, observable, and revocable. In operational terms, this usually combines workload identity, just-in-time credential issuance, policy-based authorization, and strong runtime isolation. The goal is not to eliminate plaintext. It is to ensure plaintext exists only where it is needed, only while it is needed, and only for an approved task.

A practical control stack often looks like this:

• Use workload identity, not shared secrets, so the service proves what it is before receiving access. Standards such as SPIFFE help anchor identity to the workload itself.
• Issue short-lived access tokens or session credentials per task, then revoke them automatically when the task ends.
• Evaluate access at request time with policy-as-code so the decision can reflect data sensitivity, workload posture, and request context.
• Log every decrypt and re-encrypt event, including which identity requested it and which dataset was touched.
• Prefer memory-safe and compartmentalized execution paths, such as enclaves, process isolation, or tightly scoped service boundaries, where the environment supports them.

This is where NHI governance becomes a runtime control problem, not just a secrets inventory problem. NHIMG’s Guide to the Secret Sprawl Challenge shows why long-lived credentials spread faster than teams can audit them, which is especially dangerous when data must be decrypted in motion or in memory. Best practice is evolving toward ephemeral access and per-request authorization rather than standing permissions.

These controls tend to break down in legacy environments where monolithic applications, shared service accounts, and broad network trust make it impossible to isolate decryption to a single workload or transaction.

Common Variations and Edge Cases

Tighter runtime controls often increase operational overhead, requiring organisations to balance reduced exposure against delivery speed and system complexity. That tradeoff is especially visible when databases, analytics pipelines, and agentic workloads all need controlled access to the same sensitive dataset.

There is no universal standard for this yet. Some environments can use confidential computing or enclave-based processing for stronger isolation, while others rely on tokenization, field-level masking, or proxy-based access mediation. The right pattern depends on whether the exposure risk comes from operators, applications, or autonomous agents that can chain tools unpredictably.

For AI agents and other autonomous workloads, static RBAC is rarely enough because the access path changes with each task. Runtime policy should evaluate intent, context, and data sensitivity, not just role membership. That is why current guidance from CISA Zero Trust guidance and NIST AI Risk Management Framework increasingly points to context-aware decisions and continuous verification. Where legacy systems cannot support that model, organisations should narrow the blast radius by segmenting data, reducing decryption scope, and limiting which services can ever see plaintext.

Even then, edge cases remain: batch jobs that need large data sets, third-party processors with contractual access, and high-throughput systems where logging every decrypt can affect latency. In those cases, the control objective is still the same. Make exposure temporary, attributable, and auditable, then assume any broader access path will eventually be abused.

Related resources from NHI Mgmt Group

• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• How can organisations reduce data exposure in AI tools?
• How can organisations reduce AI-driven data exposure in M365?