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.

A 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, and MCP servers are a primary path through which that agent access reaches real systems.

What an MCP server is, and why it carries risk

An 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.

MCP 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 is explicit that a local server can execute arbitrary code, so connecting an untrusted server is equivalent to running untrusted software on the machine.

The risks fall into a few recurring categories:

• Overbroad access is the norm rather than the exception, because a new server is often granted whatever credentials make it work, a database token, a repository-wide key, or a cloud role, and those credentials are rarely scoped down or rotated afterward.
• Prompt injection and tool poisoning exploit how the model reads its inputs, since malicious content in a file, ticket, or web page can carry instructions an agent follows, and a malicious server can describe its tools in ways that steer the model toward unintended actions.
• Supply chain exposure comes with every install, because MCP servers pull in external packages, so a flaw or a planted payload upstream becomes a flaw on every machine that added the server.
• Lateral movement grows as agents chain servers together, reading a repository, querying a database, retrieving a secret, then posting to chat, so a single manipulated step can reach across many systems at once.

Why MCP servers on developer machines are hard to govern

MCP 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.

The supply chain underneath these servers is an equally serious problem. In April 2026, OX Security disclosed a command execution weakness 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.

Why existing controls miss them

Traditional 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.

Two 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.

How the Bifrost AI gateway and Bifrost Edge govern MCP servers

Governing 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 built by Maxim AI, is also an MCP gateway, so approved MCP servers connect through it, and it controls which tools each request can use and records every call. Bifrost Edge extends that control to the endpoint, where the servers are actually configured.

The 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.

See every MCP server across the fleet

Bifrost Edge inventories the MCP servers 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 today, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor.

Allow or deny each server, enforced on the device

Once 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.

Control which tools each person can call

On the gateway, MCP tool filtering 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 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.

Keep an audit trail of every tool call

Because 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 an organization already runs, so the inventory and the enforcement apply across the fleet rather than to whichever laptops happened to opt in.

Common questions about MCP server security

What is an MCP server?

An 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.

Are MCP servers a security risk?

MCP 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.

How do you govern MCP servers across an organization?

Governing 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.

Where this leaves engineering and security teams

MCP 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.

Pairing 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 and register there for alpha access.