Why do traditional DLP and CASB controls struggle with AI risk in banking?

Why Traditional DLP and CASB Miss AI-Driven Banking Risk

Traditional DLP and CASB controls are effective when the risk is a file leaving the perimeter, a known domain, or a patterned exfiltration event. AI in banking changes the unit of risk: prompts, responses, tool calls, and agent decisions. That means the control plane must understand intent, runtime context, and workload identity, not just inspect content. NIST’s NIST AI Risk Management Framework and NIST Cyber AI Profile (IR 8596) both point toward governance that is continuous and context-aware, which is a poor fit for legacy signature-style policy.

NHIMG research shows why this matters operationally. In the LLMjacking threat pattern, compromised non-human identities let attackers move from credential abuse to AI misuse quickly, while the Top 10 NHI Issues highlights how weak NHI governance creates persistent exposure rather than one-off incidents. In practice, many security teams discover prompt abuse and agent misuse only after an automated workflow has already touched sensitive data or executed an unsafe action.

How It Works in Practice

AI risk in banking is often an identity and authorisation problem disguised as a content problem. A customer-service agent, credit-analysis copilot, or internal research bot may have access to systems that traditional DLP never sees as a single transaction. The control point needs to evaluate what the agent is trying to do, whether the request is consistent with the approved task, and whether the current credential should exist at all.

The emerging pattern is intent-based authorisation with just-in-time, ephemeral secrets. Instead of granting a long-lived API key to an AI agent, the platform issues a short-lived credential for a specific workload, scope, and time window, then revokes it on completion. This is aligned with NIST Cybersecurity Framework 2.0 principles around least privilege and continuous monitoring, and it fits the operational guidance in OWASP NHI Top 10.

• Use workload identity, not shared user credentials, for AI agents and model-connected services.
• Evaluate policy at request time using context such as task, data sensitivity, tool, and destination.
• Issue JIT credentials with short TTLs, then revoke them automatically after the task ends.
• Log tool calls, approvals, and policy decisions so review is based on behaviour, not only content.

For banking, this matters because an agent can chain actions across CRM, payments, fraud, and knowledge systems without ever producing a single suspicious file. These controls tend to break down when autonomous workflows reuse standing tokens across multiple tools, because the risk is then distributed across runtime decisions rather than concentrated in one inspected object.

Common Variations and Edge Cases

Tighter AI controls often increase friction for analysts and developers, so organisations must balance speed against containment. That tradeoff is especially visible in banking environments that use SaaS copilots, RAG pipelines, and multi-agent orchestration, where overblocking can interrupt legitimate operations while underblocking can expose regulated data.

Best practice is evolving on where to place the policy engine. Some teams enforce at the gateway, others at the tool layer, and more mature programmes do both. Current guidance suggests that static RBAC alone is insufficient for autonomous workloads, because agent behaviour is dynamic and not fully predictable at design time. That is why Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — Standards are useful reference points: they frame the need for cryptographic workload identity, short-lived secrets, and governance that survives tool chaining.

There is no universal standard for prompt-level DLP in regulated AI yet. In edge cases such as offline models, vendor-hosted copilots, or agents that trigger downstream payment or trading actions, the safer pattern is to treat the agent as a privileged workload and apply Zero Trust, JIT provisioning, and runtime approval gates. Banking teams that rely on perimeter controls alone usually learn the gap after an agent has already acted outside the original human reviewer’s intent.

Related resources from NHI Mgmt Group

• Why do traditional DLP and CASB tools fall short for AI policy compliance?
• Why do AI agents create a different access-risk profile than traditional applications?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents increase non-human identity risk in existing IAM programmes?