Runtime data protection for AI agents closes the identity gap

At a glance

What this is: This is a CrowdStrike analysis of why runtime data protection is needed for AI agents when at-rest controls miss shadow data, third-party leakage and live data movement.

Why it matters: It matters because IAM and data security teams need controls that govern how AI agents and sessions move data in real time, not just where data sits.

By the numbers:

• The average cost of a data breach in 2023 was $4.45 million USD, up from $4.24 million in 2022.
• Organizations took an average of 287 days to identify and contain a breach.
• 83% experienced more than one breach in 2023.

Context

AI agents and runtime data protection are connected because data security fails when teams only classify what is already stored, not what is being moved, copied, or shared during a live session. In practice, that leaves shadow data, third-party leakage and generative AI service exposure outside the scope of static scanning.

For identity programmes, the governance problem is not just data location but the runtime relationships that allow a session, workload or agent to move data beyond its intended boundary. That means control design has to account for access path, execution context and data handoff, not only repository-level policy.

Key questions

Q: How should security teams govern personal data used by AI agents?

A: Security teams should govern agent access as a runtime control problem, not as a one-time permission decision. Limit the data each agent can reach, bind access to a specific task, and monitor actual behaviour continuously. That approach makes privacy records and IAM controls reflect the same operational reality.

Q: Why do at-rest controls fail to protect shadow data?

A: At-rest controls only see what is already in known storage locations, so they miss copies created in testing, application processing or handoff to other services. Shadow data becomes a governance problem when those copies escape the managed perimeter and keep moving. Runtime visibility is needed because the risk appears during use, not after storage.

Q: What signs show that data security is missing runtime coverage?

A: A common sign is that teams can inventory stored data but cannot explain where sensitive data went after an application, agent or user session forwarded it. Another sign is repeated reliance on periodic scans to find exposure after the fact. If policy only works when data is still in its original store, runtime coverage is incomplete.

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.

Technical breakdown

Why at-rest scanning misses AI agent data movement

At-rest scanning looks at known repositories, so it only sees data that is already catalogued in a bounded location. AI agents and modern workloads create a different pattern: data can be pulled from one system, transformed in memory, and passed to SaaS tools or GenAI services without ever becoming visible in a scheduled scan. The control gap is temporal as much as architectural. A snapshot can prove where data existed at a point in time, but it cannot show where that data flowed during execution. That is why runtime data protection is a separate control layer, not just a better scanner.

Practical implication: teams should assess whether their discovery model can see data in motion, not only data at rest.

How runtime protection changes identity and session governance

Runtime protection ties policy to live movement, which means enforcement follows the session rather than the storage layer. That matters for AI agents because the risky event is often not possession of data, but the authorised path that lets a session forward data into another environment. In identity terms, the unit of control shifts from a static entitlement to an active exchange: who or what is acting, under which session, and toward which external service. This is closer to continuous authorisation than periodic review, and it aligns better with ephemeral AI workflows than with repository-centric governance.

Practical implication: extend policy checks to live sessions and outbound data paths, especially where AI agents can invoke external services.

Why shadow data becomes a governance problem, not just a discovery problem

Shadow data is not only an inventory issue. It becomes a governance problem when unapproved copies, developer test sets or application exports escape the managed perimeter and are then reused by another system or third party. Traditional controls often assume the asset list is stable, but runtime environments constantly generate new data states through copying, transformation and handoff. That means the control objective is not merely classification, but ongoing context preservation: knowing what the data is, where it came from, and whether the next destination is still authorised.

Practical implication: pair discovery with runtime classification so unapproved copies are governed at the moment they are used.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime data protection is now an identity governance problem, not a storage problem. The article’s core point is that static protection models only govern managed repositories, while AI agents and modern services move data through live sessions and third-party destinations. That makes the decisive control question about who or what is allowed to move data, under what runtime context, and to which service. Practitioners should treat data movement as an identity event, not only a data event.

Shadow data creates trust debt when governance assumes repositories are the full system of record. Once copies, developer datasets or application exports leave the controlled perimeter, the old inventory model breaks down. The article shows that classification without runtime context is incomplete because the same data can be benign at rest and risky in motion. The implication is that data security programmes must measure whether they can still govern information after it leaves the original store.

AI agent workflows amplify the gap because the session, not the file, becomes the unit of risk. An AI agent may not be autonomous in the strict governance sense, but it can still trigger data transfer paths that static controls never see. That means access and data policy need to meet at execution time, especially where external services, SaaS tools and generative AI prompts become part of the workflow. Practitioners should reframe agent oversight around live data paths.

Identity and data controls are converging into one runtime boundary. The article reinforces a broader market shift: the boundary that matters is no longer the database or the endpoint alone, but the chain of identity, session and destination that carries the data. That aligns with NIST CSF thinking on access control and protected data flows, but the practical reality is narrower and more urgent. Teams should design for runtime containment, not post hoc inspection.

Runtime protection is the named concept that matters here because it closes the gap between authorised access and authorised movement. That distinction is what static models miss. If a session can legally access data but still legally exfiltrate it into an ungoverned SaaS or GenAI service, then the control plane has lost sight of the actual risk. Practitioners should anchor policy to movement events, not only to asset state.

What this signals

Runtime data protection is the missing control plane for AI-enabled workflows. When data can move from a managed repository into SaaS or generative AI services in the middle of execution, repository-level assurance no longer describes the real exposure. Practitioners should expect runtime inspection and enforcement to become the baseline requirement for any programme that allows AI-mediated data movement.

Shadow data becomes persistent risk when governance cannot follow the copy. The operational issue is not only discovery, but continuity of policy across copies, exports and temporary datasets. Identity and data teams should plan for a world where the control has to travel with the information, especially when developer workflows and AI sessions create new data paths faster than catalogues can update.

For practitioners

• Map data movement paths for AI-enabled workflows Identify where AI agents, applications and users can move sensitive data into SaaS, GenAI services and third-party tools. Document the approval points, destination systems and data classes that are currently outside repository-based controls.
• Extend policy enforcement to runtime sessions Use controls that evaluate data transfers as they occur, so policy decisions follow the active session rather than the stored object. This is essential where the same data can be safe at rest but unsafe once forwarded.
• Close shadow data blind spots Treat unmanaged copies, developer datasets and application exports as governed assets the moment they appear. Classification should travel with the data so unapproved reuse is visible even after the original repository is bypassed.
• Separate repository assurance from runtime assurance Use at-rest scanning for baseline inventory, but do not treat it as evidence of live protection. Validate that your runtime layer can detect and block unexpected data paths that periodic scans will miss.

Key takeaways

• Static data protection is not enough when AI agents and modern services can move sensitive information outside the managed perimeter during execution.
• The article’s core warning is that the real blind spot is runtime movement, not the storage layer, and that blind spot leaves shadow data and third-party leakage outside control.
• Practitioners should align identity, session and data policies so enforcement can follow live transfers into SaaS and GenAI services.

Key terms

• Runtime data protection: Runtime data protection is the practice of classifying, controlling, and, when necessary, stopping sensitive data while it is actively moving through a system. For AI workflows, that means enforcement must happen during prompts, tool calls, uploads, and downloads, not only in retrospective logs.
• 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.
• Data-in-Motion: Data-in-motion is sensitive information while it is being transferred between systems, identities, or applications. For SaaS and AI programmes, the main concern is not only where data is stored, but which identities can move it, transform it, or expose it during transit.
• Persistent Session: A persistent session keeps a user signed in for an extended period after initial authentication. It reduces repeat login friction, but it also increases the window in which a stolen token or compromised browser session can be reused. Security teams must balance convenience against the higher blast radius of session theft.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.