Claude Desktop & Cursor security risks: the local-tool blind spot browser DLP can’t see
Your developers are running Claude Desktop, Cursor, VS Code + Copilot and Windsurf — native apps that launch local tools and MCP servers on the endpoint, with file, shell and secrets access, and egress to LLM APIs. That traffic leaves as native-app egress, not a browser tab — so your browser DLP and CASB never see it. Here’s the real risk, how to see it today for free, and where NetInsightPro fits.
Platforms: the manual checks below are OS-agnostic and work on macOS, Windows and Linux. NetInsightPro’s automated discovery, inventory, risk scoring and block cover Windows, Linux and Android; a macOS build is in review, and there is no per-app blocking on macOS. (There is no official Linux build of Claude Desktop.)
What Claude Desktop, Cursor and the others actually run on the endpoint
These aren’t websites in a tab. They’re native applications that run code on the machine — and, increasingly, they launch MCP (Model Context Protocol) servers: small local programs that give the assistant new powers such as reading files, running shell commands, calling APIs and querying databases. Each MCP server is third-party code running with real permissions, it holds whatever secrets its config gives it, and it installs in seconds with no installer and no asset-register entry.
Claude Desktop
Launches MCP servers declared in claude_desktop_config.json — filesystem, shell, database and API tools it can call on your behalf. There is no official Linux build.
Cursor
A full AI-first code editor that reads your repository and runs MCP servers from its own mcp.json — plus its own agent that edits files and runs commands.
VS Code + GitHub Copilot
Copilot Chat and agent mode operate in the editor, and VS Code registers MCP servers in its settings — extensions and MCP tools run locally with your workspace access.
Windsurf (Codeium)
An agentic IDE that indexes your codebase and runs MCP servers from its own config — the same local-tool surface as the others.
Each of these declares its MCP servers in its own JSON config file. The discovery guide has the full per-OS config-path table and the process / connection commands — we won’t reprint it here. What this page is about is why the controls you already own don’t see any of it.
Why your browser DLP and CASB don’t see it
Most data-loss tooling was built for the browser era. Browser-extension DLP, CASB and SaaS-session controls inspect what leaves through web tabs and sanctioned SaaS logins — a file uploaded to a web app, text pasted into a chat site, a download from a cloud drive. That’s a real and useful control plane. It just isn’t the one an AI IDE uses.
Claude Desktop, Cursor and the MCP servers they launch are native processes. Their traffic to LLM APIs leaves as native-application egress — direct HTTPS from a desktop app or a local CLI to a provider endpoint. A browser-centric control never sees it, because it isn’t a browser tab. And here is the part that makes the gap genuine rather than rhetorical: even a TLS-intercepting forward proxy that does see the connection to api.anthropic.com can’t tell you which local MCP server or tool opened it, what filesystem or shell scope that tool holds, or which secrets its config references. The endpoint-side context — the part that tells you whether this is a sanctioned assistant or an over-permissioned shadow tool — only exists on the device.
What browser controls see
- Uploads and pastes into web apps and SaaS
- Sanctioned SaaS logins and sessions
- Traffic that flows through a browser tab
What they miss (the blind spot)
- Native-app egress from Claude Desktop, Cursor, Copilot, Windsurf
- Local MCP servers with file, shell and secrets access
- Which local tool opened a connection to an LLM host — and what it can reach
Related reading: how we detect per-app LLM egress without reading prompts — the observation unit is (process, host, direction, bytes, time), never the request body.
What actually leaves the endpoint — and to where
None of this is inherently malicious — it is how the tools work. But it is worth being precise about what an AI IDE and its MCP servers send off the machine, because that is what your browser controls didn’t inspect.
Source code & repository context
To answer a question or edit a file, the IDE sends the relevant code and the surrounding context it indexes to the model provider. That is proprietary source leaving the endpoint by design.
Secrets an MCP server holds
MCP servers routinely carry API tokens and keys in their config so they can reach the services they wrap. An over-permissioned or untrusted server is a credential exposure, and reaches the filesystem, shell, databases and network with them.
Prompts & context → LLM API hosts
Everything the assistant reasons over travels over HTTPS to provider endpoints — hosts like api.anthropic.com, api.openai.com, generativelanguage.googleapis.com, api.cursor.com or codeium.com. Knowing which app on which device is talking to which of these — and what that app can reach locally — is the visibility that’s missing.
How to see this today, for free
You don’t need to buy anything to start. On any machine running an AI IDE — including a Mac — three checks tell you most of what you need.
1. Open the AI IDE’s MCP config
Each tool declares its MCP servers in a JSON config under an mcpServers block — read the command, args and env to see exactly what runs, what it can reach, and which secrets it holds. The exact file paths per OS and per tool are in the discovery guide.
2. Watch the native app’s outbound connections
Use your OS connection tools or a per-app firewall to see the AI IDE and its child processes connecting out to LLM hosts — the provider APIs above are expected; an unfamiliar destination from a “weather” or “docs” MCP server is the red flag. This is the native-app egress your browser controls skip. (A purely local stdio MCP server opens no socket — you catch those in step 1.)
3. Judge scope, then harden
For every server, ask whether its reach matches its job — a filesystem server scoped to one project folder is far safer than one pointed at your home directory. Then work through the practical checklist for securing MCP servers — least privilege, pinned versions, secret rotation and the rest.
The three checks, at a glance
- Open each AI IDE’s MCP config and read command / args / env
- Watch native-app outbound to LLM hosts (and unexpected ones)
- Match each server’s scope to its job — least privilege
- Harden with the securing-MCP checklist
One laptop is a manual check. A fleet is what NetInsightPro is for.
Doing those three checks on your own machine is easy. Doing them on every developer’s machine, on a schedule, and keeping one deduplicated picture of which AI agents and MCP servers are running, where, and how risky — that’s the part worth automating. NetInsightPro does cross-platform discovery, fleet inventory and evidence-based risk scoring of exactly these agents and MCP servers across Windows, Linux and Android. AI-agent & MCP security is live on Pro today. The manual method above still stands on its own.
Cross-platform discovery & fleet inventory (Pro)
The same config-file and process inspection you’d do by hand — run continuously on every device, reduced to one deduplicated inventory of every AI agent, MCP server and tool, on Windows, Linux and Android.
Per-app egress to AI providers — destinations, not payloads (Pro)
See which process on which device is talking to which AI/LLM host, identified by destination and process — the native-app egress your browser DLP misses. It records where the bytes went, never the prompts or code inside them.
Evidence-based risk scoring (Pro)
Each asset scored Low, Medium, High or Critical from its declared permissions, provider recognition and secret exposure — with the evidence shown, not a black-box number. Vulnerability scanning is included and rolling out; today’s scoring is heuristic and evidence-backed.
Policies & automatic blocking (Enterprise)
Set policies once and let NetInsightPro block matching assets per destination host across the fleet automatically, with a SOC view. That is automatic blocking, not remediation — the config-level fixes stay with your team.
We’re early to this category and honest about the edges. NetInsightPro complements the AI IDE’s own controls, your antivirus / EDR and code-level MCP scanners — it doesn’t replace them, and it doesn’t read your prompts or code. See how discovery works.
What we won’t claim
A page about a blind spot has to be honest about its own edges. Here is exactly what NetInsightPro does not do.
It does not read prompts or code. NetInsightPro observes the egress destination (which process talks to which AI/LLM host) and the MCP config structure (permission counts, secret key names/counts) — never the request body, never secret values, never your prompts.
The browser-DLP gap is scoped, not absolute. Browser-extension DLP and CASB miss native-app egress entirely; a TLS-intercepting proxy can see the connection but not which local tool made it or what it can reach. We don’t claim network controls never see anything.
Blocking is per destination host through the OS firewall on Windows, Linux and Android — not per app-process, and not by reading a live connection. A purely local stdio MCP server has no destination host; on-device quarantine for those is rolling out. There is no macOS blocking (a macOS build is in review).
It complements, never replaces. The AI IDE’s own permission prompts, your antivirus / EDR and code-level MCP scanners all still matter. Vulnerability scanning is included and rolling out — today’s risk is heuristic and evidence-backed, not deep per-package CVE analysis. No fabricated metrics or logos.
Frequently asked questions
See which AI agents & MCP servers are running across your fleet
Start free on up to two devices, or go Pro for cross-platform discovery, inventory, evidence-based risk and one-click block. Runs alongside your antivirus. It sees egress and config — never your prompts.
New to this? Start by discovering the MCP servers on your fleet