Model Context Protocol (MCP) servers have transformed AI from passive chatbots into action-capable agents. Claude can now execute tools, read files, query databases, and interact with your infrastructure. For developers, it's revolutionary. For security teams, it's a nightmare.

The problem? MCP servers everywhere like on laptops, in IDEs, in browser tabs and most organizations have no visibility into what they are or what they're doing. You've got an enterprise AI gateway controlling centralized traffic, but the moment an employee opens Claude Desktop, all governance evaporates.

Bifrost solves this with a two-layer approach: the Bifrost Gateway centralizes governance policies in your infrastructure, and Bifrost Edge enforces those same policies on every employee's machine. Together, they turn shadow MCP into governed MCP.

This is the article of how.

💻 The MCP Problem

Let's be clear about what MCP enables. A single MCP server can:

• Query your production databases directly
• Execute arbitrary code on developer machines
• Read sensitive files (API keys, credentials, source code)
• Connect to external services
• Modify infrastructure

This is intentional design. MCP servers are meant to be powerful. The protocol assumes a trusted environment.

But in enterprise? There is no single trusted environment anymore.

🔎 Why Default Solutions Fail

You might think: "We'll just block MCP access at the network layer."

But MCP can operate over stdio (local pipes), WebSockets, HTTP, and custom transports. Blocking one doesn't block the others. And even if you could block everything, you'd cripple the developers who should be using MCP as part of their workflow.

You might try: "We'll mandate that all MCP servers are pre-approved and centrally configured."

This works until your first developer says, "I need a custom tool for my use case." Suddenly you're the bottleneck. Teams build workarounds. Governance fails.

The real solution requires visibility at the endpoint + enforcement at the gateway, working together.

✅ Introducing Bifrost: Gateway + Edge

Bifrost's answer is a two-layer system:

Layer 1: The Gateway

The Bifrost Gateway sits in your infrastructure and provides centralized control over AI traffic:

• Virtual Keys: Define which models, providers, and features each team can access
• MCP Tool Filtering: Explicit allow-lists control which MCP tools are available
• Budgets & Rate Limits: Cost control and usage caps per team or customer
• Audit Logs: Immutable records of every AI request for compliance
• Guardrails: Content safety, PII detection, secret detection at the gateway level

This is where enterprise governance lives. The Gateway is your source of truth.

{
  "virtual_key": "vk-eng-team",
  "allowed_tools": [
    "github"
  ],
  "blocked_tools": [
    "file_system",
    "subprocess"
  ],
  "budget": {
    "monthly_spend": 5000,
    "alert_threshold": 4500
  }
}

But here's the catch: the Gateway only controls traffic that actually goes through it.

Layer 2: Edge (Endpoint Enforcement)

This is where Bifrost Edge changes the game.

Bifrost Edge is a lightweight agent that runs on each employee's machine (macOS, Windows, Linux) and does one thing: routes all AI traffic through your Bifrost Gateway automatically.

No configuration. No base URLs to change. No SDK modifications. Edge intercepts all AI requests at the machine level and runs them through the governance policies you've already defined in the Gateway.

Now here's what changes:

Before Bifrost Edge: Your engineer runs Claude Desktop → Direct connection to OpenAI → Unaudited, uncontrolled, outside your governance

After Bifrost Edge: Your engineer runs Claude Desktop → Routed through Edge → Routed through Gateway → Governed, audited, controlled

The governance you've already configured at the Gateway level now applies to every AI request, everywhere.

🔎 MCP Visibility

For the first time, you can see every MCP server configured across your organization:

• Which servers are connected to which tools?
• Who has access to what?
• What are those servers doing?

The Bifrost admin console shows:

MCP Servers Across Your Fleet
──────────────────────────────

Developer Machines: 47
  ✓ github-integration (27 devices)
  ⚠ custom-web-scraper (3 devices) — NOT APPROVED
  ✗ file-system-access (8 devices) — BLOCKED

Research Machines: 12
  ✓ arxiv-search (11 devices)
  ✓ paper-summarizer (9 devices)
  ⚠ experimental-tool (1 device) — PENDING APPROVAL

You now have visibility into shadow MCP. And visibility is the first step to control.

⚙️ MCP Governance

But Bifrost Edge goes further. You can approve or deny MCP servers at the device level:

Virtual Key: vk-engineers
Allowed MCP Servers:
  - github
  - internal-apis

Denied MCP Servers:
  - file-system
  - subprocess
  - custom-scrapers

When an engineer tries to connect an unapproved MCP server through Claude Desktop, Edge intercepts it:

1. Edge detects the MCP connection attempt
2. Checks against the Virtual Key's allowed list
3. If approved: Routes traffic through the Gateway (audited, controlled)
4. If denied: Blocks the connection and notifies the security team

This happens transparently, on the device, without breaking the user's workflow.

👀 MCP Oversight

The real power emerges when you combine MCP governance with Bifrost's guardrails:

Imagine an approved MCP server that reads files. Your guardrails are set to block PII exposure. A developer accidentally tries to send a file containing customer data through an AI request:

Request: "Analyze this file: customer_data.csv"

Edge Route:
  MCP server allowed? ✓ Yes
  Block: ✓ Request denied
  Notification: ✓ Sent to security team + user

The developer sees: "This file contains sensitive data that can't be analyzed. Contact security if you need access."

You see: Full audit trail, who tried to do what, when, and why.

💻 Real examples

Engineering Team + Code Tools

Your engineering organization uses:

• Approved: Claude Code, GitHub integration, internal API tools
• Blocked: File system access, arbitrary command execution, external service connectors

Configuration in the Gateway (one time):

{
  "virtual_key": "vk-engineering",
  "allowed_mcp_servers": [
    "github"
  ],
  "blocked_mcp_servers": [
    "file_system",
    "subprocess",
    "arbitrary_http"
  ],
  "budget": {
    "monthly": "$10,000",
    "alerts": ["$9,000", "$9,500"]
  }
}

Deploy Edge to all 150 engineers.

Result: Every engineer can use Claude and approved tools, with no per-machine setup, and no governance overhead.

When an engineer tries to use an unapproved server (because they found it online), Edge blocks it and Surface it in the admin dashboard. Your security team sees the attempt, reviews the tool, and either approves it or documents why it's blocked.

⚙️ The Implementation Example

Here's how this typically rolls out:

Week 1: Foundation

1. Set up Bifrost Gateway in your infrastructure (or use Bifrost's managed service)
2. Define Virtual Keys for each team
3. Configure MCP policies (allowed servers, blocked servers, guardrails)

This is a one-time investment. The policies you define here apply to all endpoints.

Week 2: Deployment

1. Register for Bifrost Edge alpha
2. Create deployment profile
3. Deploy to pilot group (50-100 employees)

Edge rolls out silently. Employees see a one-time browser sign-in prompt. Then it works.

Week 3+: Monitoring & Iteration

1. Monitor MCP connections in the admin dashboard
2. Review blocked attempts and unapproved servers
3. Approve legitimate tools, refine policies based on real usage
4. Scale rollout to rest of organization

The process is iterative because you're learning what tools your teams actually need.

🔎 The Enterprise View

From a CISO's perspective:

✅ Getting Started with Bifrost Edge

Bifrost Edge is in alpha. If you're managing AI at enterprise scale and drowning in shadow MCP:

1. Register for the Bifrost Edge alpha
2. Set up Bifrost Gateway if you haven't already
3. Define your MCP policies based on your team's needs
4. Deploy to a pilot group and see the dashboard light up with visibility

The story of AI governance isn't about choosing between security and productivity. It's about choosing infrastructure that enables both.

🖋️ Conclusion

AI is becoming critical to how work gets done. MCP servers are how AI becomes actionable. Enterprise teams need to govern both.

For too long, we've accepted a false choice: either employees use cutting-edge AI tools, or organizations maintain strict controls (which developers circumvent).

Bifrost offers a third path: governance that enables rather than restricts. Policies defined once, enforced everywhere, visible to everyone, invisible to users.

This is what enterprise AI infrastructure should look like.

🔗 Resources:

• Bifrost GitHub: https://github.com/maximhq/bifrost
• Bifrost Docs: https://docs.getbifrost.ai
• Bifrost CLI: npx -y @maximhq/bifrost-cli

💎 Star Bifrost ☆