Rethinking DLP for the agentic era

For twenty years, DLP solutions operated on the principle of boundaries. A boundary that comprises trusted apps, trusted domains and managed devices. Anything else falls outside that boundary. For example: an email to a personal address or an upload to a random website is considered a leak.

A fairly straightforward operating model.

However, that same model cannot work when every app is becoming agentic.

Why the model breaks today

The apps before the agentic era did what they were developed to do. Today’s agentic apps have an intelligence layer built-in which makes them improvise based on context. They have become unpredictable; so trust is not implicit anymore.

In the legacy sense, let’s consider Claude Code to be a trusted agent. The moment you hand it data, what happens on the backend stops being clear. The agent calls other agents. Those agents call APIs. Somewhere in that chain, your data stops being cleanly inside or outside the perimeter you defined. It’s inside a mesh of processes you can’t fully trace.

Legacy DLP was built for a world with walls. But agents operate off instructions and instructions travel.

Beyond the straightforward case of users sharing internal data like a customer list, source code, or a confidential document to get their work done, there are other avenues for data leaks.

The user may delegate a task to an agent with a legitimate instruction. But the agent can misroute the data while carrying it out. For example, ask an agent to send a set of leads to the sales team and it could end up sending them to finance as well. The user didn’t leak the data; the agent did, while following instructions.

An agent can retrieve content through RAG or other connected tools, process it, and incorporate relevant information into its response. It might not reproduce the exact file or content, but sensitive information from that data can still make its way into the response. Sensitive information can surface even when the user never explicitly provides it.

In some workflows, agents may not work alone. One agent can call a sub-agent, which can then interact with an API or another service. Data can move through this chain of delegated actions, crossing systems and trust boundaries that the user may never see. Where exactly the leak occurred may be difficult to determine.

None of these cases require data to cross a boundary you defined in advance, because there was never a single boundary to cross.

Think of traditional DLP like airport security. You check the passenger at the gate, verify where they’re going, and let them through. The problem with agents is that the passenger can now decide mid-journey to change terminals, hand the baggage to another traveler, or send it somewhere else entirely. Checking the gate isn’t enough. You need to track the entire journey.

DLP in the agentic era: Visibility first. Validation always.

The foundation of DLP still remains the same: visibility. How you gain that visibility is what has become messier. What tools the agent can reach. What sub-agents it can call, and what those will call in turn. What it pulls through RAG. Where that content originated. What formulated response was passed to the next agent.

Then: validation at every step. Not once at the boundary, like it used to be. DLP needs to evolve to check at each step.

If the old DLP checked whether data left the gate, the new DLP has to ask whether it should have left the room in the first place and every time it moves. A trusted boundary made sense when there was one gate. Not when agents build more gates than you can count.