How Untracked MCP Servers Spread on Developer Machines

TL;DR

• Developers can install untracked MCP servers in seconds by editing plain JSON files in user space without triggering administrative alerts.
• Local MCP servers run as child processes that inherit developer credentials, environment variables, local file access, and network tokens.
• Traditional Endpoint Detection and Response (EDR) and Mobile Device Management (MDM) tools fail to flag MCP servers because they execute via trusted runtimes like Node.js and Python.
• Security risks include context injection, tool poisoning, silent updates, and plaintext credential exposure mapped to the OWASP Top 10 for Agentic Applications.
• Governing local agent tools requires an architectural pairing: Bifrost as the central AI gateway and control plane, coupled with Bifrost Edge to discover, inventory, and enforce device-level allowlists.

A software engineer running an AI-assisted development environment can connect an external language model to local file systems, internal code repositories, and production databases in less than thirty seconds. Because the Model Context Protocol specification standardizes communication between large language models and local tools, configuring a server requires only adding a brief JSON stanza to an application settings file. This design accelerates developer productivity, yet it also permits untracked MCP servers to proliferate across company laptops without security review or administrative visibility. Bifrost, an open-source AI gateway built in Go by Maxim AI, acts as a centralized policy engine for AI requests, while endpoint extensions allow security teams to manage local tool sprawl. Understanding how these servers enter development environments is the first step toward reclaiming operational control.

The Rise of the Model Context Protocol in Development Environments

The Model Context Protocol (MCP) is an open standard designed to replace bespoke tool integrations by giving language models a unified interface for data retrieval and tool execution. Originally introduced by Anthropic in late 2024 and later contributed to open-source governance under LF Projects, MCP uses JSON-RPC 2.0 messages over standard input and output (stdio) or Server-Sent Events (SSE) and Streamable HTTP.

Before MCP gained traction, connecting an IDE or desktop assistant to an external service required writing custom glue code, managing proprietary API wrappers, and maintaining bespoke authentication handshakes. MCP simplified this architecture by splitting responsibility into three distinct entities:

• MCP Hosts: Applications that orchestrate the workflow and provide context, such as Cursor, Claude Desktop, Claude Code, or VS Code extensions.
• MCP Clients: Protocol-aware components within the host application that negotiate capabilities, query available tools, and send execution requests.
• MCP Servers: Lightweight background programs that expose resources (data feeds), prompts (templated instructions), and tools (executable functions) to the client.

Because an MCP server translates generic model commands into system calls, database queries, or web requests, it gives models direct agency over the operating system. If a developer needs Claude Desktop to read a Postgres database, inspect local Docker containers, or post messages to Slack, adding an MCP server bridges the gap immediately. This architectural convenience has caused adoption to surge, creating a shadow AI footprint across engineering teams.

How Untracked MCP Servers Get Installed on Developer Endpoints

Untracked MCP servers infiltrate developer machines through frictionless, user-level installation paths that bypass operating system permission prompts. Unlike traditional software installations, setting up an MCP server rarely involves running an installer binary or requesting root privileges.

Instead, a developer opens the configuration file of their preferred AI tool and inserts a JSON block pointing to an executable command. The host application parses this configuration, starts the specified executable in the background as a subprocess, and communicates with it over standard input and output channels.

The following example shows a typical configuration in a developer settings file:

{
  "mcpServers": {
    "filesystem-access": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/developer/projects"]
    },
    "internal-database": {
      "command": "uvx",
      "args": ["mcp-server-postgres", "--connection-string", "postgresql://admin:[e-mail]:5432/main"]
    },
    "developer-git": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "/Users/developer:/data", "mcp/git"]
    }
  }
}

This installation pattern succeeds without administrative oversight due to three specific factors:

1. User-Space Configuration Paths: Configuration files reside entirely within user directories, such as ~/.cursor/mcp.json or ~/Library/Application Support/Claude/claude_desktop_config.json. Modifying these files requires no elevated operating system privileges.
2. Dynamic Package Execution: Package runners like npx (Node.js) and uvx (Python) download and run packages dynamically on demand. The developer does not maintain a pinned local installation or record dependencies in a tracked project repository.
3. Implicit Execution Hooks: Modern AI-assisted editors often offer one-click interface buttons to install recommended tools. When an engineer clicks an approval modal inside an editor, the application writes directly to local JSON configuration files on their behalf.

AI Client Application	Primary Configuration File Path	Default Transport Mechanism	Elevation Required
Claude Desktop (macOS)	~/Library/Application Support/Claude/claude_desktop_config.json	Local stdio subprocess	No
Claude Desktop (Windows)	%APPDATA%\Claude\claude_desktop_config.json	Local stdio subprocess	No
Cursor IDE	~/.cursor/mcp.json	Local stdio or HTTP/SSE	No
Claude Code CLI	~/.claude.json or .claude/config.json	Local stdio	No
Continue (VS Code)	~/.continue/config.json	Local stdio	No

Why Traditional Endpoint Security Fails to Detect Shadow MCP Tooling

Enterprise security architectures rely on Endpoint Detection and Response (EDR) sensors, Mobile Device Management (MDM) profiles, and Cloud Access Security Brokers (CASBs) to prevent unauthorized software deployment. However, untracked MCP servers operate in a blind spot between endpoint monitoring and network egress controls.

First, the processes running these servers are trusted development runtimes. When an MCP host starts an unmonitored server, the EDR agent observes node, python, uv, or docker launching a subprocess. Because software engineers execute scripts and run local compilers as part of their routine duties, security heuristics treat these background invocations as benign activity. The EDR cannot distinguish between an engineer running test suites with Node.js and an engineer running an ungoverned MCP tool that queries production cloud buckets.

Second, the primary communication channel never crosses a traditional network interface. Local MCP servers rely heavily on stdio pipes established between the parent AI host and the child tool process. The operating system handles this communication through anonymous file descriptors in memory:

[Developer Workspace]
       │
       ▼
┌──────────────────┐      stdio (stdin/stdout)      ┌───────────────────┐
│ AI Client / Host │ ◄────────────────────────────► │ Local MCP Server  │
│ (Cursor, Claude) │    Anonymous Unix Pipe/Memory  │ (Node.js, Python) │
└────────┬─────────┘                                └─────────┬─────────┘
         │                                                    │
         │ API Inferences (HTTPS)                             │ Host Access / Child Shell
         ▼                                                    ▼
┌──────────────────┐                                ┌───────────────────┐
│ Model Provider   │                                │ Local Files, SSH, │
│ (OpenAI, Claude) │                                │ Internal APIs     │
└──────────────────┘                                └───────────────────┘

Because traffic travels across internal pipes rather than TCP/IP network sockets, network intrusion detection systems and web proxies record zero events during tool invocation.

Finally, MCP servers inherit the full execution context of the user account running them. When a developer starts a local server, that server automatically inherits the developer's shell environment variables, unencrypted SSH keys, active cloud provider sessions (such as AWS STS temporary tokens), and read permissions across the user's hard drive. An untracked tool therefore gains high-level enterprise access without ever generating an authentication log entry in the identity provider.

Security Risks of Ungoverned Local MCP Servers

When tools execute autonomously inside an endpoint environment, security boundaries collapse. The risks associated with untracked local tools align directly with the OWASP Top 10 for Agentic Applications, transforming local developer machines into high-yield targets.

Context Injection and Tool Poisoning

Unlike traditional APIs that require strict parameter validation, MCP servers present natural language descriptions of their tools directly into the language model context window. If a developer connects an untracked MCP server designed to search developer documentation, a compromised or malicious server can embed prompt injection instructions within tool descriptions or responses. When the host language model ingests this poisoned context, it can be coerced into calling other installed tools without the developer realizing it, such as reading SSH keys and sending them as arguments to an external web request.

Dynamic Dependency Rug Pulls

Because many developers configure tools using commands like npx -y package-name, the package runner pulls the latest available version from public registries on every cold start. If an open-source MCP server maintainer account is compromised, an attacker can publish an update that introduces credential-scraping logic. The developer launches their editor as usual, the updated package runs without notification, and sensitive environment data leaves the machine.

Plaintext Credential Exposure

Local configuration files require static parameters to connect to remote systems. Developers routinely hardcode database passwords, GitHub personal access tokens, and cloud API keys directly into mcp.json files on their disk. These configuration files are not protected by operating system keychains, making them trivial targets for any basic malware or repository scraping script running on the endpoint.

Risk Category	Technical Vector	Blast Radius	OWASP Agentic Mapping
Tool Poisoning	Hidden directives embedded in tool manifests	Silent exfiltration through secondary tools	ASI01 (Agent Goal Hijack), ASI02 (Tool Misuse)
Silent Updates	Dynamic package pulling via npx or uvx	Malicious code execution in user space	ASI04 (Agentic Supply Chain Vulnerabilities)
Context Leaks	Unsanitized prompts containing secrets	Sensitive tokens shared with public model providers	ASI06 (Memory & Context Poisoning)
Privilege Escalation	Inherited developer shell environment	Direct access to internal databases, cloud APIs, and Git	ASI03 (Identity & Privilege Abuse)

Discovering and Inventorying Fleet-Wide MCP Servers

Security teams attempting to quantify their shadow AI exposure often start by writing localized discovery scripts. Because MCP servers declare themselves within predictable file structures, administrators can audit developer laptops to determine the scope of tool usage.

A security engineer can run a localized shell scan across macOS machines to parse known host configurations:

#!/usr/bin/env bash
# Audit known MCP configuration files on macOS endpoints

CONFIG_PATHS=(
  "$HOME/.cursor/mcp.json"
  "$HOME/Library/Application Support/Claude/claude_desktop_config.json"
  "$HOME/.claude.json"
  "$HOME/.continue/config.json"
)

echo "=== Discovered MCP Server Configurations ==="

for config in "${CONFIG_PATHS[@]}"; do
  if [ -f "$config" ]; then
    echo "Found configuration: $config"
    # Extract defined server names, commands, and arguments
    jq -r '.mcpServers | to_entries[] | "  - Server: \(.key)\n    Command: \(.value.command) \(.value.args | join(" "))"' "$config" 2>/dev/null
  fi
done

Running such an audit script on a modern engineering team typically reveals dozens of unvetted servers, ranging from innocent local file searchers to untracked connections pointing at staging databases.

However, periodic manual scanning fails as a long-term strategy. Developers continuously add new tools, update paths, and test emerging coding agents in the terminal. Script-based audits provide only a snapshot in time; they cannot enforce organizational policy, block dangerous tools before execution, or maintain compliance trails.

Bridging the Gap: AI Gateway and Endpoint Governance with Bifrost

Governing local AI tooling requires bridging the gap between infrastructure policies and developer machines. Security teams cannot simply block AI editors without undermining engineering output, nor can they permit unmonitored scripts to execute unchecked. The effective solution combines centralized model management with active endpoint enforcement.

Bifrost serves as the centralized AI gateway and control plane, managing outbound model requests, routing rules, and enterprise compliance. Operating as a high-performance Go gateway, Bifrost adds only 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks. At the gateway level, administrators configure governance structures such as virtual keys, team-level budgets, model routing, and immutable audit logs. Furthermore, Bifrost operates as an MCP gateway that unifies enterprise-sanctioned tools behind secure endpoints with federated authentication.

Yet a gateway alone governs only the traffic explicitly directed toward it. If an engineer runs an untracked local model or desktop application, that traffic bypasses network proxies entirely. To solve this dilemma, Bifrost Edge extends the gateway's control plane directly down to developer laptops.

Currently in early access alpha, Bifrost Edge runs natively in the background on macOS, Windows, and Linux. Deployed fleet-wide through existing MDM platforms, Edge brings endpoint visibility and policy enforcement directly to the developer environment without requiring per-application reconfiguration.

┌─────────────────────────────────────────────────────────────────────────┐
│                           Bifrost AI Gateway                            │
│                     (Control Plane & Policy Engine)                     │
│                                                                         │
│   • Virtual Keys & Budgets            • Guardrails & Data Redaction     │
│   • Model Routing & Provider Failover • Centralized Audit Logging       │
└────────────────────────────────────▲────────────────────────────────────┘
                                     │
           Centralized Policies, Sync, and Governed Model Traffic
                                     │
┌────────────────────────────────────▼────────────────────────────────────┐
│                    Developer Machine with Bifrost Edge                  │
│                                                                         │
│  ┌──────────────────────────┐             ┌──────────────────────────┐  │
│  │ AI Client Applications   │             │ Local & Remote MCP Tools │  │
│  │ • Cursor     • Claude    │             │ • Git        • Database  │  │
│  │ • Codex      • Gemini    │             │ • Filesystem • Custom    │  │
│  └─────────────┬────────────┘             └────────────▲─────────────┘  │
│                │                                       │                │
│                ▼                                       │                │
│       ┌────────────────────────────────────────────────┴─────────┐      │
│       │                       Bifrost Edge                       │      │
│       │  • Discovers and inventories local MCP servers           │      │
│       │  • Enforces Device-Level Allow/Deny decisions            │      │
│       │  • Routes model traffic transparently through Gateway    │      │
│       └──────────────────────────────────────────────────────────┘      │
└─────────────────────────────────────────────────────────────────────────┘

The combined architecture operates through dedicated capabilities:

1. Automatic App and MCP Discovery: Bifrost Edge continuously inspects host applications on the machine, including Cursor, Claude Desktop, Claude Code, and terminal agents. It identifies which MCP servers are configured, catalogs the tools they expose, and reports them to the centralized console.
2. Device-Level Enforcement: In accordance with MCP governance configurations, Bifrost Edge stops unauthorized MCP servers directly on the machine. Denied servers are terminated before they can execute commands or read local files.
3. Fleet-Wide Deduplication: In the approvals dashboard, administrators view an aggregated inventory of all tools used across the engineering organization. If forty engineers install the same GitHub MCP server, the admin reviews the tool once and applies an allow or deny rule fleet-wide.
4. Endpoint Security and Guardrails: Beyond basic routing, Bifrost applies governance and security controls centrally, and Bifrost Edge extends that same governance and security to AI traffic on employee machines, with endpoint enforcement on each device. This ensures that gateway-level guardrails for secrets detection and PII redaction protect prompts generated by local desktop editors before data departs the network.

Architectural Layer	Deployment Location	Governance Responsibility	Technical Scope
Bifrost Gateway	Cloud / VPC / On-Prem	Control Plane & Policy Engine	Provider routing, rate limits, virtual keys, model failover
Bifrost Edge	Developer Endpoints	Last-Mile Discovery & Enforcement	App governance, MCP governance, local device allowlists
AI Client (Host)	Developer Endpoints	User Interface	Context aggregation, prompt rendering, IDE integration

Operationalizing Developer AI Tooling Governance

Restoring visibility over developer machines requires establishing repeatable administrative habits. Organizations can secure their environments without hindering developer productivity by deploying a structured governance program.

       Step 1: Fleet Inventory
  Deploy endpoint discovery via MDM
  Audit installed hosts and MCP tools
                 │
                 ▼
       Step 2: Establish Baselines
  Categorize discovered tools (Approve/Deny)
  Deduplicate servers in centralized console
                 │
                 ▼
       Step 3: Centralize Credentials
  Remove hardcoded database/API secrets from disk
  Enforce virtual keys and central auth proxies
                 │
                 ▼
       Step 4: Continuous Enforcement
  Apply automated device blocking via Bifrost Edge
  Inspect model traffic using gateway guardrails

1. Automate Deployment via Existing Device Management

Attempting to configure developer endpoints manually guarantees drift. IT teams should deploy Bifrost Edge via MDM frameworks such as Microsoft Intune, Jamf, Kandji, or Omnissa Workspace ONE. Because MDM delivery applies managed configurations pointing to the company gateway, endpoints register automatically upon user single sign-on without manual API key sharing.

2. Remove Hardcoded Secrets from Endpoints

Audit developer machines for configuration files containing unencrypted tokens. Instead of allowing developers to put static database passwords or private API tokens into claude_desktop_config.json, route external integrations through the central gateway. Bifrost supports managed tool hosting and federated authentication, ensuring that underlying credentials remain secured inside enterprise key vaults rather than sitting in user directories.

3. Establish a Curated Tool Catalog

Transition the organization from an unmonitored default state to an intentional approval workflow. Using the devices dashboard, security teams can establish baseline allowlists for common developer tools (such as approved Git servers and read-only documentation indexers) while automatically blocking unvetted file system tools or untrusted npm packages.

Frequently Asked Questions

What is an untracked MCP server?

An untracked MCP server is a local or remote tool executed by an AI client application (such as Cursor, Claude Desktop, or Claude Code) without registration, security review, or administrative visibility. These servers run in user space, translate model instructions into local actions, and operate outside traditional IT inventory systems.

How do developers install MCP servers without administrative privileges?

Developers configure MCP servers by editing user-space JSON files located in their home directories. When the AI host application reads this file, it starts the server as a local child process using developer tools like Node.js, Python, or Docker, which developers already have permission to execute.

Why do endpoint detection and response tools miss MCP servers?

EDR solutions monitor for known malicious binaries and anomalous operating system behaviors. Because MCP servers launch through trusted development interpreters like node or uvx and communicate with host applications over standard input/output (stdio) pipes in memory, EDR agents classify the activity as standard development work.

What are the main security risks of shadow MCP servers?

The primary risks include tool poisoning, prompt injection exploits, dynamic dependency rug pulls, and plaintext credential exposure on disk. Compromised servers can access local files, exfiltrate sensitive environment variables, or execute unauthorized commands with the developer's permissions.

How does Bifrost Edge detect untracked MCP servers on developer machines?

Bifrost Edge runs quietly in the background on employee devices and inspects known AI host configurations. It catalogs configured MCP servers, maps the tools they expose, and deduplicates this inventory in a centralized console, allowing administrators to enforce device-level allow and deny policies.

Can security teams block specific MCP servers without disabling the AI editor?

Yes. By deploying Bifrost Edge alongside the central AI gateway, administrators can establish granular allowlists. The host editor continues to function normally for coding and model queries, while blocked MCP servers are prevented from executing on the endpoint.

Next Steps in Securing Developer AI Infrastructure

Untracked MCP servers represent an expanding blind spot in enterprise environments. As AI tools evolve from conversational chatbots into autonomous agents capable of system execution, securing the endpoint becomes as critical as securing the underlying model. Platform teams must implement architecture that provides total visibility into local tooling without interrupting developer velocity.

Engineering leaders evaluating strategies to govern developer AI traffic can explore the Bifrost open-source repository on GitHub or request a Bifrost demo to learn how the AI gateway and Bifrost Edge provide comprehensive control across enterprise environments. For broader architectural resources and best practices, teams can consult the Bifrost resources hub.

Sources

• Model Context Protocol Specification (modelcontextprotocol.io)
• OWASP Top 10 for Agentic Applications (genai.owasp.org)
• Anthropic: Introducing the Model Context Protocol
• Bifrost Edge Documentation (docs.getbifrost.ai)