You have API keys in a vault, a budget dashboard, and a policy doc that lists which models are approved. Procurement signed off. On paper, enterprise AI is under control.
So answer one question: who called which model last night, with whose budget, through which MCP tool?
Nobody can say.
The calls nobody is counting
Enterprise AI usage did not arrive as one system. It arrived as a hundred small ones.
A data team wires GPT-5.5 into a pipeline with a key from the shared vault. A product squad ships a feature on Claude through its own SDK. An agent framework spins up MCP servers that call tools, read files, and hit internal APIs. Each of these is a real AI call leaving your infrastructure, and almost none of them pass through a single point where you could see them, price them, or stop them.
The result is not a security hole in the dramatic sense. It is worse: it is an accounting gap. You cannot answer basic questions. Which teams are spending what. Which models are actually in use versus approved. Which MCP tools an agent is allowed to invoke, and which it quietly invokes anyway.
Most teams try to close this with process. A spreadsheet of keys. A wiki page of rules. A quarterly review. Process does not enforce anything at request time, and request time is the only time that matters.
The fix is not another policy. It is a control plane that every LLM and MCP call has to pass through.
One base URL in front of every model
Bifrost is an open-source AI gateway built by Maxim AI, written in Go and licensed Apache 2.0. It sits in front of your model providers and gives you one OpenAI-compatible API for all of them: over 1000 models across every major provider behind a single endpoint.
The adoption cost is deliberately close to zero. You do not rewrite call sites. You change a base URL.
# Before: every app talks straight to the provider
client = OpenAI(base_url="https://api.openai.com/v1")
# After: the same call, now governed, logged, and routable
client = OpenAI(base_url="http://localhost:8080/openai")
That one line is the whole point. The SDK, the model names, the request bodies all stay the same. What changes is that the call now lands on something you control before it reaches OpenAI, Anthropic, Bedrock, Vertex, or any of the others.
The gateway is not a toll booth that slows everything down. You are buying governance, not latency: in Bifrost's own t3.xlarge benchmark, that control layer cost 11 microseconds of added overhead per request at 5,000 requests per second, and held a 100 percent success rate.
Standing it up locally is a single command:
npx -y @maximhq/bifrost
That pulls the binary, runs migrations, and serves a web UI plus the API on port 8080. I ran exactly this while writing, and everything below is what the running gateway actually did, not a paraphrase of the docs.
Governance that follows a hierarchy, not a spreadsheet
Once traffic flows through one place, governance stops being a document and becomes a data model. In Bifrost that model has four levels: Customer, Team, Virtual Key, and Provider Config.
The Virtual Key is the unit you hand out. It is not a raw provider key. It is a governed credential with a sk-bf- prefix that carries its own budget, rate limits, and allow-lists. I created one through the API and it came back live:
curl -X POST localhost:8080/api/governance/virtual-keys \
-d '{"name":"marketing-team-vk","is_active":true,
"rate_limit":{"token_max_limit":1000000,"token_reset_duration":"1h",
"request_max_limit":1000,"request_reset_duration":"1h"}}'
The response handed back sk-bf-82a7fb23... with a rate-limit object already ticking: token_current_usage: 0, an hourly reset window, request counters primed. That key is the thing a team codes against. Everything you attach to it travels with every call it makes.
Budgets cascade. A Provider Config can cap the OpenAI spend inside a key, the key has its own ceiling, the team above it has another, and every applicable budget has to pass for the request to proceed. Cost deducts from each level at once. Budgets reset on windows from one minute to one year, and calendar_aligned snaps them to real month and year boundaries instead of rolling clocks. Rate limits come in two flavors, request-based and token-based, and unlike budgets they apply at the Virtual Key level only.
Access control is enforcement, not advice. Put a model or provider outside a key's allow-list and the call returns a 403 with a typed reason, model_blocked or provider_blocked. There is no soft warning to ignore.
One gotcha worth knowing before you wire this into config: a budget attaches as its own referenced object, not as an inline block on the key. I tried to embed the budget directly in the create call and it came back unattached. Create the budget, reference it by id. The docs are right; the shortcut is not.
Governing every MCP call, not just every model call
Chat completions were the easy half. The harder half, and the reason this topic exists, is MCP.
Model Context Protocol is what turns a chat model into something that acts: it calls tools, runs commands, reads and writes real systems. An ungoverned MCP layer is an agent with hands and no supervisor. Bifrost treats MCP as a first-class governed surface, and it does so with tool filtering that is deny-by-default at three levels.
- Client config sets the baseline of which tools exist at all.
- Request headers (
x-bf-mcp-include-clients,x-bf-mcp-include-tools) narrow that set per call. - Virtual Key filtering overrides both, so a key with no MCP config gets no MCP tools, full stop.
Deny-by-default is the whole posture. A tool a key was never granted is not available to it, even if the underlying MCP server exposes it.
How the calls actually run is configurable, and the default is the safe one:
- Tool Execution mode is human-in-the-loop. Bifrost does not auto-run tool calls; your app reviews them and explicitly hits
/v1/mcp/tool/execute. That review point is where approval and audit live. - Agent Mode auto-executes only the tools you mark in
tools_to_auto_execute, bounded bymax_agent_depth(default 10). - Code Mode lets the model write Starlark to orchestrate many tools in one shot through four meta-tools, which Bifrost measures at up to 92.8 percent fewer input tokens than exposing every tool directly.
- Bifrost as an MCP gateway exposes a
/mcpendpoint that external hosts like Claude Desktop, Cursor, and Cline connect to. On the running instance that endpoint answered as a live streaming connection, held open the way an MCP host expects.
For teams that want reusable policy, MCP Tool Groups (an Enterprise feature) bundle curated tools and attach them to keys, teams, or users, enforced at request time.
The one-sentence version: the gateway governs what an agent is allowed to do, not just which model it is allowed to call.
What you can actually see
Governance you cannot observe is governance you cannot prove. Bifrost logs every request asynchronously, so the visibility does not cost latency.
Each entry carries the model, token counts, cost, and the identity behind the call. When a request fails over or rotates keys, an attempt_trail records every attempt, the selected_key_id, and the retry count, so a weird bill or a slow p99 has a paper trail instead of a shrug.
The exports are the standard enterprise set:
- Prometheus metrics are built in on
/metrics, live out of the box (on a fresh instance you will see the runtime metrics first; the request metrics fill in as traffic flows). - OpenTelemetry export speaks the
genai_extensionsemantic conventions to Grafana, Datadog, New Relic, or Honeycomb. - A native Datadog connector and log exports to S3, GCS, and BigQuery are available on Enterprise.
If content is sensitive, disable_content_logging keeps the metadata, latency, cost, tokens, and identity, while dropping the request and response bodies. You get the accounting without hoarding the payloads.
The controls that make security sign off
Everything so far runs in the open-source gateway. The pieces a security team asks about before rollout live in Bifrost Enterprise, which is a strict superset: same config schema, same providers, more control.
Identity comes through OIDC and SCIM, with SSO against Okta, Microsoft Entra, Keycloak, Zitadel, and Google Workspace, plus group-to-role mapping and auto-deprovisioning. Access is role-based across Admin, Developer, and Viewer, the permission set widening at each tier instead of collapsing into a single all-or-nothing admin. Data Access Control adds row-level scoping, so an operator sees only their own, their team's, or all data.
Audit logs are immutable and HMAC-signed, exportable as JSON, JSON Lines, or Syslog straight into a SIEM. That is what SOC 2 Type 2, GDPR, HIPAA, and ISO 27001 evidence actually looks like.
Guardrails split into Rules, written in CEL, and Profiles that decide how to act: native Gitleaks-backed secret detection and PII regex, plus external providers including AWS Bedrock, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, GraySwan Cygnal, and Patronus AI. For scale, clustering keeps state in sync across nodes with no single leader.
This is the layer that turns "we route through a gateway" into "we can show an auditor who did what, signed and exportable straight into the SIEM."
Extending the gateway to the laptop
The gateway governs every call that routes through it. The last mile is reach. Think of the app a developer installed this morning that talks straight to a provider from a laptop, never pointed at your gateway. Getting the same governance onto that machine is the other half of the job.
That is where Bifrost Edge and the gateway work together. Edge is a lightweight endpoint agent for macOS, Windows, and Linux that runs in the menu bar or system tray and intercepts AI traffic at the machine level. There is no base URL to change per app and nothing for the user to configure. Once a machine signs in through your existing identity provider, the same virtual keys, budgets, guardrails, and audit logs you already run on the gateway apply on the laptop too.
Edge adds two enforcement surfaces the endpoint needs:
- App allow and deny, fleet-wide. An approved app runs fully governed; a denied one is blocked before any data leaves the machine.
- MCP server governance on the device. Edge discovers the MCP servers configured inside Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor, dedupes them across the fleet, and lets you allow or deny each one centrally. Deny a server and it is stopped on the machine, even inside an app that had it configured before your policy existed.
Rollout is hands-off, through the MDM you already run: Jamf, Intune, and Kandji, with Omnissa Workspace ONE and JumpCloud in the mix as well. Admins work from an Approvals dashboard (Pending, Approved, Denied) and a Devices fleet view. The gateway centralizes the policy; Edge carries it to every machine.
What isn't ready yet
Edge is not something you can turn on this afternoon.
It is in limited alpha, or early access, and you register to be onboarded rather than downloading a shipping release. It is an Enterprise feature, not part of the open-source repo, so you will not find it in the Bifrost you clone from GitHub. That status is current as of July 2026; check the docs before you quote a timeline, because alpha windows move.
It is also not a replacement for your endpoint or network security. Edge governs AI traffic specifically. It runs alongside tools like CrowdStrike, Zscaler, and Tailscale, not instead of them.
None of that changes the part you can use today. The open-source gateway is real, it installs in one command, and every governance, MCP, and observability capability above ran on the instance I stood up while writing this. The endpoint layer is where the story is still being finished.
Where to start
Start with the gateway, because it is the part you can run today. Install it with npx -y @maximhq/bifrost, point one base URL at it, and route your team's traffic through it. Then spend an afternoon on the governance: issue a virtual key per team, attach budgets and rate limits, turn on audit logging. At that point every LLM and MCP call your infrastructure makes is attributed, bounded, and logged, and none of it required rewriting a call site.
The endpoint is the next problem, not the first one. When you are ready to bring the laptops under the same policy, Bifrost Edge is the extension that gets you there, on the timeline the alpha allows.
Every technical detail here is drawn from the Bifrost gateway and Edge documentation and confirmed against a running instance. If something in this piece does not match what you see in the docs, trust the docs.
Resources & References
- Bifrost gateway documentation
- Bifrost Edge documentation
- Bifrost on GitHub (open source)
- Register for Bifrost Edge alpha
Originally published on Medium.
Top comments (0)