Enterprise MCP Gateway with Built-In Security: OAuth 2.0, RBAC, and Tool Access Control Maxim's Bifrost project introduces an enterprise MCP gateway with built-in security, including OAuth 2.0, RBAC, and tool access control. The gateway ensures that LLM tool calls are not automatically executed, requiring explicit approval, and supports deny-by-default virtual key filtering to prevent accidental production access. MCP servers are powerful, but they can expose production systems if anyone on the team can connect and run tools without guardrails. Imagine a new hire testing the app on their laptop and accidentally granting an MCP server access to the production database. Without governance, that is a realistic path to data leakage. Bifrost https://github.com/maximhq/bifrost.git addresses this with three layers: POST /v1/mcp/tool/execute . mcp configs gets zero MCP tools. Unlisted clients are implicitly blocked.Bifrost covers virtual keys, budgets, rate limits, routing, and MCP tool filtering, RBAC, SSO, audit logs, and MCP Tool. First, let's open the app and set up the MCP server. To do this, I'll enter the following line in the terminal: npx -y @maximhq/bifrost After that, you will see the following interface similar, depending on the version : Go to the "MCP Library" tab and you will see a huge list of pre-configured MCP servers that you can use in your projects. If you want to set up your own MCP server, go to MCP Gateway and click New MCP Server : Here you can specify the connection URL, auth type, tool allowlists, and other settings including Code Mode , which can significantly reduce token usage when orchestrating many MCP servers. This is the most important security property for the scenario in the introduction. When an LLM returns tool calls, Bifrost does not automatically execute them . Tool calls are suggestions only. Your application must explicitly approve and execute each one: 1. POST /v1/chat/completions → LLM returns tool call suggestions NOT executed 2. Your app reviews tool calls → Apply security rules, get user approval if needed 3. POST /v1/mcp/tool/execute → Execute approved tool calls explicitly 4. POST /v1/chat/completions → Continue the conversation with tool results Example execution call: curl -X POST http://localhost:8080/v1/mcp/tool/execute \ -H "Content-Type: application/json" \ -d '{ "id": "call xyz789", "type": "function", "function": { "name": "database query", "arguments": "{\"sql\": \"SELECT 1\"}" } }' So even if a new hire's agent requests a dangerous database operation, nothing happens until your application deliberately executes it. Combined with deny-by-default virtual key filtering below , this is Bifrost's real three-layer answer to accidental production access. You can opt into autonomous execution for specific tools via Agent Mode , but that must be explicitly configured, it is not the default. Authentication is declared on the MCP client itself as a top-level auth type field, posted to /api/mcp/client . There is no nested auth object. auth type | Who authenticates | When to use | |---|---|---| none | — | Public MCP servers, local STDIO tools | headers | Admin, once | Shared API keys, bearer tokens, custom headers | oauth | Admin, once | Shared third-party service the whole team uses | per user oauth | Each end-user, lazily | Per-user services like Notion, GitHub, Sentry | per user headers | Each end-user, lazily | Per-user API keys, signed tokens | OAuth oauth and per user oauth is only valid for HTTP and SSE connections. Bifrost implements the Authorization Code flow, there is no client-credentials / service-account mode. { "name": "local-tools", "connection type": "stdio", "stdio config": { "command": "npx", "args": "-y", "@anthropic/mcp-filesystem" }, "auth type": "none", "tools to execute": "read file", "list directory" } curl -X POST http://localhost:8080/api/mcp/client \ -H "Content-Type: application/json" \ -d '{ "name": "web search", "connection type": "http", "connection string": "https://mcp.example.com/mcp", "auth type": "headers", "headers": { "Authorization": "Bearer your-api-key", "X-Tenant-ID": "acme-corp" }, "tools to execute": " " }' The admin authenticates once during setup. Every subsequent request to that MCP server uses the same stored token, regardless of which caller hit Bifrost. curl -X POST http://localhost:8080/api/mcp/client \ -H "Content-Type: application/json" \ -d '{ "name": "authenticated service", "connection type": "http", "connection string": "https://api.example.com/mcp", "auth type": "oauth", "oauth config": { "client id": "your-client-id", "client secret": "your-client-secret", "authorize url": "https://auth.example.com/oauth/authorize", "token url": "https://auth.example.com/oauth/token", "scopes": "mcp:read", "mcp:write" }, "tools to execute": " " }' The oauth config object accepts client id , client secret , authorize url , token url , scopes , or registration url / server url for Dynamic Client Registration. After the admin completes the authorize step, finalize with POST /api/mcp/client/{id}/complete-oauth . Use auth type: "per user oauth" when each end-user must connect under their own account. Bifrost stores one OAuth token per identity, mcp client and reuses it on later calls. Identity is required via virtual key, signed-in SSO user, or x-bf-mcp-session-id . curl -X POST http://localhost:8080/api/mcp/client \ -H "Content-Type: application/json" \ -d '{ "name": "acme api", "connection type": "http", "connection string": "https://api.acme.example.com/mcp", "auth type": "per user headers", "per user header keys": "X-API-Key", "X-Tenant-ID" , "tools to execute": " " }' Identity matters: With auth type: "oauth" or auth type: "headers" , all callers share the same upstream credential. Bifrost does not attach a per-user identity to MCP requests. To know exactly who performed an action upstream, use per user oauth or per user headers . RBAC does not govern which MCP tools an agent can invoke at runtime. That is controlled by virtual keys and three stacked levels of tool filtering: tools to execute on each MCP client baseline x-bf-mcp-include-clients and x-bf-mcp-include-tools per request mcp configs array takes precedence over request headers This is built-in behavior, not a config setting: a virtual key with no mcp configs gets zero MCP tools , and clients not listed in mcp configs are implicitly blocked. curl -X POST http://localhost:8080/api/governance/virtual-keys \ -H "Content-Type: application/json" \ -d '{ "name": "new-dev-key", "mcp configs": { "mcp client name": "internal api", "tools to execute": "search", "get article" }, { "mcp client name": "staging database", "tools to execute": "query" } }' tools to execute | Result | |---|---| " " | All tools from this client | "a", "b" | Only specified tools | | No tools from this client | Client not in mcp configs | All tools blocked from that client | This is where you enforce patterns like "backend devs can hit staging APIs but not production databases" by giving different virtual keys different mcp configs , not by RBAC permission strings. For one-off restrictions within a virtual key's allowlist: curl -X POST http://localhost:8080/v1/chat/completions \ -H "Authorization: Bearer vk new dev" \ -H "x-bf-mcp-include-tools: staging database-query" \ -d '...' Note: when a virtual key has mcp configs , it auto-generates x-bf-mcp-include-tools and overrides any manually sent header. Bifrost does not parse SQL or block operations like DELETE / DROP at the query level. Restrict access by allowing only specific tool names for example, a read-only query tool instead of an execute tool . Bifrost provides Role-Based Access Control for the administrative surface who can edit MCP gateway configs, read logs, configure guardrails, manage virtual keys, and so on. RBAC is not runtime authorization for agents invoking MCP tools. Permissions are Resource × Operation pairs, not permission strings like mcp:tool:invoke . | Role | Permissions | Description | |---|---|---| Admin | 42 | Full access to all resources and operations | Developer | 27 | CRUD on technical resources, view access to logs and cluster | Viewer | 14 | Read-only access to all resources | You can also create custom roles for example, an Auditor role with AuditLogs:View and Logs:View only . Logs , VirtualKeys , MCPGateway , MCPToolGroups , MCPLogs , GuardrailsConfig , AuditLogs , Cluster , and others. View , Create , Update , Delete , Download , Reveal , and inference operations. Example: a custom Auditor role might grant AuditLogs:View and AuditLogs:Download , but not MCPGateway:Update . That controls who can configure the gateway in the dashboard, not which tools an agent executes at runtime. Roles and permissions are managed via Governance → Roles & Permissions in the dashboard or the /api/roles endpoints: curl -X GET http://localhost:8080/api/roles/{role id}/permissions \ -H "Authorization: Bearer