AI DLP vs CASB vs endpoint DLP.

They sound overlapping in a procurement conversation and see almost nothing in common.

Endpoint DLP was designed around documents: a file has a classification, and here are the channels through which files leave. A paste into a textarea is none of those. The data never becomes a file and never triggers a rule. The product is working correctly; the surface is outside its model.

CASB was designed around sanctioned SaaS. It reliably tells you that someone connected. It does not tell you the connection carried 400 patient records, because inline content inspection of an arbitrary web composer is not what it does.

Secure web gateways come closest and still miss on timing: they see the request after send, so the disclosure has already happened and only alerting remains. Certificate pinning and encrypted client hello steadily reduce what can be decrypted at all.

The useful exercise is not choosing between them. It is writing down every surface where company data can reach an AI tool, naming the control that owns each, and being honest about which rows have no owner.

Having described what each control sees, it is worth naming what none of them sees, because this is the part that grows fastest.

A coding assistant inside an IDE reads a repository and sends context to a model without anybody pasting anything. An agent given a task takes several steps on its own, reading files and calling tools, and the data it sends is a consequence of a goal rather than of a keystroke. Browser extensions summarising the page a user is on do something similar. None of these is a composer, so a composer-level control does not see them, and none of them produces a file, so endpoint DLP does not either.

We cover the composer surfaces and we do not cover these, which is the honest position and the same one we would want from anybody else. The practical advice is to treat IDE assistants and agent frameworks as their own procurement decision, governed by what the tool is permitted to read rather than by what somebody types.

The intuitive answer to this problem is to inspect the traffic, and it is worth understanding exactly why that does not work before spending money on it.

Everything is TLS, so a gateway sees a destination and a byte count unless it terminates the connection. Terminating it means installing a root certificate on every device and decrypting your staff's traffic, which is a far larger privacy decision than the one you were trying to make, and which certificate pinning and a growing list of applications will refuse anyway. Even with decryption, a modern AI interface sends a prompt as one field in a streaming request, often alongside a conversation history, so what arrives is a blob that needs parsing per vendor and re-parsing every time a vendor changes it.

Reading the text where it is composed sidesteps all of that. The honest trade is that it requires software on the device, which is a deployment cost a network control does not have, and it covers the surfaces that software reaches rather than everything on the network.

Nobody buys three controls at once, and the order is usually decided by whichever renewal lands first, which is not a reason.

If you have none of them, endpoint DLP for files is the broader control and the conventional first purchase. If you have endpoint DLP and a CASB already, which most organisations of any size do, then the question is narrower: is anybody writing regulated data into an AI tool, and would you know. Two weeks of discovery answers it, and the answer decides the spend rather than a comparison table.

What we would not claim is that this is urgent for everyone. An organisation whose staff do not handle regulated data has a shadow AI question that is about productivity and vendor risk, not about disclosure, and that is a different purchase with a different justification.