The honest version of this comparison is not that one category wins. It is that each layer inspects a different thing, and AI traffic has a habit of moving through the places none of them stand. Your CASB sees the domain. Your DLP sees the file. Your SSE sees the session. None of them sees the tool call.
This piece is about where each layer structurally stops, and which gap you are left holding depending on what you already own. If you want the capability matrix across categories, it is in the control plane hub. What follows is the mechanical detail underneath it: not which product has which checkbox, but why certain traffic cannot be inspected by a control sitting in that position, regardless of vendor.
What each layer actually inspects
A CASB in proxy mode sits in the session path and enforces on web traffic. An SSE platform consolidates that with secure web gateway and private access, delivered from a cloud edge. Traditional DLP was built for files and endpoints, and its classifiers are its durable asset. AI-native tooling positions at the point of use, where the prompt is composed and the tool call is issued.
Those positions determine everything that follows. A control sees what passes through its position, and nothing else.
The inspection problem starts with TLS
Inline proxy inspection requires terminating TLS, which requires a corporate root certificate on every endpoint. That requirement is where the architecture starts leaking, and the vendors document it themselves rather than hiding it.
Certificate pinning defeats forward-proxy decryption outright. A pinned client refuses the proxy's substituted certificate, so the proxy cannot read the session. Both Palo Alto Networks and Netskope publish predefined exclusion lists of applications that are bypassed by default for exactly this reason, and Netskope's list includes GitHub, Dropbox, Google Drive and dozens more. Mutual TLS has the same outcome by a different route: the proxy terminates and re-originates the connection and cannot forward the client's certificate, so the remedy both vendors give is to stop inspecting.
Cloudflare states the consequence plainly in its own documentation: exempting an application from TLS inspection turns off DLP for that traffic. The exclusion list is not a minor operational detail. It is a list of places your data loss prevention does not run.
Encrypted Client Hello is worse than pinning, and differently so. Gateway policy matches on the server name in the handshake. When that name is encrypted there is no selector left to match, so the failure is not that you lose the payload. You lose the ability to route the decision at all.
The certificate is installed. Does the AI tool use it?
This is the part that surprises people who have done everything right.
Installing a root CA in the operating system trust store only works for applications that read the operating system trust store. Netskope's own documentation of supported developer tooling names the interpreters and CLIs it has had to handle specially, which is an admission that this class of application does not follow the OS store by default. Node.js is the clearest case: it ships with a bundled Mozilla CA snapshot fixed at release time, identical across platforms, and using the system store requires a flag that only arrived in a recent major version.
The fair version of this claim matters, because the overstated version is wrong and a security architect will catch it. AI tools do not uniformly ignore your corporate CA. Anthropic's Claude Code, for instance, documents that it trusts the OS store by default, though on npm installs that behavior depends on the Node version underneath. The accurate statement is narrower and more uncomfortable: whether a given agent runtime trusts your corporate CA is a per-application, per-runtime, per-version property that your enterprise does not control and has almost certainly never audited.
That is a different problem from a coverage gap. A coverage gap you can measure. This one changes when a developer upgrades a package.
Three places every network-positioned control is blind
Set the certificate problem aside and assume perfect decryption. Three categories of AI traffic still do not pass a network control in a form it can act on.
Local MCP servers speak over stdio. The client launches the server as a subprocess and they talk over standard streams. There is no socket, no TLS session, and nothing for a proxy to sit in front of, which is the shape of the problem in finding MCP servers security cannot see. Remote MCP over HTTP is genuinely visible by comparison, and a decrypting gateway can read the tool name and arguments out of the request body. The limits there are practical rather than structural: the gateway needs a JSON-RPC parser and a policy model for tool semantics, and since the endpoint path is arbitrary, URL-category policy gives you nothing.
Server-side tools execute on the provider's infrastructure. When an agent uses a hosted search or fetch tool, the provider's documentation is explicit that the API executes the call internally. The outbound request to the third-party site originates from the provider's cloud. Your network sees one TLS session to the model provider's API and never sees the fetch at all. No amount of decryption at your edge changes this, because the traffic you want to inspect is not on your network.
CASB session control is browser-only. Microsoft states that session controls apply only to browser-based access and are enforced during interactive browser sessions, and that its own Teams desktop client is unsupported. Microsoft's recommended mitigation is to block native clients and allow only browser sessions. Consider what that policy does to a desktop AI assistant, an IDE with an agent in it, or a terminal-based coding tool, which is the ground covered in endpoint AI security.
What CASB and SSE genuinely do better
A comparison that only lists the other side's weaknesses is marketing. Three things these platforms do that AI-native tooling generally does not.
Catalog-based discovery at scale, from logs, with no decryption at all. Microsoft's Cloud Discovery analyzes traffic logs against a catalog of more than 31,000 applications scored on risk factors, and it works without touching TLS. The honest limit is that it is catalog-bound, and Microsoft says so: applications not in the catalog are not discovered, which means a model endpoint called directly from a script or a three-week-old AI startup is invisible until the catalog catches up.
API-mode CASB scans data at rest inside SaaS applications, out of band, using the provider's own APIs. It needs no proxy and no certificate, which makes it immune to pinning, mutual TLS and Encrypted Client Hello entirely. That is durable value nothing in the AI-native category replicates. Its limit is latency rather than coverage: Microsoft notes that full tenant scans spread across hours or days, so it is not a real-time control.
And the classifiers are real assets. Microsoft's own approach to generative AI protection is instructive here, because Purview delivers it through integrations with secure access service edge or secure browser solutions rather than as a network control of its own. The classifier is the reusable part. The inspection point is what differs, which is the distinction drawn out in AI DLP versus legacy DLP.
The case that proves the gap
ShadowLeak, published by Radware in September 2025, is the clearest demonstration that this is architecture rather than product quality.
The attack used an indirect prompt injection delivered to an agent with enterprise mail access and browsing, and the exfiltration happened service-side. The request that carried the data out was made by the provider's infrastructure, not by the user's machine. An enterprise with a fully deployed CASB, a decrypting SSE, and endpoint DLP would have seen a single authorized session to a sanctioned AI provider, because that is all there was to see. Radware reports the vulnerability was confirmed and fixed.
Two related cases make the same structural point from different angles. EchoLeak in M365 Copilot rode a trusted Microsoft host that performed a fetch on the client's behalf, defeating Microsoft's own content security policy allowlist. CamoLeak used GitHub's own image proxy as the channel, with traffic flowing between two legitimate GitHub domains. In each case the exfiltration path was a trusted host inside the allowlist, which is precisely the control that network-positioned tools rely on.
You already own something. What is your gap?
| If you own | You are covered for | Your remaining gap |
|---|---|---|
| CASB in API mode | Data at rest in sanctioned SaaS, no certificate needed | Anything in motion; nothing is real-time |
| CASB session control | Browser-based access to sanctioned apps | Every desktop app, IDE and terminal agent |
| SSE or SWG with decryption | Web and remote MCP traffic you can decrypt | Pinned apps, mTLS, ECH, stdio, server-side tools |
| Endpoint DLP | Files leaving the device | Prompts, which are typed rather than copied from a file |
| Log-based discovery | Known apps at scale, cheaply | Anything not yet in the catalog |
Read down the right column. Every gap in it is either a place the traffic does not pass, or a form the traffic does not take. That is why adding a second product in the same position rarely closes anything, and why the useful question is not which category is better but which position is unoccupied in your estate.
The position that covers most of the right column is the point of use, because a prompt is inspectable where it is composed regardless of what the transport does afterwards, and that inspection needs no root certificate on the endpoint. That is the argument for inspecting the prompt rather than the session, and it is a positional argument rather than a feature one.
So is AI security a real category?
Partly. The classifiers are not new, and the acquisition pattern suggests platform vendors expect to absorb this. Gartner itself folded CASB into SSE: the last Magic Quadrant for Cloud Access Security Brokers appeared in 2020, and the first for Security Service Edge in 2022. Categories consolidate, and this one probably will.
What does not consolidate is the inspection point. A control that lives in the network cannot inspect a subprocess talking over standard streams, and it cannot inspect a request that originates from somebody else's cloud. Those are not gaps a roadmap closes. If the incumbents cover this, they will do it by shipping something that runs at the point of use, which is a new position rather than a new feature.
Which is also the reason no incumbent will publish this comparison. They sell the layer, so the table above is one they cannot write. For a view of who is actually shipping what, the vendor landscape is the better starting point than any single vendor's comparison page.