{"slug": "the-mcp-server-problem-hiding-on-every-developer-laptop", "title": "The MCP server problem hiding on every developer laptop", "summary": "MCP servers, which allow AI tools to read files and call APIs, often run on individual developer machines with no oversight, creating security risks. The Bifrost AI gateway and Bifrost Edge aim to bring these servers under control across the fleet. Gartner predicts that by 2028, a quarter of enterprise breaches will trace back to AI agent abuse, with MCP servers being a primary attack path.", "body_md": "*MCP servers let AI tools read files, call APIs, and act inside internal systems, and most of them run on individual developer machines with no oversight. This guide explains the security risks of ungoverned MCP servers and how the Bifrost AI gateway and Bifrost Edge bring them under control across the fleet.*\n\nA developer can connect an MCP server to a coding agent in under a minute, granting an AI model the ability to read files, call internal APIs, and take actions inside the systems it touches. Useful as that is, each connection also creates an access path that the security team never reviewed and often cannot see. Across a team of any size, these connections accumulate on individual laptops, and most organizations have no record of which MCP servers exist, what they can reach, or which credentials they hold. Gartner has predicted that by 2028, a quarter of enterprise breaches will trace back to [AI agent abuse](https://www.gartner.com/en/newsroom/press-releases/2024-10-22-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2025-and-beyond), and MCP servers are a primary path through which that agent access reaches real systems.\n\nAn MCP server is a program that exposes tools, data, or actions to an AI model through the Model Context Protocol, the open standard that lets assistants and coding agents reach beyond their own context into files, APIs, databases, and other systems. The capability is what makes agents useful, and it is also what makes them risky, because a connected server gives a model a path into real infrastructure that is governed only by whatever the protocol and the surrounding setup happen to enforce.\n\nMCP was built for interoperability and ease of integration first, and it leaves much of the security enforcement to whoever deploys a server. Many MCP servers, especially the ones running locally on a laptop, operate with whatever access the developer granted and no check on individual tool calls unless controls are added around them. The official [MCP security guidance](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) is explicit that a local server can execute arbitrary code, so connecting an untrusted server is equivalent to running untrusted software on the machine.\n\nThe risks fall into a few recurring categories:\n\nMCP servers on developer machines are hard to govern because they are configured separately inside each app, on each machine, and by each person, which keeps them outside any central inventory. A server added to a coding agent on one engineer's machine is unknown to everyone else, and the configuration can change after anyone reviews it. Check Point Research demonstrated this in 2025 with a flaw in Cursor: once a user approved an MCP configuration, the IDE did not re-validate it, so an attacker could land a harmless config in a shared repository, wait for approval, and later swap in a command that ran on every subsequent launch. The issue was fixed in a later Cursor release, but the pattern it exposed is general.\n\nThe supply chain underneath these servers is an equally serious problem. In April 2026, OX Security disclosed a [command execution weakness](https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html) in the standard input and output transport of the official MCP software development kit, present across every major language version and affecting thousands of publicly reachable servers, a reminder that one design default in a widely used component propagates to every project built on it. A control that depends on reviewing each server by hand cannot keep up with that volume or that rate of change.\n\nTraditional controls miss MCP servers because they were built for a different shape of traffic. Network proxies and data loss prevention systems inspect what crosses the corporate network, yet a local MCP server can run entirely on the laptop over standard input and output, with nothing for the network to intercept. API gateways and web application firewalls assume predictable, developer-defined requests, so they cannot validate an agent's identity or judge whether a given tool call is appropriate in context. Blocklists depend on a known list of destinations, and with thousands of servers in circulation and new vulnerabilities disclosed almost weekly, no list keeps pace. Written policy states what engineers should do, but a document does not stop a tool call at the moment it runs.\n\nTwo facts follow from this: MCP servers are configured on the endpoint, so visibility and enforcement of which servers exist have to happen on the endpoint as well; and because the tool calls themselves run through whatever connects the agent to the server, controlling how an approved server is used belongs at a gateway that every call passes through.\n\nGoverning MCP servers well takes the same two layers that govern any AI traffic: a place to define and enforce policy, and a way to apply that policy on every machine. Bifrost, the [open-source AI gateway](https://github.com/maximhq/bifrost) built by Maxim AI, is also an [MCP gateway](https://docs.getbifrost.ai/mcp/overview), so approved MCP servers connect through it, and it controls which tools each request can use and records every call. [Bifrost Edge](https://docs.getbifrost.ai/edge/overview) extends that control to the endpoint, where the servers are actually configured.\n\nThe two layers cover the two halves of the problem. Edge identifies which MCP servers exist on the fleet and blocks the ones that are not allowed, and the gateway governs how the approved servers are used, down to the individual tool and the individual person.\n\n[Bifrost Edge inventories the MCP servers](https://docs.getbifrost.ai/edge/mcp-governance) configured inside each AI app on every machine and builds a live inventory of which servers are present, on which apps, and across how many devices. For many organizations this is the first complete answer to a basic question about which MCP servers are actually running on the fleet, replacing guesswork with real data. MCP discovery covers the [AI apps that support the protocol](https://docs.getbifrost.ai/edge/supported-applications) today, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor.\n\nOnce the inventory exists, administrators allow or deny each MCP server individually, and Edge enforces that decision on the machine, even for an app that had the server configured before the policy existed. When Edge detects a server it has not seen, it raises a pending approval in the admin console, where administrators decide whether new servers stay allowed or blocked while a decision is open. A denied server cannot be used, rather than being discouraged by a policy no one enforces.\n\nOn the gateway, [MCP tool filtering](https://docs.getbifrost.ai/features/governance/mcp-tools) decides which tools an approved server actually exposes, per virtual key. The starting point is deny by default, so a virtual key with no MCP configuration receives no tools, and an administrator builds an explicit list of the approved clients and tools each key may use. [Per-user OAuth](https://docs.getbifrost.ai/mcp/auth/per-user-oauth) then ties each upstream connection to the individual using it, so a person's tool calls run under their own scoped credentials instead of a single shared token that grants the same broad access to everyone.\n\nBecause approved MCP traffic flows through Bifrost, every tool call is recorded with the identity behind it, what was called, and what came back. That record turns an agent action from an unattributable event into something a security or compliance team can review, which is exactly what the scattered, machine-by-machine setup made impossible before. Edge reaches every machine through the [device management platform](https://docs.getbifrost.ai/edge/deployment-mdm) an organization already runs, so the inventory and the enforcement apply across the fleet rather than to whichever laptops happened to opt in.\n\nAn MCP server is a program that gives an AI model access to specific tools, data, or actions through the Model Context Protocol. A coding agent might use one MCP server to read a repository, another to query a database, and another to file an issue, with each server defining what the model is allowed to do.\n\nMCP servers are a security risk when they run without oversight, because they grant AI models real access to internal systems and often hold broad, long-lived credentials. The risk lies not in the protocol itself but in ungoverned use, meaning servers configured on individual machines, with access no one reviewed and tool calls no one can see.\n\nGoverning MCP servers across an organization takes both visibility and enforcement. An endpoint layer such as Bifrost Edge inventories the servers configured on every machine and enforces which ones are allowed, while an MCP gateway such as Bifrost controls which tools each person can call and records every call for audit.\n\nMCP servers are now part of how software gets built, and that is not going to reverse. The teams that stay ahead of the risk treat it as a visibility problem first and an enforcement problem second, governing servers where they are configured and where their tool calls run rather than trusting that a policy document will hold.\n\nPairing the Bifrost AI gateway with Bifrost Edge covers both halves: the gateway controls which tools each person can use and logs every call, and Edge, currently in alpha, brings every MCP server on every machine into one inventory with enforcement on the device. Teams weighing the risk of ungoverned MCP servers can see how the combined approach works on the [Bifrost Edge overview](https://docs.getbifrost.ai/edge/overview) and register there for alpha access.", "url": "https://wpnews.pro/news/the-mcp-server-problem-hiding-on-every-developer-laptop", "canonical_source": "https://dev.to/marcuswwchen/the-mcp-server-problem-hiding-on-every-developer-laptop-3blh", "published_at": "2026-06-22 06:17:20+00:00", "updated_at": "2026-06-22 06:39:53.029970+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "developer-tools", "ai-policy"], "entities": ["MCP", "Bifrost AI gateway", "Bifrost Edge", "Gartner", "Check Point Research", "Cursor", "OX Security", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/the-mcp-server-problem-hiding-on-every-developer-laptop", "markdown": "https://wpnews.pro/news/the-mcp-server-problem-hiding-on-every-developer-laptop.md", "text": "https://wpnews.pro/news/the-mcp-server-problem-hiding-on-every-developer-laptop.txt", "jsonld": "https://wpnews.pro/news/the-mcp-server-problem-hiding-on-every-developer-laptop.jsonld"}}