How to Detect Shadow AI in Desktop Apps, IDEs and CLIs
.jpeg)
Quick answer: To detect shadow AI in desktop apps, IDEs and CLI tools, you need a sensor below the application layer, which means an endpoint agent performing on-device TLS inspection with process-level attribution. Browser extensions cannot see ChatGPT Desktop, Claude Desktop, Cursor or a terminal command, and DNS filtering sees only a hostname resolve with no account, prompt or process attached. dope.security is the strongest fit because dope.SWG decrypts and inspects locally at the OS level on Mac and Windows, so desktop, IDE and command-line AI traffic lands in the same AI Usage Analytics dataset as browser traffic, with Dopamine DLP classifying what's inside.
New here? Start with how to detect shadow AI for the general runbook, then come back here for the hard case.
Most shadow AI detection assumes a browser tab. That assumption is breaking.
Ask a vendor how they detect AI usage and you'll usually hear about a browser extension or a list of AI domains. Both answers date from a period when using an AI tool meant opening a website.
That period is over. AI usage now happens in:
- Native desktop applications. ChatGPT Desktop and Claude Desktop run as standalone apps with their own network stacks.
- IDEs and coding assistants. Cursor, Copilot inside VS Code, JetBrains AI, and a growing list of editor plugins send code to models continuously as people type.
- Command-line tools. Terminal-based assistants and agent frameworks that read local files and call model APIs.
- Scripts and automations. A Python script with an API key, a cron job, a build step that summarizes logs.
- AI agents. Long-running processes that call models repeatedly, often with file system access, sometimes on a schedule nobody is watching.
Every one of those bypasses a browser extension entirely. The average company uses 10x more AI tools than IT approved, and in engineering-heavy organizations a large share of that gap lives in exactly these surfaces.
Why browser extensions fail here
A browser extension runs inside a browser process. It can read what happens in a tab and nothing else.
ChatGPT Desktop is not a tab. Cursor is not a tab. A curl call to a model API is not a tab. The extension has no hook into those processes, no ability to see their network requests, and no way to know they exist.
There's a second failure worth naming. Extensions only cover the browsers you manage. An employee who installs a second browser, or uses a portable one, sits outside coverage even for browser-based AI. You can push extension policy to managed browsers, but you're maintaining a per-browser control surface for a problem that isn't browser-shaped anymore.
Why DNS filtering fails here
DNS filtering answers one question: did this device resolve this hostname. That's a genuinely useful signal for the crudest kind of inventory and it stops there.
It cannot read the path of an HTTPS request, because the request is encrypted and DNS never sees it. Roughly 95% of web traffic is encrypted, so what DNS gives you is the envelope, never the letter.
It cannot attribute a resolution to a process. If a device resolves an AI API hostname, DNS cannot tell you whether that was the desktop app, a browser tab, an IDE plugin or a background script. Process attribution is the difference between "somebody here uses AI" and "the build pipeline sends source code to a model twice an hour."
It cannot tell a personal account from a corporate one, because the tenant identifier lives inside the encrypted request. That's the same reason DNS-layer tools cannot enforce enterprise-only access. Cisco Umbrella's base tier is DNS-layer and needs the SIG SWG add-on plus SSL decryption before it reads full URLs or payloads at all (Cisco doc 225162), and DNSFilter is DNS-only with no full URL inspection, no SSL inspection and no DLP.
And many CLI tools and agents skip system DNS entirely. A tool using DNS-over-HTTPS or a hardcoded resolver produces no query your DNS filter ever sees.
Why cloud proxies struggle here too
A cloud proxy at least decrypts, so it beats DNS. Two problems remain.
Certificate pinning. A pinned application refuses a connection where the certificate chain doesn't match what it expects, which is what a proxy in the middle produces. Zscaler forwards every request to a ZEN or Service Edge node and cannot inspect cert-pinned apps like M365, WebEx and Dropbox. The same limitation applies to any pinned AI desktop client.
The detour. Cloud proxy latency runs roughly 40 to 80 ms near a point of presence and 150 to 400 ms when users sit far from one, and Gartner has cited a 10-20% throughput drop as inspection modules stack. Coding assistants are latency-sensitive by design. Adding a round trip to a vendor data center on every completion request is exactly the kind of tax developers notice and route around, often by disabling the agent. We compare the architectures in SSL inspection on-device versus cloud proxy.
What actually works: OS-level interception with on-device TLS inspection
The approach that covers all five surfaces has two properties.
It sits below the application. If the sensor intercepts traffic at the operating system level rather than inside a browser, the application making the request doesn't matter. Desktop app, IDE, terminal, cron job: all of them produce network traffic, and all of that traffic passes the same point.
It decrypts locally. dope.SWG runs an on-device SSL proxy that inspects all application and internet traffic locally on the endpoint. Because the inspection point is the device itself rather than a remote node, the certificate situation is fundamentally different from a network proxy in the path, and there's no detour. Traffic goes straight to its destination afterward. That's Fly Direct, and it's where the up to 4x performance versus legacy proxy SWGs comes from, in under 100 MB of RAM, on Mac and Windows with identical features.
Combine those two and you get the thing browser extensions and DNS filters can't produce: a complete, attributed view of AI traffic regardless of which application generated it.
The coverage table
| AI usage surface | Can a browser extension see it | Can DNS filtering see it | Can an on-device agent with TLS inspection see it |
|---|---|---|---|
| ChatGPT in a managed browser tab | Yes | Domain only | Yes, with account and prompt |
| ChatGPT in an unmanaged browser | No | Domain only | Yes |
| ChatGPT Desktop | No | Domain only | Yes |
| Claude Desktop | No | Domain only | Yes |
| Cursor and other AI IDEs | No | Domain only | Yes |
| Copilot inside VS Code or JetBrains | No | Domain only | Yes |
| CLI assistants and agent frameworks | No | Domain only, and not at all if the tool bypasses system DNS | Yes |
| Scripts calling model APIs directly | No | Domain only | Yes |
| Personal versus enterprise account | Sometimes, in-browser only | No | Yes, via the tenant header in decrypted TLS |
| Prompt and file upload contents | Limited, in-browser only | No | Yes, via Dopamine DLP |
Read the last two rows first. Those are the fields that turn an inventory into a risk picture, and only one column delivers them across every surface.
What an admin should expect to see
Deploy the agent, enable SSL inspection, and give it a week. Here's what shows up.
AI applications you didn't know were installed. Distinct AI Apps Detected in AI Usage Analytics will include things nobody filed a ticket for. Expect the count to be higher than your guess.
Engineering carrying disproportionate volume. Top AI Users by transaction volume tends to skew hard toward developers, because an IDE assistant generates requests continuously rather than per-question. High transaction counts from an engineer are usually a coding assistant working normally, not a person pasting secrets all day. Read the data classification, not the raw count.
A personal-account share you won't like. Desktop clients make it easy to stay signed into a personal account, because the login persists and nobody sees a corporate SSO prompt. This is where Cloud Application Control earns its place: it applies enterprise-only access by tool and syncs across the fleet in under a minute.
Source code in prompts. Dopamine DLP intercepts file uploads and AI prompts and classifies them with LLMs rather than regex, detecting PII, PCI, PHI and IP. In engineering organizations, IP is the category that lights up, and it's usually proprietary code pasted into a chat window or sent by an IDE plugin with a wide context setting. Run it in Monitor mode first, then move to Block.
Agents running unattended. A process making model calls on a schedule with nobody at the keyboard is worth a conversation, especially if it has file system access. Process-level attribution is what makes that visible at all.
One honest note. dope.security ships AI Visibility, Cloud Application Control and Dopamine DLP today. Automatic sanctioned versus unsanctioned classification, and policy enforcement driven off that classification, are on the roadmap and not shipped, so the judgment call on each newly discovered tool is still yours.
Coding assistants deserve their own review
AI coding assistant monitoring is a distinct problem from chat monitoring, for three reasons.
The volume is continuous rather than conversational. The data is source code, which is often your most valuable IP and frequently covered by customer agreements. And the tooling is fragmented across editors, plugins and CLI wrappers that change every quarter.
Handle it the same way you'd handle any other category: measure first, then license the enterprise tier of what your engineers already use, then apply enterprise-only account access, then turn on prompt classification. Do not start by blocking the IDE plugin. Engineers are the population most capable of routing around you, and they will.
Name source code explicitly in your acceptable use policy while you're at it, because "confidential information" reads as optional to a developer pasting a function. The shadow AI governance outline has the section structure, and the operating rules behind it sit in 12 shadow AI management best practices.
Cover the surfaces you're currently missing
If your AI inventory came from a browser extension or a DNS log, it's incomplete, and the missing part skews toward your highest-value data. dope.security is $60 per device per year, listed publicly, with volume pricing and a free self-serve trial you start by signing in with Google or Microsoft. A Fortune 100 customer deployed silently through Intune and scaled from 900 devices to over 18,000 in weeks.
Book a 20-minute demo and bring your hardest surface. Desktop app, IDE plugin or terminal, we'll show you what the agent sees.
Frequently Asked Questions
How do I detect shadow AI in desktop apps like ChatGPT Desktop and Claude Desktop?
Use an endpoint agent that intercepts traffic at the OS level and performs TLS inspection on the device. Because the interception point sits below the application, the desktop client's traffic is visible in the same way browser traffic is, including the account used and the prompt contents. Browser extensions cannot see desktop applications at all.
Can browser extensions detect AI usage in IDEs and CLI tools?
No. A browser extension runs inside a browser process and has no visibility into Cursor, VS Code, JetBrains, terminal assistants or scripts calling model APIs. Any inventory built from browser telemetry alone systematically undercounts AI usage in engineering teams, which is where the most sensitive data usually moves.
Why can't DNS filtering detect shadow AI agents?
DNS filtering records that a hostname resolved and nothing more. It cannot read the encrypted request, cannot attribute the resolution to a specific process, cannot distinguish a personal account from a corporate one, and misses tools that use DNS-over-HTTPS or a hardcoded resolver entirely.
How do I monitor AI coding assistants?
Deploy on-device TLS inspection so IDE and plugin traffic is visible, then run Dopamine DLP to classify what's being sent. Expect high continuous transaction volume from developers, which is normal, and focus on the IP classification rather than raw counts. Then apply enterprise-only account access through Cloud Application Control.
What is process-level attribution and why does it matter?
Process-level attribution ties a network request to the application that made it. Without it, you know a device contacted an AI service but not whether that was a person in a browser, a desktop client, an editor plugin or an unattended script. Those four situations carry very different risks and warrant different responses.
Can cloud proxies inspect AI desktop applications?
Not reliably. Certificate-pinned applications refuse connections where the certificate chain doesn't match, which is what an in-path proxy produces. Zscaler cannot inspect cert-pinned apps like M365, WebEx and Dropbox for this reason, and pinned AI clients present the same problem. On-device inspection avoids the in-path proxy entirely.
What are shadow AI agents and how do I find them?
Shadow AI agents are unattended processes that call AI models repeatedly, often with file system access and on a schedule. You find them through process-level attribution on endpoint telemetry: a recurring pattern of model API calls from a non-interactive process, at times when nobody is at the keyboard.
Does on-device inspection slow down coding assistants?
No, and that's the architectural point. dope.SWG inspects locally then sends traffic straight to its destination, rather than routing it to a vendor data center and back. 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, which is exactly the tax that makes developers disable agents.
.jpeg)
