企业级MCP网关：OAuth 2.0+RBAC+工具级安全管控

MCP 服务器功能强大，但如果团队中的任何人都可以随意连接并运行工具而没有任何防护机制，就有可能暴露生产系统。

想象一下，新员工在笔记本电脑上测试应用时，意外授予了一个 MCP 服务器访问生产数据库的权限。在没有治理的情况下，这是数据泄露的一条现实路径。

Bifrost 通过三层防护来解决这个问题：

人工介入式执行（Human-in-the-loop execution）—— Bifrost 不会自动执行工具调用。LLM 只负责建议工具；由你的应用程序审查这些建议，并显式调用 POST /v1/mcp/tool/execute。

默认拒绝式工具过滤（Deny-by-default tool filtering）—— 没有 mcp_configs 的虚拟密钥将无法使用任何 MCP 工具。未列入名单的客户端会被隐式阻止。

治理（可选）—— RBAC、SSO、审计日志和 MCP Tool Groups 控制谁可以配置网关以及审查管理活动。

Bifrost 涵盖虚拟密钥、预算、速率限制、路由、MCP 工具过滤、RBAC、SSO、审计日志和 MCP Tool。

首先，打开应用并设置 MCP 服务器。为此，我会在终端中输入以下命令：

npx -y @maximhq/bifrost

之后，你会看到以下界面（因版本不同，可能略有差异）：

转到 "MCP Library" 标签页，你会看到一个庞大的预配置 MCP 服务器列表，可以在自己的项目中使用。

如果你想搭建自己的 MCP 服务器，请前往 MCP Gateway 并点击 New MCP Server：

在这里，你可以指定连接 URL、认证类型、工具允许列表以及其他设置，包括 Code Mode——在编排多个 MCP 服务器时，它可以显著减少 token 使用量。

⚙️ 人工介入式工具

这是引言场景中最重要的安全属性。

当 LLM 返回工具调用时，Bifrost 不会自动执行它们。工具调用只是建议。你的应用程序必须显式批准并执行每一个：

1. POST /v1/chat/completions   → LLM 返回工具调用建议（不执行）
2. 你的应用审查工具调用 → 应用安全规则，必要时获取用户批准
3. POST /v1/mcp/tool/execute   → 显式执行已批准的工具调用
4. POST /v1/chat/completions   → 用工具结果继续对话

执行调用示例：

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\"}"
    }
  }'

因此，即使新员工的 Agent 请求了一个危险的数据库操作，在你的应用程序显式执行之前，什么都不会发生。结合下面的默认拒绝式虚拟密钥过滤，这就是 Bifrost 应对意外生产环境访问的真实三层答案。

你可以通过 Agent Mode 为特定工具选择加入自动执行，但那必须显式配置，不是默认行为。

💻 MCP 认证

认证在 MCP 客户端本身声明为顶层 auth_type 字段，发布到 /api/mcp/client。没有嵌套的 auth 对象。

OAuth（oauth 和 per_user_oauth）仅对 HTTP 和 SSE 连接有效。Bifrost 实现的是 Authorization Code 流程，不支持 client-credentials / service-account 模式。

1. 无认证（仅用于开发）

{
  "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"]
}

2. 静态请求头（共享 API 密钥）

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": ["*"]
  }'

3. 服务级 OAuth（管理员授权一次）

管理员在设置期间进行一次身份验证。此后对该 MCP 服务器的每个后续请求都使用相同的存储令牌，无论哪个调用者访问 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": ["*"]
  }'

oauth_config 对象接受 client_id、client_secret、authorize_url、token_url、scopes，或用于动态客户端注册的 registration_url / server_url。管理员完成授权步骤后，使用 POST /api/mcp/client/{id}/complete-oauth 完成最终配置。

4. 每用户 OAuth（每个用户自行认证）

当每个最终用户必须使用自己的账户连接时，使用 auth_type: "per_user_oauth"。Bifrost 为每个（身份标识，MCP 客户端）对存储一个 OAuth 令牌，并在后续调用中复用。身份标识通过虚拟密钥、已登录的 SSO 用户或 x-bf-mcp-session-id 提供。

5. 每用户请求头（遗留 / 自定义每用户密钥）

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": ["*"]
  }'

身份标识的重要性：使用 auth_type: "oauth" 或 auth_type: "headers" 时，所有调用者共享同一个上游凭证。Bifrost 不会在 MCP 请求中附加每用户身份标识。如果要准确知道谁执行了上游操作，请使用 per_user_oauth 或 per_user_headers。

💻 运行时工具访问控制（虚拟密钥）

RBAC 不能控制 Agent 在运行时可以调用哪些 MCP 工具。那是由虚拟密钥和三层叠加的工具过滤机制来控制的：

客户端配置——每个 MCP 客户端上的 tools_to_execute（基线）

请求头——每个请求的 x-bf-mcp-include-clients 和 x-bf-mcp-include-tools

虚拟密钥配置——mcp_configs 数组（优先级高于请求头）

这是内置行为，而非配置设置：没有 mcp_configs 的虚拟密钥无法使用任何 MCP 工具，未列入 mcp_configs 的客户端被隐式阻止。

虚拟密钥配置

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"]
      }
    ]
  }'

这就是你实施"后端开发人员可以访问 staging API，但不能访问生产数据库"这类模式的方式——通过为不同虚拟密钥配置不同的 mcp_configs，而不是通过 RBAC 权限字符串。

单次请求范围收窄

对于虚拟密钥允许列表中的一次性限制：

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 '...'

注意：当虚拟密钥具有 mcp_configs 时，它会自动生成 x-bf-mcp-include-tools 并覆盖手动发送的请求头。

Bifrost 不会解析 SQL 或在查询级别阻止 DELETE / DROP 等操作。通过仅允许特定的工具名称来限制访问（例如，使用只读查询工具而非执行工具）。

🔎 RBAC——管理访问

Bifrost 提供基于角色的访问控制，用于管理层面——谁可以编辑 MCP 网关配置、读取日志、配置防护栏、管理虚拟密钥等。RBAC 不是 Agent 调用 MCP 工具的运行时授权。

权限是资源 × 操作的配对，而非 mcp:tool:invoke 这样的权限字符串。

你也可以创建自定义角色（例如，只有 AuditLogs:View 和 Logs:View 权限的 Auditor 角色）。

受保护的资源包括：

Logs、VirtualKeys、MCPGateway、MCPToolGroups、MCPLogs、GuardrailsConfig、AuditLogs、Cluster 等。

可执行的操作包括：

View、Create、Update、Delete、Download、Reveal 和 inference 操作。

示例：自定义 Auditor 角色可能授予 AuditLogs:View 和 AuditLogs:Download，但不授予 MCPGateway:Update。这控制的是谁可以在仪表板中配置网关，而不是 Agent 在运行时执行哪些工具。

角色和权限通过仪表板中的 Governance → Roles & Permissions 或 /api/roles 端点进行管理：

curl -X GET http://localhost:8080/api/roles/{role_id}/permissions \
  -H "Authorization: Bearer <admin_token>"

🖥️ 用户配置与角色映射

没有 role_sync 配置块。角色分配来自通过 OIDC 进行用户配置，支持 Okta、Microsoft Entra 等。

配置 SSO 后：

用户通过 OAuth 2.0 / OIDC（Authorization Code + PKCE）使用企业凭据登录

角色从 IdP 组、应用角色或自定义声明映射到 Bifrost 角色（Admin、Developer、Viewer 或自定义角色）

角色和团队分配在每次会话时同步

后台协调每 24 小时运行一次；OIDC 会话刷新检查每 15 分钟运行一次

不活跃或已停用的用户会在本地被注销（包括通过入站 SCIM 2.0）

配置位于 config.json 的 scim_config 下。参见用户配置文档获取各提供商的具体设置指南。

Bifrost 中的审计日志记录管理活动——谁在什么时候做了什么， affected 了哪些资源。它们不使用 log_level / capture / export_to 块。

实际配置结构：

{
  "audit_logs": {
    "disabled": false,
    "hmac_key": "env.AUDIT_HMAC_KEY",
    "retention_days": 365,
    "object_storage": {
      "type": "s3",
      "bucket": "acme-audit-archive",
      "prefix": "acme-prod",
      "compress": true,
      "region": "us-east-1",
      "access_key_id": "env.AUDIT_S3_KEY",
      "secret_access_key": "env.AUDIT_S3_SECRET"
    }
  }
}

签名事件——配置 HMAC 密钥用于验证

仪表板审查——按搜索文本、操作、结果和时间范围筛选

导出——JSON、JSON Lines 或 Syslog（需要 AuditLogs:Download 权限）

保留期——retention_days 控制数据库保留期限

对象存储归档——可选镜像到 S3/GCS，用于长期合规保留

在仪表板的 Governance → Audit Logs 查看审计条目。

✅ 实施最佳实践

1. 依赖默认拒绝

不要寻找 "policy": "default_deny" 这样的设置。它不存在。相反：

为每个团队或环境创建具有显式 mcp_configs 的虚拟密钥

将客户端级别的 tools_to_execute 设置为所需的最小范围

在用于本地开发的密钥上不分配生产数据库工具

2. 保持人工介入式作为默认行为

只对你已明确审查过的工具启用 Agent Mode 自动执行。默认流程——chat → review → /v1/mcp/tool/execute——是你最强的安全网。

3. 分离运行时访问与管理访问

运行时（Agent 可以做什么）：虚拟密钥 + mcp_configs + 请求头

管理（谁可以更改配置）：RBAC + SSO

4. 使用按环境划分的虚拟密钥

{
  "name": "production-readonly",
  "mcp_configs": [
    { "mcp_client_name": "production_database", "tools_to_execute": ["query"] }
  ]
}

{
  "name": "staging-full",
  "mcp_configs": [
    { "mcp_client_name": "staging_database", "tools_to_execute": ["*"] }
  ]
}

5. 尽早配置审计日志

启用 HMAC 签名，将 retention_days 设置得舒适地高于你的归档窗口，并可选择镜像到对象存储以满足合规要求。

6. 定期进行访问审查

安排每季度审查来回答：

哪些虚拟密钥授予了对生产 MCP 客户端的访问权限？

谁在 Enterprise 中拥有 Admin 或 Developer RBAC 角色？

是否存在权限过度的虚拟密钥或不活跃的 SSO 账户？

使用仪表板和 /api/roles 端点，没有 bifrost audit CLI 命令。@maximhq/bifrost-cli 包是面向编程 Agent（Claude Code、Codex CLI、Gemini CLI、Opencode）的交互式启动器，不是审计工具。

借助 Bifrost，你可以以更安全的方式配置公司的 MCP 服务器。这个现成的解决方案不仅能节省成本，还能节省时间，而这些时间可以用于产品开发。

Bifrost GitHub: https://github.com/maximhq/bifrost

Bifrost Docs: https://docs.getbifrost.ai

Bifrost CLI: npx -y @maximhq/bifrost-cli

感谢阅读本文！❤️

期待在评论区听到你的想法！