They were built for files, SaaS events, and known transfer patterns, not conversational payloads or agent actions. When employees paste data into chat tools or agents call APIs, the control point shifts to the interaction itself, and legacy tools often cannot see or interpret that movement.
Why Traditional DLP and CASB Miss Generative AI Risk
DLP and CASB were designed to inspect files, sanctioned SaaS events, and predictable transfer paths. Generative AI changes the control surface: the sensitive object is often a prompt, a response, or an agent action that never looks like a classic file exfiltration event. NIST’s NIST AI 600-1 Generative AI Profile makes the same point at a governance level: controls must follow the AI interaction, not only the storage system.
The problem becomes sharper when users paste regulated data into chat tools or when an agent chains tools, calls APIs, or writes to systems on its own. At that point, the issue is no longer simple data movement. It is intent, context, and execution authority. Traditional controls also struggle with model-mediated transformations, where content is summarized, rephrased, or split across multiple prompts, making keyword rules and file fingerprints unreliable. NHIMG research on DeepSeek breach shows how quickly AI systems can become data exposure events when secrets and chat records are left outside effective governance.
In practice, many security teams discover this gap only after a chatbot conversation, connector, or autonomous workflow has already moved sensitive information beyond the original control boundary.
How It Works in Practice
The practical failure is architectural. DLP and CASB usually enforce policy after data is classified and after traffic resembles a known pattern. Generative AI often does neither. A user can paste source code into a prompt, ask the model to transform it, and receive an answer that is technically new content but operationally still sensitive. An AI agent can also use a connector, retrieve records, or invoke an API under delegated authority. That behaviour is closer to CSA MAESTRO agentic AI threat modeling framework territory than classic web filtering.
-
They inspect content in transit, but prompts and completions may be streamed, compressed, or split across turns.
-
They recognise sanctioned SaaS applications, but not every model endpoint, plugin, connector, or embedded agent runtime.
-
They can block obvious uploads, but not a workflow where the agent retrieves data, reasons over it, and sends an action to another system.
-
They assume a human is the principal actor, while an autonomous agent may have its own workload identity, tool access, and execution path.
Current guidance suggests shifting from static perimeter inspection to runtime policy decisions: intent-based authorisation, JIT credential issuance, short-lived secrets, and workload identity for agents. That means evaluating what the agent is trying to do at the moment of request, not merely what the payload contains. The operational lesson is reinforced by Microsoft Azure OpenAI service breach, where the security question is not just whether data moved, but whether the AI interaction itself was governed.
These controls tend to break down in high-volume agent pipelines because the policy engine, identity layer, and telemetry stack are rarely aligned to make per-action decisions fast enough.
Common Variations and Edge Cases
Tighter inspection often increases latency, false positives, and operational overhead, so organisations must balance stronger control against developer friction and user workarounds. There is no universal standard for this yet, especially for multi-agent systems where one agent delegates to another or where a model may use MCP-based tools under changing context.
One common edge case is the “approved app, unapproved behaviour” problem. A sanctioned chat tool may be allowed, but the risk appears when a user pastes secrets or when an agent reaches into systems the original user should never have touched. Another is encrypted or tokenized content: DLP may see a blob, but it cannot reliably infer whether that blob contains a credential, a customer record, or a harmless summary. For that reason, control design is moving toward policy-as-code and runtime enforcement, as described in Anthropic Project Glasswing and the NIST AI 600-1 GenAI Profile.
For agentic environments, the safer pattern is to treat each tool call as a privileged action: issue ephemeral credentials, bind them to workload identity, log the intent, and revoke access immediately after task completion. OWASP-AGENTIC and OWASP-NHI guidance aligns with this direction, but best practice is still evolving. The key difference is simple: classic DLP and CASB try to observe the stream, while generative AI security must govern the actor.
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 | Agentic apps need runtime guardrails, not only content inspection. | |
| CSA MAESTRO | MAESTRO addresses threat modeling for autonomous tool-using agents. | |
| NIST AI RMF | AIRMF fits governance of unpredictable AI behaviour and accountability. |
Bind each tool call to intent, scope, and short-lived authority before execution.
