Subscribe to the Non-Human & AI Identity Journal

Why do existing IAM and DLP controls fall short for AI usage?

Existing IAM and DLP controls often assume the risky action can be reviewed after the fact, but AI exposure happens during the session. If the control cannot inspect prompts, uploads, and responses in real time, it cannot stop disclosure before the data leaves the environment.

Why This Matters for Security Teams

Existing IAM and DLP controls were built around users, devices, and files that can be classified before access is granted. AI usage breaks that model because prompts, retrieved context, generated outputs, and tool calls happen in a single live interaction. Once a model can summarize, transform, or transmit sensitive content, after-the-fact review is too late to prevent exposure. That is why current guidance increasingly points to runtime inspection and policy enforcement rather than static gatekeeping, as reflected in NIST’s NIST SP 800-63 Digital Identity Guidelines and NHI research on standards for non-human identities.

The practical failure is not that IAM and DLP are irrelevant. It is that they assume stable subjects and predictable data paths. AI agents and copilots can ingest code, tickets, secrets, and customer data in one session, then repackage that material in another tool without a human noticing. In practice, many security teams encounter this only after a sensitive prompt, upload, or response has already left the environment.

How It Works in Practice

Security teams need to move from coarse identity checks to session-level control. For AI usage, that usually means combining identity, context, and content inspection at the point where the model is asked to act. The control decision should consider who initiated the request, what data is being supplied, which model or agent is being used, and whether the action matches an approved business purpose.

That is why static RBAC alone is insufficient. A user may be allowed to access a system, but not to paste source code into an external model or upload regulated records into a public chat interface. Better practice is emerging around intent-aware policy, short-lived credentials, and real-time filtering of prompts and outputs. In NHI terms, the same principles apply to workload identities: the identity must be cryptographically bound to the workload, not just to a human proxy. NIST’s Zero Trust Architecture reinforces this direction by requiring continuous verification rather than trust based on network location.

Operationally, that often looks like:

  • Inspecting prompts before they reach the model, including attached files and copied context.
  • Classifying responses for sensitive content before they can be shared downstream.
  • Issuing short-lived access tokens for model or tool use instead of long-lived secrets.
  • Logging agent actions with enough context to reconstruct what was asked, what data was used, and what was returned.

NHIMG research has repeatedly shown that organisations struggle to manage non-human access consistently, and the same fragmentation shows up in AI control stacks. The risk increases when teams bolt AI onto existing IAM and DLP tooling without adapting policy evaluation to the live session, as seen in NHIMG coverage of Azure Key Vault privilege escalation exposure.

These controls tend to break down in environments where users can move data from governed systems into unmanaged browser-based AI tools because the inspection point no longer sits between the data and the model.

Common Variations and Edge Cases

Tighter AI controls often increase friction for developers, analysts, and operations teams, so organisations have to balance leakage prevention against workflow speed. That tradeoff is especially visible when a business wants to use external models, internal models, and agentic automation under one policy set. There is no universal standard for this yet, so current guidance suggests aligning controls to the sensitivity of the task rather than treating all AI usage the same.

One common edge case is approved internal AI use that still relies on external connectors, plugins, or retrieval layers. Even if the chat interface is internal, the model may call out to services that were never covered by legacy DLP rules. Another is the use of summaries or embeddings, which can leak sensitive patterns even when the original document never leaves the boundary. Teams should also watch for copy-paste paths, browser extensions, and sanctioned shadow AI, because those channels often bypass the enterprise control plane entirely.

For that reason, current best practice is to pair identity controls with content-aware policy enforcement and data minimisation. NHIMG’s DeepSeek breach analysis shows how quickly trust can collapse when model interaction paths are not governed with the same rigour as traditional access paths. The practical answer is not to ban AI outright, but to define where AI can see data, what it can return, and when human approval is required.

Standards & Framework Alignment

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

OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 LLM-01 AI session controls must stop prompt and output leakage in real time.
CSA MAESTRO Covers runtime governance for agentic and model-driven workflows.
NIST AI RMF Requires ongoing risk management for generative AI misuse and leakage.

Add prompt, retrieval, and output policy checks before any model or agent action completes.