Why do traditional IAM and DLP controls fall short for GenAI?

Why This Matters for Security Teams

Traditional IAM and DLP were built around stable users, fixed entitlements, and detection after data has moved. GenAI breaks that model because the risky moment is often the prompt, the retrieved context, or the model output that gets reused downstream. That means access decisions need to account for intent, sensitivity, and the current workflow state, not just who logged in. NIST’s NIST AI 600-1 GenAI Profile reflects this shift by treating AI risk as a governance and lifecycle issue, not only a perimeter problem.

The gap is visible in real incidents. NHIMG’s DeepSeek breach coverage shows how exposed secrets and sensitive records can become operationally inseparable from the system that produced or stored them. Once prompts, connectors, and outputs are all part of the attack surface, legacy controls that only see identities and file movement miss the actual risk path. In practice, many security teams encounter GenAI misuse only after sensitive output has already been copied into a business process, rather than through intentional usage control.

How It Works in Practice

GenAI governance works best when it shifts from static allow or deny rules to usage-layer controls that inspect the request in context. That usually means combining identity, policy, and data controls at the point of prompt, tool call, retrieval, or export. A conventional DLP rule may still be useful, but it is not enough when the risk is generated dynamically by the model, the connected knowledge source, or the user’s follow-on action.

Practitioners typically need three layers:

• Identity and session binding so the system knows which human, workload, or agent is acting.
• Policy evaluation at request time so decisions reflect the prompt, tool, dataset, and destination.
• Content handling rules for redaction, masking, logging, and output restrictions where the model could expose regulated data.

This is where zero trust principles matter. NIST SP 800-63 Digital Identity Guidelines help anchor authentication assurance, but GenAI also requires runtime authorization because authentication alone does not explain what the session is trying to do. In parallel, NHIMG’s Azure Key Vault privilege escalation exposure coverage illustrates how access paths can expand through overly broad privileges and mis-scoped secrets. Current guidance suggests pairing IAM with policy-as-code checks, short-lived credentials, and connector-level restrictions so the model cannot freely reuse sensitive context outside approved workflows.

These controls tend to break down in high-volume enterprise deployments where multiple copilots, plugins, and data sources are chained together because the context changes faster than static policy reviews can keep up.

Common Variations and Edge Cases

Tighter usage controls often increase operational friction, requiring organisations to balance developer speed against stronger oversight. That tradeoff is especially visible in environments that rely on internal copilots, customer-facing chatbots, or agentic workflows that call multiple systems in sequence. There is no universal standard for this yet, so best practice is evolving.

Some teams overcorrect by treating every GenAI interaction as a high-risk event. That approach can create alert fatigue and push users toward shadow AI tools. A better pattern is risk-tiered control: stricter review for regulated data, production secrets, and external sharing, with lighter controls for low-sensitivity drafting or summarisation. NHIMG’s Ultimate Guide to NHIs — Standards is useful here because it frames NHI governance as an operational control problem, not just an inventory exercise.

Edge cases also matter. DLP may still catch obvious exfiltration, but it struggles when the model paraphrases sensitive content, when data is embedded in prompts rather than files, or when the output becomes sensitive only after downstream recombination. In those cases, organisations should supplement DLP with contextual policy checks and usage telemetry, rather than assuming post-event inspection will be enough.

Related resources from NHI Mgmt Group

• Why do traditional IAM controls fall short in multi-ERP environments?
• Why do traditional IAM controls fall short for SaaS data security?
• Why do traditional DSPM tools fall short for AI workloads?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?