DLP Isn't Just Blocking Credit Card Numbers Anymore

Remember the old days of data loss prevention (DLP)? Regex patterns scanning every email and file transfer for anything that looked like a credit card number or Social Security number. Sixteen digits in a row? Blocked. Nine digits with dashes? Blocked. A phone number that happened to match a pattern? Also blocked. Your chief financial officer (CFO) sending a legitimate financial report to the board? Believe it or not, blocked.

Old-school DLP was a blunt instrument. It caught some real incidents, generated mountains of false positives and made everyone, security teams included, miserable. Most users learned to work around it, which defeated the entire purpose.

But DLP has grown up. And if your approach to data protection is still stuck in the regex era, you're solving yesterday's problem while today's data walks out the door through channels you're not even watching.

Why old-school DLP earned its bad reputation

It's worth understanding why traditional DLP failed so spectacularly, because the lessons inform what actually works now.

Pattern matching without context is a losing game. A credit card number in a finance team's quarterly report is not the same as a credit card number being uploaded to a personal file-sharing account. But old DLP treated them identically. Every match got the same response: block it, log it, send an alert. The result was thousands of false positives, and the real incidents got buried in the noise.

Users became the adversaries. When security tools block legitimate work, people find workarounds. They rename files. They split data across multiple messages. They use personal email. They take photos of screens. DLP that frustrates users doesn't prevent data loss. It just pushes it to channels you can't see.

Endpoint-only coverage missed the real risk. Traditional DLP lived on endpoints and email gateways. That was fine when data lived on laptops and moved through email clients. But now your sensitive data is in software as a service (SaaS) applications, cloud storage, collaboration platforms and application programming interfaces (APIs). If your DLP strategy only covers endpoints and email, you're guarding the front door while the back wall is missing.

What modern DLP actually does

The DLP market has evolved significantly, and the best solutions today look nothing like the regex engines of the past.

Vendors will tell you machine learning fixed false positives. Machine learning helped. Exact data match (EDM) did more.

EDM hashes your actual records, your real customer table, your real account numbers, and alerts only when your data moves. Not data shaped like yours. Yours. That is why the CFO's board report stops getting blocked. Document fingerprinting does the same thing for structured files. Both are unglamorous, both predate the machine learning pitch and both should be configured before you pay for a model.

Then turn on optical character recognition (OCR). I made a joke earlier about users photographing screens. It is not a joke anymore. Images were the second most common data type users submitted to external AI in 2026, behind source code. Screenshot to chat window is a primary exfiltration path now. If your DLP cannot read text inside an image, you are watching the front door while the data leaves through a picture of the data.

Context-aware policies. Modern DLP considers the full picture: who is sending the data, where is it going, what application are they using, is this normal behavior for this user and what's the sensitivity of the content? A developer sharing code snippets in chat gets treated differently than someone downloading a customer database to a universal serial bus (USB) drive. Context turns binary block/allow decisions into nuanced, risk-based responses.

Cloud-native architecture. Data protection needs to live where your data lives. That means inline inspection for SaaS applications, API-based integration with cloud storage, visibility into collaboration platforms and coverage for cloud infrastructure. If your DLP can't see data moving through your SaaS stack, it's blind to your biggest risk surface.

User behavior analytics. Instead of just looking at content, modern DLP looks at behavior. An employee who suddenly starts downloading large volumes of files they've never accessed before. That is a signal. Someone accessing sensitive data outside normal hours from a new location. Another signal. Behavioral analysis catches data exfiltration attempts that content inspection alone would miss.

The channel nobody put in the policy: your AI agents

Every control in the last section assumes a person. Who is sending it. Is this normal for this user. Does this fit their baseline.

Now ask those questions about a non-human identity holding a delegated token.

Non-human identities outnumber humans in the enterprise by roughly 45 to 1, and agents are widening the gap every quarter. In a Cloud Security Alliance survey, 92% of respondents said they are not confident their legacy identity tooling can manage that risk, half named unclear ownership and accountability as a top pain point, and only 14% have fully automated the creation and removal of AI identities. Everyone else is running spreadsheets.

Here is what that does to your DLP program.

Your best behavioral signal is now a false positive. I told you above that an employee suddenly pulling large volumes of files they have never touched is a signal. For an autonomous agent, that is the job description. Bulk access to unfamiliar data under a legitimate token is the normal operating signature of every agent you deployed this year. So when an agent gets prompt-injected and starts exfiltrating, it produces the same telemetry as an agent doing exactly what you bought it for. Behavioral baselining built for humans does not survive contact with non-human identities.

The prompt is a channel and you are probably not inspecting it. Verizon 2026 Data Breach Investigations Report (DBIR) data shows hundreds of thousands of DLP events involving generative AI tools, and the most common data type submitted to external AI, by a wide margin, was source code. Images came second, which is why the OCR advice above is not optional. Most users are hitting AI services from non-corporate accounts on corporate devices. Shadow AI is now among the most common non-malicious insider actions in that dataset, up sharply year over year. And a meaningful share of users has unauthorized AI browser extensions installed that collect browsing context from internal sites, on a path that runs entirely outside traditional DLP.

You built a program to protect source code. The channel your source code actually leaves through is a text box.

Completions leak too. Inspecting the prompt and ignoring the response catches half the problem. An agent with broader entitlements than its requesting user will happily surface data that user was never cleared to see, pulled from an over-shared site by a retrieval layer that honored the token instead of the intent. That is a data loss event with no upload, no attachment and no endpoint.

Tool calls are a data plane. Model Context Protocol (MCP) traffic carries sensitive parameters into tools and sensitive payloads back out. Researchers have documented indirect prompt injection that makes an MCP server fire unintended API requests on the caller's behalf, conversation hijacking through malicious servers, covert tool invocation the user never sees and Unicode concealment that shows a human one tool in the approval dialog while a different one executes. Human in the loop is not a control when the loop is shown a forgery.

And the attackers are already automated. Google Threat Intelligence Group (GTIG) documented a suspected financially motivated actor who used an AI coding assistant and a multi-agent framework to plan, build and execute a mass credential harvesting campaign in under six hours. The framework ran inside the victim's own cloud, so attack traffic came from legitimate IP addresses. In a separate case, GTIG found an exposed command-and-control server whose live dashboard was validating more than 23,800 harvested secrets, including cloud and AI service API keys. Those are the exact credentials your agents authenticate with.

So what do you actually do?

Give every agent its own identity, scoped and short-lived, and never a shared service account. The major identity platforms now govern agents through the same entitlement management you already use for people, so the tooling excuse is gone. Inspect prompts and completions as a first-class channel, not as a web category you blocked. Broker your MCP traffic so tool calls are logged, and treat every unbrokered MCP server as unsanctioned. Baseline agents against agent behavior, not human behavior. And accept that the pre-AI answer to over-permissioned automation, which was to ignore it, has expired.

Context-aware policy was the right idea. It just needs to know that some of its subjects are not people.

The landscape right now

The DLP market has consolidated and shifted, and it reorganizes itself roughly every two quarters. I am deliberately not naming products. Names age badly, and the categories tell you more than the logos do. Map the vendors you already own to these three buckets, then ask the questions that follow.

The platform vendor you already run. If you are deep in one productivity suite, its native DLP is the natural starting point. Coverage of mail, files, chat and endpoints is mature, and the leading suites now extend policy to AI prompts: the assistant embedded in the suite, the agents built on its low-code tooling and the web-grounding path, so you can stop prompts from leaving for web search without killing the feature. Pair that with the same vendor's agent identity capability and you get an identity for every agent and a policy on every prompt.

That last phrase is the catch, and it is the same catch it has always been. Inside that vendor's estate. If your SaaS, collaboration and cloud footprint spans several providers, native DLP alone leaves gaps, and now the gaps include every agent that lives outside the suite's identity plane.

The cloud-delivered security platforms. These build data protection into the traffic path, so inspection is part of every transaction rather than bolted on beside it. Expect strong inline inspection for SaaS, solid cloud storage coverage and behavior analytics. The development that matters is the push into AI: brokers that inspect and control MCP transactions whether you sanctioned them or not, guardrails for prompt injection and jailbreaking, gateways for models you host yourself and built-in red teaming. Several of these platforms grew that capability through acquisition. Make any of them prove classification quality on your own data before you believe the platform story, because platform breadth and inspection depth are not the same purchase. If your risk is heavy SaaS, multi-cloud and a growing pile of agents, this category belongs on your shortlist.

The discovery-first data security vendors. Several long-standing DLP vendors have folded data security posture management and data detection and response into the core platform and narrowed their scope to data security. Discovery-first is the right strategic read, and it is the same direction the suite vendors went. Do your diligence on the company, not just the product. Ownership, financial footing and roadmap focus all shape what you are buying into, and a narrowed roadmap is a bet you inherit.

Whichever bucket you land in, decide where enforcement lives. The endpoint, the network path, the SaaS API and the MCP and agent broker are separate trust boundaries. Ask every vendor which of them they enforce on and which they only observe. Observation without enforcement is a dashboard, not a control.

Making DLP work for users

This is the part that matters most. A DLP solution that users hate is a DLP solution that doesn't work. Here's what separates good implementations from bad ones.

Educate instead of just blocking. When a user triggers a DLP policy, show them why. "This document contains customer personally identifiable information (PII) and can't be shared externally" is infinitely better than "Action blocked by security policy." Users who understand the why are less likely to look for workarounds.

A DLP program your analysts actually read beats a DLP program that catches more and gets ignored. Nobody can honestly tell you their catch rate, yours included, because measuring what you missed requires knowing what you missed. So stop optimizing for a number you cannot produce. Optimize for the alert queue a human will still be working through on a Friday afternoon.

Focus on crown jewels, not everything. You can't protect all data equally. Identify your most sensitive data (customer PII, financial records, intellectual property, source code) and build your strongest protections around that. Everything else gets lighter-touch policies. Trying to apply maximum protection to everything guarantees maximum friction with minimum security.

Make exceptions easy but logged. Sometimes people need to share sensitive data for legitimate business reasons. Make the override process quick and painless, but log everything. "I need to send this customer file to our legal team" should take one click with a justification, not a three-day ticket. But that override gets logged, reviewed and audited.

Bottom line

DLP grew up. The question is whether your approach grew up with it.

If you're still running regex-based pattern matching on endpoints and email, you're protecting a fraction of your data surface with a tool that generates more noise than signal. Modern DLP is context-aware, cloud-native, behavior-driven and, when implemented well, actually useful instead of universally hated.

The technology is there. The challenge is implementation: tune for your environment, focus on what matters most, educate your users and cover the channels where your data actually lives. If users hate your DLP, it's not a people problem. It's a deployment problem.

Data protection in late 2026 means knowing where your sensitive data is, how it moves and who is touching it across cloud, SaaS, endpoints, prompts and tool calls. Note the word who. Increasingly the answer is not a person. It is an agent, holding a token you issued, doing something at three in the morning that looks exactly like what you hired it to do.

Pattern matching cannot get you there. Neither can a policy engine that assumes every subject has a pulse.

Next up: Keeping secrets out of Git without making developers hate you

Make a new world happen, the secure way.

Part of the WWT AI Agent Gateway series. Contact the WWT Security Practice to learn more about ARMOR, WWT AI Readiness Model for Operational Resilience.