By NHI Mgmt Group Editorial TeamPublished 2026-05-22Domain: Agentic AI & NHIsSource: CrowdStrike

TL;DR: Runtime protection is presented as the missing layer for data security because static at-rest controls miss shadow data, third-party leakage, and live movement into SaaS or GenAI services, according to CrowdStrike. The real issue is identity and session exposure, not scan coverage alone, so governance must follow data in motion.


At a glance

What this is: This is a CrowdStrike blog analysis arguing that at-rest data protection alone cannot secure modern cloud environments because data moves through apps, SaaS, and AI services in ways static scanning misses.

Why it matters: For IAM and NHI practitioners, the key lesson is that identity and session controls must extend into runtime paths where service accounts, tokens, and AI-enabled workflows can leak data.

By the numbers:

👉 Read CrowdStrike's analysis of runtime and at-rest data protection


Context

Modern cloud data security fails when teams treat storage as the control point and ignore what happens as data moves. That gap matters for NHI governance because service accounts, API keys, tokens, and AI agents often interact with data outside the systems where static inventory and scheduled scans are strongest.

The article frames runtime protection as a way to observe data in motion across applications, SaaS services, and generative AI workflows. That is a sensible response to a common enterprise pattern: organizations usually know where data is stored, but not always where identities and sessions carry it next.


Key questions

Q: How should security teams govern data accessed by AI agents and service accounts?

A: Security teams should govern the identity session, not just the datastore. That means mapping which non-human identities can access sensitive data, restricting where they can send it, and logging downstream transfers into SaaS or GenAI tools. Runtime visibility is essential because static inventory alone cannot show how data propagates once an agent or token is active.

Q: What is the difference between at-rest protection and runtime protection?

A: At-rest protection secures data where it is stored, while runtime protection monitors data as it moves between applications, services, and users. For NHI governance, runtime protection matters more when service accounts, tokens, or agents can move sensitive content into unmanaged paths that static scans never see.

Q: Why do non-human identities increase data leakage risk?

A: Non-human identities increase leakage risk because they often have broad machine-to-machine reach, long-lived or reused credentials, and limited human review. Once access is granted, those identities can move data through pipelines, integrations, and AI services faster than traditional governance processes can inspect.

Q: When should organisations prioritize runtime controls over more scanning?

A: Organisations should prioritize runtime controls when data changes hands frequently, when AI agents or automations touch sensitive content, or when third-party handoffs are common. In those cases, the highest risk is not unscanned storage. It is uncontrolled movement by identities that already have legitimate access.


Technical breakdown

Why at-rest scanning misses NHI-driven data movement

At-rest scanning checks data where it is stored, which works for known repositories but not for dynamic workflows. Non-human identities often move data between applications, pipelines, and external services without creating a stable storage footprint. That creates shadow paths, especially when developers copy data into test environments or when AI systems pass content to third parties. The architectural problem is visibility, not just encryption. You can protect a database and still miss the session that moved the same data into an unmanaged tool.

Practical implication: security teams need visibility into the identity and session that moved the data, not only the datastore that held it.

How runtime protection changes the control point

Runtime protection monitors data as it flows, which lets controls trigger on movement rather than on periodic scan results. That matters for NHI because a token, workload identity, or agent session can carry access into GenAI services, SaaS applications, and APIs faster than a scheduled control can react. In practice, runtime controls can classify data in motion, map unexpected paths, and enforce policies when transfers happen. The design goal is continuous contextual awareness across changing trust boundaries, not after-the-fact discovery.

Practical implication: align control logic to data transfer events so policy follows the identity session in real time.

Why AI workflows intensify session and credential risk

AI-assisted workflows increase the number of short-lived, machine-mediated interactions that can expose sensitive content. Each interaction may use credentials, delegated access, or embedded tokens that are difficult to track with traditional IAM reports. When AI agents and automations handle data, the issue is not only who is authenticated, but what that identity can do with the data once access is granted. This is where runtime visibility intersects with NHI governance: the trust model must cover the full session lifecycle, including movement, reuse, and downstream propagation.

Practical implication: review session scope and downstream data-sharing paths for every automated workflow that touches sensitive information.


Threat narrative

Attacker objective: The attacker or internal risk path aims to move sensitive data beyond managed boundaries where detection, audit, and containment are weaker.

  1. Entry occurs when a service account, API key, or developer session accesses data in a managed application and then passes it into an unmanaged SaaS or GenAI workflow.
  2. Escalation follows when the same identity or token is reused across multiple systems, extending access beyond the original storage boundary.
  3. Impact occurs when sensitive data leaks through a third party, a testing copy, or an AI service that was not included in the original data control plan.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Runtime data security is now an identity problem, not only a storage problem. Once data leaves a known repository, the deciding factor becomes which NHI, token, or session moved it and where that access can propagate. Static scans can still serve compliance, but they do not define the operative risk model for agentic and automated environments. Practitioners should treat runtime visibility as a first-class identity control.

Ephemeral access does not remove exposure if the session can still spread data. The post’s logic is sound on one point: short-lived credentials reduce dwell time, but they do not prevent leakage through delegated workflows, third-party services, or AI tools. That means JIT access must be paired with destination control and content awareness. Otherwise, the blast radius simply moves downstream.

Data security posture management must now include NHI session governance. The old model stopped at what is stored and where it resides. The newer model has to account for which non-human identities touched the data, what transformations happened in transit, and whether the path remained within policy. Organisations that skip this layer will keep finding gaps after the fact, so practitioners should map controls to runtime behaviour.

Runtime protection is becoming the practical bridge between DSPM and NHI governance. DSPM alone identifies sensitive content, but NHI governance explains how automated identities can move that content into risky paths. The combined control story is what security leaders should operationalise next. Teams should plan for policies that bind identity, session, and data movement into one reviewable control plane.

From our research:

What this signals

Ephemeral credential trust debt: teams keep adopting short-lived access models without fully accounting for how much downstream data movement those sessions can still authorize. When AI systems already receive more access than human employees in 70% of organisations, per the 2026 Infrastructure Identity Survey, the governance problem is structural, not cosmetic.

Enterprises should expect runtime data controls to become part of the NHI control stack, especially where AI agents, delegated tokens, and third-party handoffs intersect. The programme implication is clear: review who can move data, not just who can see it, and align that work with the NHI Lifecycle Management Guide.

Security leaders should also treat data movement as a Zero Trust question, because trust decisions now happen inside sessions rather than only at login. The practical next step is to anchor policy to identity, destination, and content state, then map that approach to the NIST Cybersecurity Framework 2.0.


For practitioners

  • Implement runtime visibility for sensitive data paths Track how service accounts, API keys, and automated workflows move sensitive data into SaaS, GenAI, and third-party services. Use that telemetry to replace purely periodic scan-based assumptions with live path review.
  • Review NHI session scope before data egress Map which non-human identities can read, transform, forward, or copy sensitive content, then constrain those permissions to the minimum needed for each workflow. Focus on session lifetime, destination systems, and reuse across environments.
  • Link DSPM findings to identity ownership Assign each sensitive-data flow to a named system owner and identity owner so remediation is not limited to storage fixes. This makes it easier to close gaps caused by hidden service accounts or unmanaged tokens.
  • Add controls for third-party and GenAI handoffs Require policy checks before sensitive content is sent to external tools, especially where machine identities operate with delegated access. Include rules for content classification, destination approval, and alerting on unexpected transfers.

Key takeaways

  • At-rest controls alone do not govern modern data risk when non-human identities and AI workflows can move sensitive content into unmanaged destinations.
  • The scale problem is already visible, with breach costs, containment delays, and repeated incidents showing that delayed discovery remains a material security weakness.
  • Security teams should shift from scan-only thinking to runtime identity governance that tracks who moved data, where it went, and whether the path stayed within policy.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Runtime exposure grows when NHI credentials are long-lived or reused.
NIST CSF 2.0PR.AC-4Least-privilege access is central when agents move data across services.
NIST Zero Trust (SP 800-207)PR.AC-5Continuous verification is needed when identities carry data across trust boundaries.

Apply zero trust to NHI sessions so each transfer is re-evaluated before data leaves a boundary.


Key terms

  • Runtime Protection: Runtime protection is the practice of monitoring and enforcing policy while data is actively moving between systems. It is more than a scan or a storage check. For NHI governance, it matters because automated identities can carry sensitive data into services that static controls never fully observe.
  • Non-Human Identity: A non-human identity is any machine, workload, service account, token, certificate, bot, or AI agent that authenticates to systems. These identities often outnumber human users and can have broader, less visible access paths, which makes their lifecycle and session behaviour a core governance concern.
  • Data Egress: Data egress is the movement of information out of a controlled environment to another system, service, or destination. In practice, it is where many identity and data risks converge, because the identity allowed to export the data can be different from the identity that originally stored it.
  • Shadow Data: Shadow data is sensitive information that exists outside the places security teams expect to find it. It often appears in testing copies, ad hoc exports, SaaS tools, or AI workflows, which makes it hard to govern with inventory-based controls alone.

Deepen your knowledge

Runtime data protection and NHI session governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents and service accounts that move sensitive data, it is worth exploring.

This post draws on content published by CrowdStrike: Demystifying Data Protection in the Cloud: Runtime vs. at Rest. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org