Who should own DLP decisions when data, identity, and AI workflows overlap?

Why This Matters for Security Teams

DLP ownership becomes contentious when the same data flow is touched by storage teams, identity engineers, and AI workflow owners. Traditional DLP programs are usually scoped around locations and channels, but overlapping AI pipelines change the exposure path: data is copied into prompts, embeddings, logs, caches, and tool outputs, often outside the original control plane. NIST Cybersecurity Framework 2.0 is useful here because it treats governance and detection as shared security outcomes, not just point controls.

That matters even more when secrets and NHIs are in play. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, a pattern documented in the Ultimate Guide to NHIs and related breach analysis in 52 NHI Breaches Analysis. In practice, many security teams encounter the DLP problem only after an AI workflow has already copied sensitive data into an unmanaged path, rather than through intentional design.

How It Works in Practice

The practical answer is not a single owner for every decision, but a single decision model with multiple accountable owners. Data security should define what content classes are protected and where inspection is mandatory. IAM and NHI governance should define which identities, service accounts, and agents are allowed to request, transform, or exfiltrate that content. AI workflow owners should define where prompts, outputs, and tool calls create new leakage surfaces.

For agentic and automated workflows, static DLP rules are rarely sufficient. AI agents can chain tools, move laterally, and reshape the data path at runtime, so access decisions need to be evaluated in context. That usually means policy-as-code, runtime authorization, and short-lived credentials rather than broad standing access. Current guidance suggests pairing DLP with workload identity, because the system needs to know not only what data is leaving, but what agent, service, or model path is trying to move it and whether that action is expected.

• Classify data once, then enforce inspection across storage, API, prompt, and egress paths.
• Bind agent actions to workload identity so the DLP decision can include who or what is acting.
• Use JIT access and short TTL secrets so a compromised workflow has less time to misuse data.
• Log prompt, tool, and export events together so investigations can reconstruct the full movement path.

For implementation guidance, the NIST AI Risk Management Framework helps organisations govern model-driven data movement, while the NIST Cybersecurity Framework 2.0 supports shared accountability across protect and detect functions. NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results is especially relevant where API keys, service accounts, and agent identities are the real route to data movement. These controls tend to break down when AI systems write to third-party tools that bypass enterprise inspection points because the data leaves the governed path before DLP can evaluate it.

Common Variations and Edge Cases

Tighter DLP often increases operational friction, requiring organisations to balance stronger data control against developer speed, model usability, and investigation overhead. That tradeoff is most visible in environments with shared AI services, outsourced data processing, or multiple business units using different classifiers.

There is no universal standard for this yet, but current guidance suggests three common patterns. First, some organisations centralise the policy engine while allowing local teams to own enforcement. Second, others place ownership with the data security team but require IAM and NHI sign-off for any workflow that can move regulated data. Third, mature teams treat AI agents as first-class workloads and give them explicit governance under the same control model used for service accounts.

The edge cases are usually the hardest. Encrypted data that is decrypted only inside a workflow, high-volume retrieval augmented generation systems, and cross-border SaaS integrations can all defeat simplistic DLP scoping. In those cases, ownership should shift from “who owns the tool” to “who can approve the runtime path.” That usually means the security decision is shared, but the execution authority sits with the team closest to the workflow that creates the exposure.

Related resources from NHI Mgmt Group

• Who should own Zero Trust policy decisions in a mature identity programme?
• What do identity teams get wrong about data governance in AI platforms?
• Who should own governance for workload identity in AI systems?
• Why is it important to integrate identity and data governance?