AI-enabled data protection still leaves identity and session risk

At a glance

What this is: This is an analysis of why traditional data protection controls break down when organizations need to monitor and enforce policy across modern, distributed environments.

Why it matters: It matters because IAM and NHI teams increasingly need identity-aware controls that can see session context, not just inspect files or endpoints.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read CrowdStrike's analysis of how to protect identities and sessions from infostealers

Context

Data protection fails when security teams treat files as the only object worth controlling. In practice, the governance gap sits in the identity and session layer, where human users, service accounts, API-driven workflows, and AI-enabled actions can all move data across SaaS, cloud, and hybrid environments.

The article frames a familiar enterprise problem: legacy controls create too much operational noise, too many blind spots, and too much manual tuning to keep pace with modern data movement. For NHI governance, that means the question is not only where sensitive data lives, but which identities and sessions can touch it, copy it, or exfiltrate it without a reliable control point.

Key questions

Q: How should security teams handle data protection for non-human identities?

A: Security teams should treat non-human identities as active data movers, not just backend accounts. That means mapping which automations, integrations, and agentic workflows can access sensitive information, then enforcing policy based on identity, session risk, and destination. Controls must also preserve evidence so investigators can prove what moved and who or what moved it.

Q: What is the difference between content inspection and identity-aware data protection?

A: Content inspection looks at the file or payload itself, while identity-aware data protection also evaluates who initiated the action, from what context, and under which privileges. The second approach is more useful in SaaS and cloud environments because the same content can be safe or risky depending on the session and actor involved.

Q: When do DLP tools create more risk than they reduce?

A: DLP tools create more risk when they generate so many false positives that teams move to monitor-only mode or build brittle exception lists. At that point, the policy exists on paper but not in practice, and sensitive data can move without meaningful control or reliable evidence for response.

Q: How can organisations support forensic investigation of suspected data exfiltration?

A: Organisations should retain evidence of the suspected action, including hashes or preserved copies where appropriate, along with timestamps and the identity context behind the event. That gives legal, HR, and security teams a defensible chain of custody and avoids depending on a user device that may already have been altered.

Technical breakdown

Why legacy data loss prevention breaks in distributed identity environments

Traditional data loss prevention focuses on content inspection and static policy rules. That model works poorly when data moves through managed and unmanaged applications, because the control point often lacks context about the identity, session, device state, and business workflow involved. In practice, the same file may be legitimate in one context and risky in another, which drives false positives and rule sprawl. The more fragmented the environment, the harder it becomes to maintain a consistent policy baseline across endpoints, SaaS, and cloud workloads.

Practical implication: Practitioners should evaluate whether their controls can follow data across identities and sessions, not just scan content at rest.

Why identity context changes the meaning of data movement

Identity context tells defenders who initiated the action, under what privileges, and through which workflow. In NHI-heavy environments, that extends beyond employees to service accounts, bots, integrations, and agentic processes that can transfer data without a traditional interactive login. When controls ignore that context, they cannot distinguish between sanctioned automation and unauthorized movement. That is why session-aware policy enforcement matters: it ties data handling to the current trust state, not to a one-time approval or a static label.

Practical implication: Security teams should connect DLP policy to identity posture and session risk before relying on enforcement at scale.

How forensic evidence supports response and auditability

Data forensics in this context means preserving evidence of what was moved, when, and by which actor, so investigators can verify integrity after a suspected egress event. That matters because exfiltration is often a chain of small actions, such as copy, paste, rename, sync, or transfer into a generative AI tool. Without retained evidence and chain of custody, teams can neither validate the event nor support legal, HR, or compliance workflows. This is especially relevant where non-human identities can perform high-volume actions quickly.

Practical implication: Teams should require evidence retention and chain-of-custody capabilities for any control that claims to support incident response.

Threat narrative

Attacker objective: The attacker wants to move sensitive data out of controlled environments while minimizing detection and preserving access to useful evidence only for themselves.

1. Entry occurs when a compromised identity or session is used to access data from a managed application or endpoint.
2. Escalation happens when the actor copies, syncs, or pastes sensitive content into another workspace or generative AI tool without detection.
3. Impact is achieved when sensitive data leaves the trusted boundary and the organization loses visibility into where it was sent or retained.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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

NHI Mgmt Group analysis

Identity-aware data protection is the control gap that most enterprises still understate. File-centric controls can detect some leakage, but they do not explain why the movement happened or whether the actor still deserves trust. As environments add service accounts, workflow automation, and AI agents, the policy must follow the identity session rather than the document alone. The practitioner conclusion is clear: enforce against the actor, not just the artifact.

Session risk matters more than static access grants when data moves across SaaS and cloud. A credential that looked acceptable at login may no longer be trustworthy when the user, workload, or agent starts copying data into another destination. That is why modern controls need to consider live context such as device state, application boundary, and current privilege depth. Teams that ignore session state will keep over-blocking legitimate work while missing high-confidence leakage.

For NHI governance, data protection and secrets protection are converging. The same operational weaknesses that let leaked credentials persist also let data move without meaningful oversight, especially when automation masks the human initiator. This creates a shared governance problem across access review, rotation, monitoring, and response. The practitioner conclusion is to manage secrets, sessions, and data flows as one control plane.

Operational noise is not a side effect, it is a governance signal. When teams accept broken scripts, false positives, and monitor-only mode as normal, they are telling the business that the policy model does not fit how work actually happens. That condition is especially risky for NHI-heavy workflows, where machine identities can generate high-volume activity faster than analysts can triage. The practitioner conclusion is to simplify policy before scaling enforcement.

Data forensics should be treated as part of identity incident response, not a separate logging feature. Once an identity or session is suspected of moving sensitive data, investigators need evidence that can withstand audit and legal review. That means retention, integrity, and traceability have to be designed into the control, not bolted on later. The practitioner conclusion is to require evidentiary depth wherever data movement can trigger response.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why policy and practice keep diverging.
• That operational gap is why teams should pair rotation, monitoring, and access review with the broader guidance in Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Identity-aware data protection is becoming part of the NHI control plane, not a separate data loss problem. As automation and AI systems touch more sensitive data, the question shifts from whether a file is protected to whether the actor still deserves the privilege to move it. With 27 days to remediate a leaked secret still the average, organisations cannot rely on post-event cleanup to compensate for weak session governance.

Ephemeral trust decisions are now the practical boundary for enforcement. Static access grants are too blunt when sessions change state faster than humans can review them, especially in SaaS and hybrid workflows. Practitioners should align policy with live identity posture and use external guidance such as the NIST Cybersecurity Framework 2.0 to structure detect and respond responsibilities.

Identity blast radius: the real control problem is how far one compromised session can move data before the organisation notices. That means NHI governance, secrets hygiene, and response evidence need to be planned together, not as disconnected workstreams. For teams building out controls, the next step is to map where a single credential or automation path can cross application boundaries before policy catches up.

For practitioners

• Map data movement to identity and session context Inventory which users, service accounts, and automation flows can move sensitive data across managed and unmanaged applications. Use that map to determine where content inspection is insufficient and where session risk should influence policy decisions.
• Reduce policy sprawl before broad enforcement Consolidate overlapping DLP rules, remove brittle exceptions, and test enforcement in simulation mode before turning on blocking. This lowers false positives and makes it easier to defend the policy model to business owners.
• Tie exfiltration response to evidence retention Require retained copies or hashes of suspected exfiltration artifacts so investigators can confirm integrity, reconstruct the event, and support legal or HR workflows without relying on user devices after the fact.
• Review non-human access paths that can move data Include service accounts, integrations, and AI-enabled workflows in access reviews when they can copy, paste, sync, or export sensitive data. Treat those paths as part of the same control environment as human sessions.

Key takeaways

• Legacy data protection fails when it cannot see identity and session context across SaaS, cloud, and hybrid workflows.
• Secret remediation still takes 27 days on average, which shows why post-event cleanup cannot compensate for weak preventive controls.
• Practitioners should unify data movement controls, secrets governance, and forensic readiness into one NHI-aware operating model.

Key terms

• Identity-aware data protection: A control approach that evaluates who is moving data, from where, and under what privileges before allowing or blocking the action. It extends beyond content inspection by tying enforcement to identity, session state, and destination context, which is essential in SaaS, cloud, and automation-heavy environments.
• Session risk: The changing level of trust assigned to an active login or token after it has been issued. Session risk reflects device state, application context, privilege depth, and behavior, so a session that began legitimately can become unsafe before it ends.
• Chain of custody: A documented record that preserves the integrity of evidence from the moment an event is detected through investigation and response. In identity and data protection workflows, it helps prove what happened, when it happened, and which actor or session was involved.
• Non-human identity: A service account, API key, token, certificate, workload identity, bot, or AI agent that can authenticate and act inside an environment. These identities often move faster and at greater scale than human users, which makes their permissions, sessions, and evidence trails critical governance concerns.

Deepen your knowledge

Identity-aware data protection and secrets governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for service accounts, automation, and AI-enabled workflows, it is worth exploring.

This post draws on content published by CrowdStrike: How to Protect Identities and Sessions from Infostealers. Read the original.