Bifrost is Maxim AI's high-performance, open-source AI gateway that unifies access to 20+ providers through a single OpenAI-compatible API. Bifrost Enterprise is a strict superset of that gateway, adding high-availability clustering, adaptive load balancing, identity and access controls, audit logs, guardrails, and private deployment options.
Those additions matter when several teams share the gateway. Routing rules, access policies, MCP tool permissions, and administrative changes can be managed and audited in one layer instead of being implemented separately in every AI application.
After writing about the open-source gateway in my previous two posts, I asked the Bifrost team for access to the Enterprise version. They gave me limited access to the paid features for free. This article covers what I tested and whether those features make sense for personal and enterprise use.
Transparency through Audit Logs
So, before creating any new Enterprise configuration, I wanted to see whether Bifrost could actually tell me what was happening behind the scenes. Audit Logs tell you exactly that. It’s different from the regular LLM logs because they show the requests going through the gateway, while Audit Logs focus on changes and administrative activity inside Bifrost. So if someone creates a virtual key, changes a routing rule, updates a guardrail, or modifies the cluster configuration, this is where we should be able to find it.
For a personal setup, audit logs may be more detail than you need. In a company, they give security and platform teams a record of who changed shared routing, access, and guardrail configuration.
What are MCP Tool Groups?
In my previous blog, I already mentioned how I connected the MCP Gateway to OpenCode using the Virtual Key, which enabled Bifrost to expose all of my configured MCP tools through that one endpoint.
But that also raised a question: do I really want every harness to have access to every tool? So, this time I decided to try MCP Tool Groups.
The idea is pretty simple. We can create a group of selected MCP tools and attach that group to a virtual key. OpenCode already uses my dedicated Enterprise virtual key, so I can control the tools available to it without changing the rest of my MCP setup.
In the previous blog, you might have seen that I’ve used the Context7 MCP server. It provided access to two tools:
resolve-library-idquery-docs
So, while creating the tool group, I decided to drop the query-docs and kept only the resolve-library-id activated.
Then, under Associations, I attached the group only to my opencode-enterprise virtual key. I didn't attach it to any teams, customers, providers, or other keys.
The OpenCode MCP configuration itself didn't need much change. It was already pointing to Bifrost's remote MCP endpoint:
{
"mcp": {
"bifrost": {
"type": "remote",
"url": "https://bifrost-enterprise.agitracker.io/mcp",
"enabled": true,
"oauth": false,
"headers": {
"Authorization": "Bearer {file:./bifrost-virtual-key}"
}
}
}
}
I kept the virtual key inside a separate local file, so it never had to be pasted into the configuration or committed to Git.
After restarting OpenCode, I used a deliberately small prompt,
Use the Context7 MCP to resolve the React library. Reply with only the returned library ID.
The request executed successfully, as you can see in the above screenshot.
So, is this feature useful? The idea is excellent, especially when different coding harnesses should have access to different MCP tools. And, it gives you a central place to manage tool access instead of duplicating MCP configuration across every client.
What is Adaptive routing?
The next feature I wanted to try was Adaptive Routing. The idea behind it is quite useful, especially if you are running several models, providers, or API keys through the same Bifrost gateway.
Normally, requests are distributed using fixed weights. For example, if two Gemini keys have the same weight, Bifrost can send roughly half of the traffic to each one. The problem is that fixed weights do not know whether one key has become slower, started returning errors, or hit a rate limit.
Adaptive Routing tries to solve that automatically.
Bifrost monitors the latency, error rate, success rate, and utilization of each available route. It then recalculates their weights every few seconds. And, a healthy and faster route receives more traffic, while a failing or slow route receives less. Bifrost still sends a small amount of traffic to recovering routes so it can detect when they become healthy again.
The routing happens at two levels:
- Bifrost can select which provider should handle a model request.
- After selecting the provider, it can choose the best API key configured for that provider.
This makes the feature more useful for companies that maintain multiple provider accounts or keys. Instead of manually changing weights whenever a provider starts acting up, Bifrost can react to the recent performance data on its own.
How to set Guardrails?
Provider safety controls do not cover every organization's policies. Putting custom guardrails at the gateway lets the same input and output checks run across every model behind it.
This feature is meant to protect both the prompts sent to a model and the responses coming back from it. Bifrost separates the feature into two parts: rules decide when a check should run, while profiles define what kind of check should be performed. For this test, I wanted to avoid adding another external API key, so I chose Bifrost's built-in Custom Regex provider. According to the Guardrails documentation, Custom Regex runs locally and can be used for deterministic pattern checks.
So, I created two guardrail rules. One for the input, and the other one for the output.
So, now if I send a request like Reply with exactly: BIFROST_GUARDRAIL_TEST, I get a regex pattern matched error. That’s where the guardrail is actually doing its job.
The regex rule blocked the matching output without calling an external guardrail service.
Final thoughts
When I started exploring Bifrost Enterprise, I expected the paid version to feel like the open-source gateway with a few extra switches. That wasn’t true.
The core experience stayed familiar, and I could continue using OpenCode through one Bifrost endpoint while the gateway handled the provider connection underneath. That part was convenient. I did not need to change my workflow every time I switched between OpenAI and Gemini.
The enterprise features that made the most sense to me were Audit Logs and MCP Tool Groups. Audit Logs give teams a central record of what happened, while MCP Tool Groups make it easier to control which tools a client can access.
Would I use Bifrost Enterprise for my personal setup? Probably not if I only had one provider, one API key, and a handful of requests. The extra governance and operational features would be more machinery than I need.
For a team running several models, provider keys, MCP clients, and internal users, the situation is different. A shared gateway, centralized logs, access controls, guardrails, and tool restrictions can remove a lot of repeated setup from individual applications. And if you think you are the right candidate, you can always book a demo!
Top comments (3)
great share
Thank you!!
the mcp tool groups feature is the one that changes the mental model. once your gateway can scope which tools each client exposes, you stop thinking about mcp as a setup concern and start treating it as an access control layer.
same shift with adaptive routing. fixed weights assume infrastructure is stable — it's not. api keys hit rate limits, providers degrade. letting the gateway observe and reweight in real time is the right abstraction.
audit logs feel obvious in hindsight but they're what most teams skip until something goes wrong.
what's your take on custom regex guardrails versus offloading that to a dedicated llm based content filter?