Bifrost is the open-source AI gateway that mitigates MCP security risks from a central control plane, while Bifrost Edge carries that same governance to every endpoint machine.
Runtime tool discovery is the headline feature of the Model Context Protocol (MCP): an AI application can find and invoke external tools on the fly. The catch is that each MCP server it connects to becomes a new trust boundary capable of reading files, reaching APIs, and shipping data outside the organization. Look at the risks that result from this design (servers nobody signed off on, tools handed too much permission, credentials that escape, and AI usage on staff laptops that no one watches) and you find governance and visibility gaps rather than coding bugs. That distinction matters, because a control plane combined with an endpoint layer is precisely what closes those gaps. Maxim AI built Bifrost in Go as an open-source MCP gateway; it governs MCP and model traffic from one central point, and Bifrost Edge pushes the same governance out to wherever employees run AI tools. What follows is a walkthrough of the MCP security risks that an AI gateway and an endpoint governance layer can genuinely reduce, and the controls that do the reducing.
What MCP Security Risks Are
Connect an AI application to external tool servers over the Model Context Protocol and you introduce a class of vulnerabilities known as MCP security risks. The root cause is runtime behavior: an agent reaches any server it can and invokes whatever tools that server exposes, which means a single server might surface confidential data, take actions in a user's name, or slip untrusted content into the model's context. For enterprises, the questions with the highest stakes are simple to state: which servers and tools are permitted, who is allowed to call them, and whether anyone can actually see either.
These failure modes are now being catalogued formally across the industry. Shadow MCP servers, tool poisoning, token mismanagement, and excessive permissions all appear in the OWASP MCP Top 10, a list of the most critical ways MCP goes wrong. Complementing that, the NSA's MCP security design considerations spell out what an organization should be controlling once agents start calling external servers, and the official MCP security best practices cover guidance at the protocol level. Infrastructure cannot solve every item in those frameworks, so this post stays with the subset that an AI gateway such as Bifrost plus an endpoint governance layer is positioned to handle.
Why MCP Widens the Enterprise Attack Surface
In the pre-MCP world, an agent shipped with a small, fixed toolset baked straight into the application. MCP changes that arrangement: tools now arrive from servers at runtime, and few organizations track which servers their people are actually using. Wiring a third-party MCP server into Claude Desktop or Cursor takes an employee only a few minutes, after which that server may be holding OAuth tokens, executing system commands, and reading local files without any policy sitting between it and the machine.
Two structural gaps compound the problem:
- Endpoint AI sits largely outside the view of security teams. Out on the laptop, beyond the data center and the reach of conventional monitoring, desktop apps, browser AI, and coding agents all talk to MCP servers. Teams have a name for this unwatched activity: shadow AI.
- A gateway can only govern whatever traffic is routed through it. Point a coding agent directly at an MCP server and that traffic skips the control plane entirely, leaving allow-lists, budgets, and guardrails with nothing to act on.
One model lets Bifrost cover both gaps at once: the AI gateway serves as the control plane where policy gets defined and enforced, and Bifrost Edge ferries that identical policy out to every machine. It is this pairing that turns the MCP security risks below into something you can actually mitigate instead of merely worry about.
The MCP Security Risks a Gateway and Endpoint Layer Can Mitigate
The table below maps each addressable MCP security risk to the control that mitigates it. The AI gateway handles centralized governance; Bifrost Edge enforces that policy on the endpoint.
| MCP security risk | How an AI gateway plus endpoint governance mitigates it |
|---|---|
| Shadow MCP servers (unapproved servers wired into AI apps) | Edge inventories every MCP server across the fleet and enforces allow or deny on each device |
| Excessive tool permissions | Tool filtering is deny-by-default per virtual key; tool groups expose only curated subsets |
| Untrusted servers reaching the model | Only sanctioned servers are connected centrally; denied servers are blocked on the endpoint |
| Credential and secrets leakage in prompts | Guardrails scan prompts and responses for secrets and PII before data leaves the machine |
| Scattered MCP credentials and token mismanagement | The gateway centralizes MCP auth so tokens are not stored per app on laptops |
| Prompt injection and tool-poisoning content | Content-safety guardrails inspect prompts and responses; the same profiles apply to endpoint AI |
| No audit trail of MCP usage | Gateway audit logs capture every governed request; Edge brings endpoint AI under the same logging |
Each mitigation depends on two parts working together, and the sections ahead break down what the control plane contributes and what the endpoint layer adds.
How the Bifrost AI Gateway Governs MCP Traffic
For MCP security, the control plane is the Bifrost AI gateway. Functioning as an MCP gateway, it positions itself between AI applications and the tool servers they reach, pulling connection, authentication, and policy into a single point so that approved MCP traffic gets governed there. Every control described below originates and is enforced at this layer.
Limit which tools an agent can call
Few MCP risks get mentioned as often as over-permissioned tool access, and the gateway counters it by defaulting to deny. Under MCP tool filtering, a virtual key carrying no MCP configuration surfaces zero tools; you have to explicitly allow-list the clients and tools that each key is permitted to use. Larger organizations get MCP tool groups, which package curated subsets of tools and bind them to virtual keys, teams, users, or providers, ensuring an agent only ever sees the union of tools its identity is entitled to when a request comes in.
Centralize MCP credentials and authentication
A steady source of MCP compromise is mishandled tokens: hard-coded keys and long-lived secrets strewn across local app configs. Bifrost pulls MCP authentication into one place, supporting static headers, OAuth 2.0, per-user headers, and per-user OAuth. Instead of being copied into every app on every laptop, credentials sit with the gateway and are tied to the caller's identity, which removes a whole category of credential-exposure risk.
Catch secrets and sensitive data before they leave
API keys, access tokens, and personal data can all ride out of the organization inside prompts headed for MCP tools. To counter that, the guardrails system applies content controls while traffic is in flight: secrets detection leans on Gitleaks-backed rules to catch leaked credentials in both requests and responses, while a custom-regex PII template flags emails, phone numbers, and similar identifiers. The same system also offers content-safety providers (AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, and others) that layer additional defense against prompt injection and tool-poisoning content. Think of all this as cutting risk down rather than closing it off completely, because semantic-level injection remains a moving target.
Keep an audit trail of every governed request
When no one has logged which tools ran or what data went out, MCP incidents tend to slip by unnoticed. Bifrost answers this with immutable audit logs aligned to SOC 2, GDPR, HIPAA, and ISO 27001 requirements, handing security teams a traceable record of MCP and model activity. Where deployment constraints are strict and the industry is regulated, the Bifrost Enterprise feature set adds RBAC, SSO, and in-VPC options on top.
How Bifrost Edge Extends MCP Governance to the Endpoint
Traffic that never reaches a gateway is traffic a gateway cannot govern, and shadow MCP servers fall squarely into that blind spot. Bifrost Edge fills it by taking the governance you set up in the gateway and extending it to every machine, so the AI people genuinely rely on lands under the same policy on its own. Note that Bifrost Edge is currently in alpha.
Discover and control shadow MCP servers
On each machine, Edge inspects the MCP configuration of the AI apps it supports and assembles a live inventory spanning the whole fleet: which servers are set up, where they live, and how many devices carry them. From there, MCP governance in Edge gives administrators per-server allow or deny decisions that take effect on the device itself, so a denied server stays unusable even when an app had it configured before the policy came along. Today's discovery reaches the major MCP-capable AI apps, Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor among them.
Apply the same guardrails everywhere
Routing endpoint AI traffic through the gateway means every guardrail you have already set up flows automatically to desktop apps, browser AI, and coding agents. Right on the laptop, the endpoint security layer runs secrets detection, PII redaction, and content safety before any prompt reaches a model and before any response comes back, and it does so without extra setup on the device. The gateway keeps the policy engine; what Edge does is widen the pool of traffic that the same protection covers.
Roll out across the fleet without per-app setup
Fleet-wide deployment is what Edge is designed for, riding the device management platforms you already run, including Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud. A managed configuration aims each machine at the organization's Bifrost, the user authenticates a single time through SSO, and governance comes online for every supported stream of AI traffic. Nothing about base URLs has to change and no SDKs need swapping, and that is what keeps endpoint MCP governance workable at scale.
Implementing MCP Security with Bifrost
The pragmatic order of rollout is gateway controls first, endpoint layer second:
- Send approved MCP traffic through the gateway. Hook your sanctioned MCP servers up to Bifrost and configure virtual keys as the governance entity that carries budgets, rate limits, and tool access.
- Default tool policy to deny. Lean on tool filtering and tool groups so that each key, team, or user is shown only the tools it actually requires.
- Switch on guardrails. Turn up secrets detection and PII rules, then attach a content-safety provider for layered prompt-injection defense.
- Start logging for audit. Record every governed MCP and model request so you have what you need for compliance and incident response.
- Push out to the endpoint with Edge. Roll Bifrost Edge through MDM to take stock of shadow MCP servers, apply per-server decisions on each device, and bring the same guardrails to endpoint AI.
Teams looking to optimize MCP at scale will find the gateway capabilities laid out in greater depth in the MCP gateway resource guide.
Frequently Asked Questions About MCP Security
What is a shadow MCP server?
It is an MCP server that someone has hooked into an AI app without any security review or central sign-off. Running beyond formal governance and frequently configured with loose permissions, such a server escapes the notice of security teams right up until something surfaces it. Bifrost Edge takes inventory of these servers across the fleet and applies allow or deny decisions on each device.
Can an AI gateway stop prompt injection in MCP tools?
It chips away at prompt-injection and tool-poisoning risk by running prompts and responses through content-safety guardrails and by capping which tools an agent may invoke, yet it is not a complete fix by itself. Because injection at the semantic level keeps evolving, treat guardrails as one layer within a defense-in-depth approach that also includes least-privilege tool access and auditing.
How do you control which MCP tools an agent can use?
Bifrost defaults to deny: until you explicitly allow-list them, a virtual key surfaces no MCP tools at all, and tool groups let you bind curated tool subsets to keys, teams, and users. Only what a given identity is entitled to ever reaches the model when a request arrives.
Does this cover AI tools running on employee laptops?
It does. While the Bifrost AI gateway governs configured traffic, Bifrost Edge stretches that governance out to desktop apps, browser AI, and coding agents on each machine. Edge sits in alpha today and ships fleet-wide via MDM platforms.
Securing MCP Across Your Stack with Bifrost
Strip MCP security risks down to their core and they are governance problems: servers that were never approved, tool access that runs too broad, credentials that leak, and endpoint usage no one governs. Centrally, the Bifrost AI gateway addresses them through deny-by-default tool policy, centralized MCP authentication, guardrails, and audit logging; Bifrost Edge then carries that control onto every machine so shadow MCP servers get found and governed right at the source. Want to watch the gateway and endpoint layer cooperate to mitigate MCP security risks on your own stack? book a demo with the Bifrost team.
Top comments (0)