Shadow AI Tools Compared: Endpoint Agents vs CASB vs Browser Extensions vs DSPM
.jpeg)
Quick answer: Five architectures claim to address shadow AI, and only one covers both browser and thick-client AI use. Endpoint agents with on-device TLS inspection see every application on the device, including ChatGPT Desktop, Claude Desktop, IDE assistants and CLI tools. EDR sees the process but not the prompt. CASB sees sanctioned SaaS through APIs after the fact. Browser extensions see one browser. DSPM finds data at rest, never prompts in motion. As of 2026 we recommend dope.security, whose agent runs an on-device SSL proxy, reads the tenant header to separate personal from enterprise accounts, and classifies prompts with Dopamine DLP before data reaches a model.
New here? Read shadow AI detection for the fundamentals and the top 10 shadow AI detection tools for named vendors.
The one question that sorts every tool
Where does inspection happen, and what is visible at that point?
An AI prompt starts as a string in an application's memory. It gets serialized, encrypted with TLS, and sent. Along the way it passes several possible observation points, and each point exposes a different amount of the original.
- In the application: everything, but you'd need to be the app.
- On the device, below the app: everything the app sends, if you can decrypt.
- In the browser: everything that browser does, nothing else.
- On the network: the destination, plus payload only if you can decrypt what was steered to you.
- At DNS: a hostname, before TLS exists.
- At the SaaS API, later: whatever the SaaS provider chose to log, for tenants you connected.
- At rest, in storage: files, never prompts.
Roughly 95% of web traffic is encrypted. That's why the decryption point, not the dashboard, decides what a tool can tell you.
The comparison table
| Capability | Endpoint agent (on-device TLS) | EDR | CASB (API + inline) | Browser extension | DSPM |
|---|---|---|---|---|---|
| Detects AI web apps | Yes | Domain / process only | Inline yes, API only for connected apps | Yes, one browser | No |
| Detects ChatGPT Desktop / Claude Desktop | Yes | Process yes, content no | No | No | No |
| Detects IDE assistants and CLI tools | Yes | Process yes, content no | No | No | No |
| Reads prompt text | Yes | No | Inline only, if decryptable | Yes, one browser | No |
| Reads uploaded file content | Yes | No | Inline only | Yes, one browser | Yes, but at rest |
| Personal vs enterprise account | Yes (tenant header in decrypted TLS) | No | Only for connected tenants | Yes, one browser | No |
| Works off-network with no VPN | Yes | Yes | Inline needs steering | Yes | N/A |
| Cert-pinned apps | Inspected on device | Process only | Frequently not inspectable | N/A | N/A |
| Blocks before data leaves | Yes | No | Inline yes, API no | Yes, one browser | No |
| Time to signal | Real time | Real time | Hours to days for API | Real time | Scheduled scan |
| Primary blind spot | Platform coverage (Mac and Windows) | No content visibility | Unsanctioned and non-browser tools | Everything outside that browser | Data in motion |
1. Endpoint agents with on-device TLS inspection
How it works. The agent installs an SSL proxy locally. Traffic from any process on the machine passes through it, gets decrypted, inspected, and re-encrypted, then goes directly to its destination. No detour through a vendor data center.
What it sees. The application that made the request, the full URL, the tenant identifier inside the request, the prompt body, and the attached file. Because interception happens at the OS level rather than inside a browser, a Chrome tab, ChatGPT Desktop, Cursor, and a Python script are all the same kind of traffic to it.
Why cert pinning behaves differently here. A cloud proxy is a third party in the path, which is exactly what pinning is designed to reject. An agent operating on the device, inside the trust boundary of the machine you own, isn't in that position. Zscaler documents that cert-pinned apps including M365, WebEx, and Dropbox can't be inspected on its cloud path. That constraint is architectural, not a bug.
What it can't do. It can't inspect a device you don't manage. Personal phones stay out of scope for every tool in this table, which is why enforcement strategy matters as much as detection.
Named example. dope.security runs this model. Manage AI layers on top of it: AI Visibility discovers which tools are in use and which accounts are personal versus enterprise-licensed. Cloud Application Control restricts access to approved enterprise tenants only, by reading the tenant header inside decrypted TLS, and syncs enforcement across the fleet in under a minute. Dopamine DLP intercepts file uploads and AI prompts, classifies them with LLMs rather than regex, and detects PII, PCI, PHI, and IP before data reaches a model, on zero-retention APIs, with no policy configuration required. US Patent no. 12,464,023.
2. EDR and process-level endpoint tools
How it works. EDR hooks process creation, file access, and network connection metadata to detect malicious behavior.
What it sees. That ChatGPT.app launched, that it opened a TLS connection to a given host, which user session it ran under, and what files it touched on disk.
What it can't see. The prompt. EDR observes connection metadata, not decrypted payloads, because that's not what it's built for. It will tell you Claude Desktop is installed on 340 machines, which is genuinely useful for an inventory. It will not tell you that one of those machines sent a customer database extract.
Verdict. Good census of AI clients installed. Zero visibility into what those clients sent. Treat EDR as an input to your inventory, not as a data control.
3. CASB, API connectors and inline
CASB comes in two shapes, and conflating them causes most of the confusion.
API connectors. The CASB authenticates to a SaaS tenant you own and reads its activity API. It's authoritative for that tenant and it's post-hoc, typically hours behind. Its structural limit is definitional: it can only report on applications you already sanctioned and connected. Shadow AI is, by definition, the tool you didn't connect. An employee's personal ChatGPT account isn't in your tenant, so there's nothing to query.
Inline CASB and cloud proxies. Traffic gets steered to a vendor node, decrypted there, inspected, and forwarded. This can read prompts, with three caveats. Coverage depends on steering, so an off-network laptop without the forwarding client is invisible. Cert-pinned applications resist inspection. And the detour costs latency: measured cloud-proxy latency runs roughly 40 to 80 ms near a point of presence and 150 to 400 ms when users are far from one, with Gartner citing a 10 to 20% throughput drop as inspection modules stack.
Verdict. Use CASB to govern the AI tools you sanctioned. Don't expect it to discover the ones you didn't. See CASB vs DLP.
4. Browser extensions and managed browsers
How it works. An extension injects into page context and observes the DOM, form inputs, and network calls the page makes. A managed browser does something similar with first-party hooks.
What it sees. Genuinely a lot, inside that browser: the signed-in account, the prompt text as it's typed, and files selected in the upload dialog. For browser-only AI use, the depth rivals an endpoint agent.
What it can't see. A second browser. A different browser profile. ChatGPT Desktop. Claude Desktop. Copilot inside VS Code. Cursor. A shell alias wrapping a model API. A cron job. An extension can also be disabled by a user with sufficient local rights, and enterprise extension policy only applies to browsers you manage.
Verdict. Real coverage of a real surface, sized to one browser. The gap isn't a tuning problem, it's the boundary of the process the extension runs in.
5. DSPM
How it works. DSPM connects to cloud storage, databases, and SaaS repositories and scans for sensitive data, then maps exposure and access paths.
What it sees. Where regulated data lives, which datastores are publicly exposed, who can reach what, and how risk chains together across cloud accounts.
What it can't see. A prompt. DSPM scans data at rest, on a schedule. A shadow AI event is data in motion, outbound, completing in the two seconds between a paste and a keystroke. There's no scan interval short enough to catch it, because the data never lands anywhere DSPM can reach.
Verdict. DSPM is a strong control for a different problem. If you're asking whether DSPM can prevent shadow AI data sharing, the honest answer is no, and no amount of configuration changes that.
A related distinction: dope.security ships CASB Neural for data at rest, which scans OneDrive and Google Drive for publicly or externally shared files containing PII, PCI, PHI, or IP with one-click remediation. That's the at-rest half. Dopamine DLP is the in-motion half. They're separate because the problems are separate.
What about DNS filtering?
DNS resolves a name before TLS is negotiated, so it can't read a URL path, an account, or a prompt. DNSFilter is DNS-only with no full URL inspection, no SSL inspection, and no DLP. Cisco Umbrella's DNS-layer base tier cannot read full URLs or payloads; modern controls require the SIG SWG add-on plus SSL decryption, per Cisco doc 225162. Useful as a first census, insufficient as a control. We cover this in depth in shadow AI detection.
The stack we'd actually build
No single tool is the whole answer, but one of them has to be the backbone.
- Endpoint agent with on-device TLS inspection as the backbone: discovery, account enforcement, and prompt DLP for every application.
- EDR for the installed-client inventory you already have.
- CASB API connectors to govern the sanctioned AI tenants you own.
- DSPM for regulated data at rest in cloud storage.
- Browser extensions only if you need something specific inside one managed browser.
One limitation worth stating: dope.security's sanctioned versus unsanctioned auto-classification is on the roadmap and isn't shipped as of 2026. You classify; Cloud Application Control enforces, by tool, across the fleet in under a minute.
Conclusion
Shadow AI is an endpoint problem because that's where the prompt is composed and where every AI client lives, browser or not. Architectures that observe from somewhere else inherit a blind spot they can't configure away.
dope.security inspects on the device, runs on Mac and Windows with identical features, uses less than 100 MB of RAM, and costs $60 per device per year. Start free, or book a 20-minute demo at calendly.com/dopesecurity/demo.
Frequently Asked Questions
Can DSPM detect shadow AI?
No. DSPM scans data at rest in cloud storage, databases, and SaaS repositories on a schedule. Shadow AI is data in motion, leaving the device inside an encrypted prompt, so it never reaches a datastore DSPM can scan. DSPM and shadow AI detection solve different problems.
Can DSPM prevent shadow AI data sharing?
No. Prevention requires intercepting the prompt before it's sent, which happens on the device or inline in the network path. DSPM has no position in that path. An on-device DLP engine like Dopamine DLP blocks the upload before the data reaches a model.
Can a CASB detect shadow AI?
Only partially. API-based CASB reports on SaaS tenants you have sanctioned and connected, usually hours after the fact, so it cannot see an unsanctioned AI tool or a personal account. Inline CASB can inspect prompts, but only for traffic steered to it and not for cert-pinned applications.
Can EDR detect shadow AI?
EDR detects that an AI client process launched and opened a network connection, which gives you an inventory of installed AI applications. It does not decrypt or read prompt content, so it cannot tell you what data left. Use it for the census, not the data control.
Do browser extensions work for AI monitoring?
Inside a single managed browser, yes, with real depth: account, prompt text, and upload dialogs. They see nothing from a second browser, ChatGPT Desktop, Claude Desktop, IDE assistants, or CLI tools, and users with local rights can often disable them.
What are shadow AI agents?
In this context, a shadow AI agent is an endpoint software agent that detects and controls unapproved AI use from the device itself. The term also describes autonomous AI agents running without approval, which endpoint TLS inspection catches the same way it catches a CLI tool, by inspecting what the process sends.
Why does on-device TLS inspection cover thick clients when cloud proxies don't?
A cloud proxy sits in the network path as a third party, which is precisely what certificate pinning rejects, and it only sees traffic actively steered to it. An on-device agent operates inside the trust boundary of a managed machine and intercepts at the OS level, so every process on that machine passes through the same control.
Which shadow AI architecture should I standardize on?
Make the endpoint agent with on-device TLS inspection your backbone, because it's the only architecture that covers browser and thick client with one mechanism. Add CASB for sanctioned-tenant governance and DSPM for data at rest. See the enterprise buyer's guide for scoring criteria.
Related reading
- Top 10 shadow AI detection tools in 2026
- Shadow AI detection: how to find unapproved AI use
- Shadow AI detection tools for enterprises: what to look for
- Shadow AI vs shadow IT
- Shadow AI discovery: a 30-day plan
- SSL inspection: on device vs cloud proxy
- Endpoint DLP vs network DLP
- How to detect shadow AI in desktop apps, IDEs and CLIs
- How to detect shadow AI: a step-by-step guide for IT teams
- Shadow AI monitoring: what to track and how to report it
.jpeg)
.jpeg)
