本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# MCP 治理策略
<a name="mcp-governance-strategy"></a>

MCP 为组织提供的另一项关键功能是支持集中式治理。您的 MCP 治理策略应解决对 MCP 服务器及其访问的资源的身份验证和授权问题。它还应解决保护下游资源的速率限制、监控工具使用情况和性能的操作指标以及管理 MCP 服务器的部署和分发的问题。

## 身份验证和授权
<a name="mcp-governance-strategy-auth"></a>

身份验证和授权策略中最重要的部分之一是管理来自 MCP 服务器的下游资源访问。当用户呼叫代理时，会执行身份验证和授权，以确保用户有权呼叫代理。然后，代理在 MCP 服务器中协调调用特定工具。您需要决定如何根据每个工具授权访问权限。

一种选择是*machine-to-machine 授权*，即不需要用户同意或互动。例如，基于时间的代理调用使用 MCP 服务器从应用程序收集日志并对其进行分析。在这种情况下，代理已获得访问指定数据的预授权。第二种选择是*用户委托访问权限*，即用户同意访问用户特定的数据和资源。

下表显示了身份验证和授权模式。


| 
| 
| **因子** | **用户委托的访问权限** | **Machine-to-machine** | 
| --- |--- |--- |
| 数据所有权 | 用户特定的数据授权 | 系统或组织范围的数据 | 
| 用户互动 | 用户在场并可以同意 | 没有用户互动 | 
| 操作时机 | 交互式或实时 | 后台、预定或批处理 | 
| 权限范围 | 权限因用户而异 | 代理级别的权限一致 | 

用户委派的访问需要谨慎实施，并且应与您的安全团队共同开发。代理必须能够评估法学硕士选择了哪些工具以及它们是否需要额外的授权。MCP 工具必须包括描述，以说明其身份验证和授权要求以及在何处检索访问令牌。客户端应用程序必须支持中间身份验证请求，MCP 客户端必须为每次工具调用向代理提供检索到的凭据。

您应确保 MCP 工具始终拥有自己的令牌来访问外部功能，并确保对访问进行记录和审计。用户凭据不应通过您的代理系统传播。例如，您的 MCP 服务器不应使用相同的令牌来访问用于调用代理的数据。下游调用应使用明确范围的、目的生成的令牌。这有助于提供额外的防护措施，防止以操作的名义意外访问数据。它还可以帮助防止幻觉产生意想不到的结果。想象一下，具有完全管理员权限的用户要求代理克隆生产数据库以用于预生产。为此，用户只需要`READ`和`CREATE`权限。假设法学硕士产生了幻觉，并认为作为此请求的一部分，它需要清理旧数据库。如果它重复使用用户的证书，则很可能会成功，因为用户的原始凭证具有`DELETE`权限。相反，如果 MCP 服务器为请求使用故意缩小范围的令牌，则删除`CREATE`生产数据库的尝试将失败。`READ`

您可以使用 [Amazon Bedrock AgentCore Identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/common-use-cases.html) 来帮助实现这些模式。请务必故意选择列出和调用 MCP 服务器托管的工具的权限是否意味着对 MCP 服务器公开的外部功能的权限。这种从 MCP 服务器到资源再返回用户的身份流取决于所使用的身份验证和授权服务的类型。您必须决定如何在 MCP 服务器上大规模处理此问题。

在设计身份验证和授权模式时，请实施令牌隔离机制，为正在访问的每个工具检索不同的访问令牌。不要在工具和服务器之间重复使用令牌。 AgentCore 身份提供了这种令牌隔离功能。它会自动管理工作负载令牌（用于 machine-to-machine身份验证）和用户令牌（用于用户委托的访问），以确保正确分离并防止权限升级。在整合远程 MCP 服务器或 MCP 网关时，这一点尤其重要。

### MCP 身份验证和授权的最佳实践
<a name="mcp-governance-strategy-auth-best-practices"></a>
+ **代币分离** — 不要将不记名代币从调用者传递给下游服务。验证 aud（受众）字段与接收令牌的服务器相匹配。受众声明指定了令牌的用途，从而防止在不同的 MCP 服务器上重复使用未经授权的令牌。
+ **选择访问方法** — 在 MCP 服务器提供的每种工具 machine-to-machine和用户委派访问之间进行选择。考虑将使用相同身份验证模式的同一 MCP 服务器中的工具组合在一起。

## 控制负载
<a name="controlling-load"></a>

与任何分布式系统一样，您必须考虑如何控制 MCP 服务器群中的负载。首先，您需要考虑是否在 MCP 服务器中实施速率限制以及在何处实施限制。如果您选择不实施速率限制，则会传递下游资源执行的任何速率限制。许多系统选择根据请求属性（例如用户或账户 ID）进行速率限制。验证发送到下游服务的请求是否具有相同的属性，这样多个用户就不会受到其他用户驱动的负载的影响。

如果您确实选择实施速率限制，则推荐的方法是在 MCP 服务器级别实施主速率限制，后端服务提供二级保护，代理根据速率限制反馈调整其行为。考虑速率限制是针对每个 MCP 服务器还是每个工具。每个 MCP 服务器的速率限制有助于在多租户环境中保护您的 MCP 服务器群和服务。但是，这可能非常粗糙。每个工具的速率限制旨在防止下游资源不堪重负，而这些资源本身可能没有足够的速率限制。如果工具调用多个 APIs，则应将速率限制设置为与这些工具允许的最低速率保持一致 APIs。

对于用户和自动化系统来说，在 HTTP 标头中传递速率限制信息也是一个有用的指标，可以帮助他们管理自己的请求速率和重试策略。例如，您可以将这些标头从 MCP 服务器发送回代理，如以下示例所示：

```
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640995200
```

此外，当没有一个客户超过速率限制但负载影响系统性能时，可以考虑减负以保护整体服务。

### 控制负载的最佳实践
<a name="mcp-governance-strategy-load-best-practices"></a>
+ **选择速率限制方法** — 计划根据个人用户对下游资源的使用情况或通过他们对您的 MCP 服务器和工具的使用情况对他们进行速率限制。
+ **考虑减载** — 保护您的 MCP 服务器群免受非单个或少数客户导致的普遍过载的影响。

## 运行指标
<a name="mcp-governance-strategy-metrics"></a>

MCP 实施需要捕获的关键指标应侧重于其提供的客户体验。这些指标通常包括令牌使用情况、工具选择准确性、向代理注册的工具数量和工具延迟。例如，监控每个工具返回的输出令牌使您能够在工具超过上下文窗口使用阈值时设置警报。当工具超过该阈值时，您可能需要查看该工具的行为。这也与 MCP 工具设计策略有关。工具选择精度指标表明了代理为给定任务选择合适工具的程度，而执行速度和成功率则突显了性能瓶颈和可靠性问题。

例如，为了评估工具选择和工具使用准确性指标， AWS 团队创建了用于回归测试的黄金数据集。这些数据集是在用户查询时使用 LLMs 历史 API 调用日志综合生成的。使用预定义的工具选择和工具使用指标（例如工具选择精度、工具参数精度和多回合函数调用精度）， AWS 团队可以客观地评估 AI 代理正确识别适当工具、用准确的值填充参数以及在对话回合中保持连贯的工具调用序列的能力。

衡量有关向代理注册的工具数量的指标可以帮助您识别潜在的上下文窗口管理挑战以及 MCP 服务器提供的可用工具的变化。您应该定期查看运行指标，这些指标表明 MCP 服务器和工具的用户体验。