MCP治理和MCP 网关在团队生产中的实际意义
53% 的 MCP 服务器使用静态 API 密钥。了解你的团队如何在生产环境中控制影子 MCP、凭证和审计跟踪所需的四个治理基本要素。
MCP部署完成后，它就成为一个运行时层，允许AI Agent(如 cursor , claude, trae, 或者其他 vibecoding， ai chat工具)调用其背后的能力、访问数据并在你的系统中执行操作（如可以通过配置 filesystem MCP去让AI在生产环境出现异常时快速帮你检索异常日志，这可以将你的问题排查效率从十多分钟降低到几分钟甚至数十秒钟）。此时，治理的重点在于控制和可见性——哪些MCP服务器被允许访问、凭据如何颁发和限定范围、可以访问或写入哪些数据，以及是否每个操作都可以追溯到用户。
如果没有明确的控制措施，生产环境中的 MCP 很快就会变成一个不受监控的访问层。不过别担心，本文将解决这个问题。它将详细讲解如何在实际系统中安全运行 MCP，并防止它成为您基础设施中不受监控的访问层。
为什么不受监管的MCP会造成生产责任
MCP的风险在于它很容易被滥用，缺乏必要的防护措施：
- 影子 MCP：开发人员只需几分钟即可将代理连接到 MCP 服务器，通常无需经过任何审核流程。这意味着代理可能正在调用来自未经审查的服务器的工具，而 IT 和安全团队甚至都不知道这些服务器的存在。防止这种情况发生的首要任务是限制可以使用的服务器范围，而不是仅仅信任开发人员能够正确选择， 比如同样是上服务器上看日志， 可以使用 shell MCP做高危操作，也可以使用 filesystem MCP做安全读取，这两者都能解决这个问题， 但大多数初中级工程师往往会选择危险更大也更简单的shell MCP
- 凭证泄露：大多数 MCP 集成仍然依赖于不安全的模式。约 53% 的集成使用静态 API 密钥，只有 8.5% 使用 OAuth，而 79% 将凭证存储在环境变量中。MCP 本身最初发布时并未内置身份验证功能，虽然在 2025 年 3 月添加了 OAuth 支持，但它仍然是可选的。其结果可想而知：令牌共享、轮换机制薄弱，以及操作和用户之间缺乏清晰的映射关系。
- 供应链风险： Postmark MCP撤回就是一个很好的例子——一个非官方软件包冒充 Postmark 名称，并作为合法集成程序分发。这表明在 MCP 生态系统中，信任是多么容易被滥用。
这三种情况都会加剧风险。一旦 MCP 服务器遭到入侵，它不仅会暴露自身，还会继承代理的权限，从而成为直接访问内部数据和系统的途径。
每个 MCP 部署都需要四个治理原语。
大多数风险都源于MCP 的去中心化设计——没有一个统一的平台来强制执行控制。每个服务器都定义了自己的工具、身份验证和行为。由于缺乏统一的层级，治理最终会分散到每个集成中，无法扩展。
一个可行的方法是围绕以下四个核心原语进行标准化：
| 原始 | 它的作用 | 威胁已解决 |
| 受信任注册表（下一节将对此进行更详细的介绍） | 允许列表中的 MCP 服务器及其暴露的工具 | 影子 MCP |
| 集中式身份验证 | 使用基于用户的认证key或者OAuth，而不是共享的静态令牌。 | 证书曝光 |
| 运行时策略执行 | 在执行前评估并阻止未经授权的工具调用。 | 不受控制的代理写入，个人身份信息泄露 |
| 审计日志 | 记录每次调用，包括用户身份、参数和结果 | 没有审计追踪，不符合监管规定 |
像 orbitproxy这样的 MCP 网关可以从单个控制点强制执行所有四项策略。它不再像以前那样针对每个服务器单独实施控制，而是作为位于代理和 MCP 服务器之间的单一控制点。它负责执行注册表检查、处理身份验证、强制执行运行时策略，并一致地捕获所有流量的日志。
哪些服务器可以运行？
控制 MCP 首先要问一个基本问题：你的AI Agent到底可以连接到哪些服务器？
做法是建一份"可信注册表",也就是白名单。只有登记在册的服务器才能被 Agent 连接。每条记录建议写清楚:服务器是谁、具体用哪个版本(最好附上 SHA-256 哈希,用来确认代码没被改过)、提供哪些工具、谁负责、有没有通过审批。
要注意,官方公共目录只能帮你"找到"服务器,不能证明它们"安全",因为它通常只核实服务器归谁所有。所以,不要把它当成信任依据。
最后,白名单要真正用起来,得让合规的方式比绕过更方便,否则开发者会自己想办法绕开。
orbitproxy 的 MCP 网关实现了这一点，因此只有经过批准的服务器和工具才能被代理访问
谁可以访问哪些内容，凭证是如何运作的？
在许多部署环境中，AI Agent使用共享 API 密钥或长期有效的令牌连接到 MCP 服务器。这在快速演示中可行，但在生产环境中却行不通。共享凭据在日志中无法区分，这意味着您无法确定是哪个用户触发了操作。随着使用规模的扩大，轮换令牌会变得非常麻烦。而且，如果单个令牌暴露，实际上就等于授予了对该令牌所能访问的所有内容的访问权限。
解决这个问题的办法是为团队每个成员的每个Agent 单独分发密钥， 这在一定程度上可以缓解这个问题，也能让你更加清晰的明白到底是谁触发了这什么行为，在发现密钥泄露时也可以做到单个直接吊销和轮换
另一种方法是基于用户的身份验证，通常使用 OAuth 2.1。AI Agent不再以通用服务的身份进行身份验证，而是代表实际用户执行操作。每个请求都包含用户身份、权限范围和过期时间。这立即提高了可追溯性，限制了影响范围，并使撤销操作变得切实可行。
在生产环境中，这通常通过 SSO（单点登录）与您现有的身份提供商集成，使用 SAML 或 OIDC。这样，MCP 访问就能继承您在整个组织中已实施的身份控制、组映射和策略。身份验证不再是 MCP 的附加组件，而是成为您更广泛的访问模型的一部分。
网关层是实现这一功能的关键。网关集中处理身份验证，而不是让每个 MCP 服务器各自独立地进行身份验证。它管理 OAuth 流程、验证 JWT，并确保发送到 MCP 服务器的每个请求都经过身份验证、限定了范围并可归因于特定用户。
例如，orbitproxy的 MCP 网关支持 OAuth 2.1、JWT 验证，并可与企业身份提供商 (IdP) 直接集成，从而在所有服务器上强制执行一致的身份验证。
运行时强制执行和数据保护
身份验证用于确定用户身份。治理还需要确定用户被允许执行哪些操作，以及允许哪些数据通过以下层级进行传输：
- 第一层——工具级基于角色的访问控制 (RBAC)：多级控制(MCP) 权限不能止步于服务器级别，因为单个服务器可能暴露数十个工具，包括读写操作。访问权限需要在工具级别定义——谁可以在什么条件下以及在什么上下文中调用哪个工具。orbitproxy会针对组织、工作区、团队和用户强制执行工具级 RBAC ，因此默认情况下访问权限不会过于宽泛。
- 第二层——PII 脱敏和数据控制：敏感数据应在网关处进行过滤，在到达 MCP 服务器之前，或在响应返回给AI Agent之前进行过滤。这确保即使是受信任的工具也不会接收或泄露不应接收或泄露的数据。
- 第三层——针对高风险操作的人为控制：诸如写入生产系统、触发支付或修改记录等操作，在执行前需要经过审批，未审批操作会被直接拒绝。这在关键环节引入了阻力，同时又不会减慢低风险交互的速度。
这些控制措施共同将 MCP 从开放的执行层转变为受控的执行层，其中访问范围受到限制，数据受到保护，高影响力操作经过深思熟虑。
审计追踪和监管合规性
如果 MCP 是执行层，那么审计日志就是实际发生情况的唯一可靠记录。
一个可用于生产环境的 MCP 审计跟踪系统需要记录的信息远不止基本的请求日志。至少，每次交互都应包含用户身份、时间戳、会话 ID、提示信息、工具名称、参数、服务器身份、响应以及访问的任何数据源。其目标是实现不可否认性——您需要能够证明哪个代理代表哪个用户调用了哪个工具，以及最终结果是什么。
这就是 MCP 治理与 NIST AI 风险管理框架和 ISO/IEC 27001:2022 等合规框架直接连接之处。前面讨论的基本要素可以清晰地映射到现有的控制措施：
| 框架 | 原始 | 条款 |
| NIST AI RMF | 登记处 | 治理 |
| NIST AI RMF | 威胁建模 | 地图 |
| NIST AI RMF | 溯源追踪 | 措施 |
| NIST AI RMF | 纵深防御控制 | 管理 |
| ISO 27001:2022 | 用户级 OAuth | 附件A 5.15–5.18 |
| ISO 27001:2022 | DLP/PII 编辑 | 附件A 8.11–8.12 |
| ISO 27001:2022 | 溯源日志 | 附件A 8.15–8.16 |
| ISO 27001:2022 | 私人登记处 | 附件A 5.19–5.20 |
这里存在一个常见的误解。像 NIST AI RMF 和 ISO 42001 这样的框架经常被引用来解释“人工智能治理”，但它们主要关注模型层面的风险——偏差、可解释性和生命周期管理。它们并没有全面解决可以通过工具采取行动的代理系统，而这正是 MCP 的适用范围。
正是由于这种差距，详细的审计跟踪才显得尤为重要。如果没有这些跟踪记录，MCP 在安全性和合规性方面都会成为盲点。
构建您的治理堆栈
正如您所见，MCP治理需要从一开始就构建。实施步骤很简单：首先建立一个可信注册表来控制哪些服务器可以运行；然后添加集中式身份验证，将每个操作与用户关联起来；接着强制执行运行时策略来控制代理可以执行的操作；最后添加审计日志，使每个操作都可追溯。
难点在于如何将这些碎片化的部分整合起来。
orbitproxy 的 MCP 网关在一个控制点上提供了所有四个层级的功能。它是可以自托管可私有化的，旨在强化治理，同时又不拖慢团队的效率。
常见问题
为什么要用 MCP 网关，而不是在每个服务里各自做？
因为 MCP 服务是各自独立的，鉴权方式、日志格式和权限模型都不一样。逐个改造成本高、口径乱。网关把准入、认证、管控、审计集中到一个入口，规则只维护一份。
MCP 网关和传统 API 网关有什么区别？
传统 API 网关面向的是"服务调用服务"，关注路由、限流和鉴权。MCP 网关面向的是"Agent 调用工具"，除此之外还要处理工具级权限、工具列表的动态变化、敏感数据脱敏以及高危操作确认，这些是 Agent 场景特有的。
已经在用 MCP 的团队，应该从哪里开始？
先盘点：把现在实际在用的 MCP 服务和凭证摸一遍，再依次完成准入收口和统一认证。这两步投入最小，风险降低最明显。