MCP is quietly changing what a developer laptop is.
When someone runs an MCP-enabled client locally, they’re not just using an assistant. They’re standing up a local runtime that sits between external models and some of the most sensitive assets in the company: source code, repos, configs, shells, package managers, and internal APIs.
That local MCP server becomes a real boundary in the system. And today, most security stacks don’t see it at all.
Why EDR does not catch MCP
EDR does exactly what it was designed to do: classify processes, watch behavior, and flag known bad patterns.
The problem is that MCP looks completely normal at that level.
A legitimate desktop app spawns Python or Node.
It reads files and repo trees.
It makes legitimate outbound HTTPS calls.
It runs helper scripts and subprocesses.
None of that violates policy on a developer machine. The difference is intent. MCP turns natural language into tool calls that perform real actions, often in chains. Most EDR telemetry captures the primitives, but not the semantic link between model reasoning and local execution.
Even Microsoft describes MCP as a client–server architecture. That’s a distributed system boundary — running on laptops.
Why network controls don’t help
This breaks exactly where modern controls already struggle: encrypted egress.
Once traffic is TLS, firewalls and DLP mostly see destinations and volumes. Developer traffic to model providers, GitHub, npm, and cloud APIs is usually allowed. CASB and SASE are built for governed SaaS surfaces, not local runtimes that use HTTPS to move context to external inference.
So sensitive code and config can flow from laptop to model endpoint without ever touching a centralized control plane.
Package managers go beyond plumbing tools
MCP shifts supply-chain risk onto endpoints. Local MCP servers and dependencies are installed and updated directly on developer machines. That turns every laptop into a distribution and execution environment for third-party code.
This isn’t hypothetical. In September 2025, a targeted npm campaign hit packages with more than 2.6 billion weekly downloads. And in the Shai-Hulud incident, malware harvested credentials like GitHub tokens and cloud keys, then spread by injecting itself into other packages.
That’s not a CI failure. That’s developer laptops acting as infrastructure — and propagation nodes.
MCP enables lateral movement without exploits
Local MCP servers often execute OS commands or custom code under a developer’s ambient privileges. That creates a new kind of lateral movement:
No privilege escalation.
No suspicious binaries.
No malware-looking behavior.
Just a legitimate local service plane brokering high-value context with permissive egress. Red Hat’s own MCP security guidance calls out the difference in risk between local and remote MCP servers for exactly this reason.
What securing MCP actually means
The answer isn’t banning AI or locking down laptops. MCP is runtime infrastructure, and it needs to be governed like infrastructure. That means visibility into:
- What MCP servers exist locally
- What capabilities they expose
- Which processes invoke them
- What sensitive data they touch
- Where that context is sent
- Which credentials are in scope
There’s a difference between logging “python.exe made an HTTPS request” and understanding that an MCP tool chain assembled proprietary repo data and sent it to an external inference endpoint as part of an automated flow.
MCP didn’t introduce a new class of tools. It turns developer laptops into systems that can aggregate high-value internal context and transmit it externally, automatically, and at machine speed. MCP didn’t introduce a new class of tools. It introduced a new class of endpoint runtime infrastructure — one that sits outside traditional control planes but has access to their most sensitive data.