MCP 治理、用户角色和权限 — 对企业的重要性

大多数 MCP 设置的隐患

模型上下文协议为 AI 代理与真实系统之间的交流开辟了一条清晰的通道。第一波 MCP 服务器作为 CLI 二进制文件发布：在开发者的笔记本电脑上安装，将 Claude Desktop 指向它，完成。这适用于单个强用户。

但这对企业来说 不适用。

当公司内部有超过一个人需要 MCP 时，三个治理问题会同时出现：

谁可以使用哪个连接器？
每个用户连接后可以做什么（读取？写入？删除？）
审计日志在哪里？

基于 CLI 的 MCP 服务器回答“每个拥有二进制文件的人” / “API 能做的任何事情” / “标准输出，明天就消失”。对于受监管的企业来说，这是一个硬性停止。

这就是 AnythingMCP 旨在弥补的差距。

在 MCP 上下文中治理的含义

在传统的 SaaS 中，治理意味着 用户、组、角色、权限 和 审计日志。相同的基本概念适用于 MCP，但它们增加了一个额外的维度：工具。

MCP 服务器向 AI 客户端公开一系列工具。每个工具都是一个独立的功能 — list_invoices、create_quote、delete_account。没有每个工具的访问控制，授予用户“CRM 连接器”意味着授予该连接器公开的所有工具。这相当于因为实习生需要 tail 日志而给他们 root SSH 权限。

AnythingMCP 将四个层次视为一等公民：

层次	问题	示例
用户	谁在发出请求？	`mario.rossi@acme.com`
角色	他们拥有什么样的访问权限？	`developer`、`viewer`、`finance`
连接器	哪个集成系统？	Salesforce CRM、SAP ERP、Postgres
工具	具体的 MCP 工具是什么？	`list_accounts`（读取）、`delete_account`（关闭）

每次调用都会检查这四个层次，然后记录。

AnythingMCP 治理模型

用户和 SSO

您可以从仪表板手动创建用户，或者 — 这正是企业客户实际做的 — 连接您现有的身份提供者：

SAML 2.0 适用于 Okta、Azure AD、OneLogin、Ping、Auth0、Keycloak
SCIM 2.0 用于自动配置和取消配置（当某人离开公司时，他们的 MCP 访问权限会随着他们的 AD 账户消失，而不是在运营部门处理三周后）
组 → 角色映射：AD 组 eng-platform 自动成为 AnythingMCP 中的角色 developer

没有单独的密码需要轮换，没有需要保持同步的影子用户列表。

角色

角色是权限的命名集合。AnythingMCP 提供合理的默认值 — admin、developer、viewer — 并允许您定义自己的角色。

角色定义在概念上看起来是这样的：

role: finance
description: 财务团队 — 在任何地方读取发票，在 DATEV 中发布
connectors:
  - slug: datev
    tools:
      list_clients: read
      list_invoices: read
      create_booking: write
      delete_booking: off
  - slug: weclapp
    tools:
      list_invoices: read
      list_orders: read
  - slug: sap-erp
    tools:
      "*": off    # 明确拒绝

通配符 "*" 很重要：当您稍后向 SAP 连接器添加新工具时，财务角色会自动继承关闭 — 失败关闭而不是失败开放。

每个连接器的访问

最常见的企业模式：按团队边界分隔连接器。

销售团队查看 CRM。
财务团队查看 ERP 和会计。
工程团队查看生产数据库（只读）。
客户支持团队查看工单系统。

每个团队的 AI 代理 — Claude、ChatGPT、Copilot，无所谓 — 只看到其角色允许的工具。销售人员要求 ChatGPT “删除客户记录” 时，网关会干净利落地拒绝，而不是在操作已半完成后从 SAP 返回 500 错误。

每个工具的权限

这是 CLI 服务器无法匹配的细粒度。

一个 Salesforce 的单一 MCP 连接器可能公开 30 多个工具：list_accounts、get_opportunity、create_opportunity、update_opportunity、delete_opportunity、list_leads，…… 对于每个工具，AnythingMCP 支持三种模式：

read — 工具可调用并返回数据，但变更会被过滤掉
write — 工具完全可调用
off — 工具完全对代理隐藏（它甚至不会出现在 MCP tools/list 响应中）

“隐藏”是关键。模型无法被越狱调用它不知道存在的工具。通过按角色修剪工具目录，您将攻击面减少到每个用户实际需要的最小值。

审计日志

每次工具调用都会写入一行：谁、何时、哪个工具、哪个连接器、使用了哪些参数、返回了什么（或什么错误）。日志存储在您的 PostgreSQL 中 — 不在我们的云中，不在第三方的 S3 中 — 并且可以像查询其他表一样查询。

对于受监管的行业（银行、医疗、公共部门），这使得 MCP 可用。您可以通过一个 SQL 查询回答“上个季度是否有人读取了患者记录 1234”。

为什么这在仅有 CLI 的 MCP 服务器上是不可能的

MCP 生态系统充满了单一用途的 CLI 服务器 — mcp-server-postgres、mcp-server-github 等等。它们非常适合个人使用。它们 在结构上无法 实现企业治理，原因有四：

没有用户概念。CLI 二进制文件以调用它的操作系统用户身份运行。没有“Mario”与“Anna” — 只有 whoami。两个共享同一 Claude Desktop 安装的用户共享同一 MCP 身份，这是设计使然。
没有每个工具的范围。如果 CLI 公开 query_database，每个拥有二进制文件的用户都可以用任何 SQL 调用它。您无法将其限制为仅 SELECT，或特定表，而不分叉二进制文件。
没有中央审计。每个二进制文件记录到自己的标准输出。没有地方可以询问“上周公司进行的每个 MCP 调用”。
没有取消配置。当某人离开时，您必须追踪每台安装了二进制文件的笔记本电脑并撤回凭据。实际上，没有人会这样做。

这些不是 CLI 服务器中的错误 — 它们是架构固有的。运行在开发者机器上的二进制文件没有组织身份的概念。

为什么托管的 SaaS 网关有相反的问题

另一个显而易见的答案是“使用托管的 MCP 网关 SaaS”。这解决了治理问题，但引入了一个更糟糕的问题：您的生产凭据现在存储在第三方。

对于德国 GmbH 或美国受监管实体，这通常会失败：

合规性 — GDPR、BDSG、HIPAA、SOX 都使得将服务账户凭据交给第三方变得复杂（或禁止）
爆炸半径 — 如果 SaaS 被攻破，每个客户的连接生产系统都会同时暴露
供应商锁定 — 凭据、审计日志、角色定义，全部存储在您无法控制的系统中

AnythingMCP 是 自托管设计。网关运行在您的 VPC、您的 Kubernetes 集群、您的 Hetzner 服务器、您的笔记本电脑 — 无论您想要在哪里。凭据永远不会离开您的边界。审计日志存储在您的数据库中。如果您愿意，治理策略可以在您的 git 仓库中版本化。

您可以获得托管网关的治理，同时拥有自托管二进制文件的信任姿态。

为什么这对企业特别重要

我们在企业客户中反复看到三种模式：

模式 1 — 安全审查门

试点项目从 IT 或创新开始。项目一旦进入生产，安全审查就会介入并询问：

我们可以撤销特定用户的访问权限吗？
我们能证明谁调用了哪个工具吗？
凭据存储在哪里，谁可以解密它们？

CLI 服务器在这三方面都失败了。AnythingMCP 用仪表板的截图回答每个问题。

模式 2 — 法律/合规门

法律部门询问：“如果监管机构传唤我们关于 AI 驱动的决策，我们能提供调用记录吗？”

答案需要是肯定的，带有时间戳、用户身份和完整的工具参数。AnythingMCP 的审计日志正是为此结构化的 — 每次调用都是一行，包含时间戳、用户、连接器、工具、参数、响应状态。将其导出为 CSV 以供法律使用只需一行查询。

模式 3 — 跨团队门

一旦一个团队的 MCP 工作正常，三个团队也想要它。如果没有治理，每个团队要么：

获得自己的 CLI 安装（失去中央监督）
与其他团队共享一个安装，没有隔离（一个团队的错误会破坏另一个团队的数据）

AnythingMCP 允许单个实例安全地为所有团队服务 — 销售团队只看到 CRM，财务团队只看到 ERP，工程团队只看到指标数据库。每个团队的 AI 客户端获得不同的 /mcp URL，带有其自己的范围工具目录。

实用设置，端到端

以下是 AnythingMCP 中典型企业部署的逐步流程：

部署网关到您的基础设施中（Docker、Helm、Railway、DigitalOcean — 您的选择）。大约需要 60 秒。
连接 SSO。将 Okta 或 Azure AD 指向网关的 SAML 端点。将您的 AD 组映射到 AnythingMCP 角色。
添加连接器。从仪表板，将 AnythingMCP 指向您的 API（OpenAPI URL、WSDL、数据库连接字符串）。它会自动生成 MCP 工具目录。
定义角色。对于每个角色，选择他们可以调用的连接器和工具（读取 / 写入 / 关闭）。通配符默认为关闭，因此稍后添加新工具时不会意外授予访问权限。
将 MCP 端点分发 给用户。每个用户的 Claude / ChatGPT / Copilot 客户端获得相同的网关 URL — AnythingMCP 根据经过身份验证的用户角色返回范围工具目录。
通过审计日志进行监控。每次调用都存储在您的 Postgres 中；在一个下午内构建一个 Metabase 仪表板。

TL;DR — 为什么选择 AnythingMCP 进行治理

需求	CLI MCP 服务器	托管 SaaS 网关	AnythingMCP（自托管）
用户 + SSO	❌	✅	✅
每个连接器的权限	❌	✅	✅
每个工具的权限	❌	部分	✅
您数据库中的审计日志	❌	❌（他们的）	✅
凭据永远不会离开您	✅	❌	✅
合规友好	❌	❌（大多数）	✅
添加新工具 → 安全默认	❌	变化	✅（失败关闭）
与 Claude / ChatGPT / Copilot 一起工作	✅	✅	✅

如果治理在您的 AI 路线图上，并且自托管是不可谈判的 — AnythingMCP 是唯一能同时满足您这两点的选择。

开始使用

您可以在 AnythingMCP Cloud 上尝试治理模型（7 天免费试用，无需信用卡）或通过单个命令自托管开源版本。两者都提供相同的 RBAC 引擎。

→ 在 Cloud 上免费开始
→ 在 GitHub 上自托管
→ 与团队讨论企业部署