MCP访问治理：谁可以使用哪些工具和数据
将每个 MCP 请求与一个人联系起来，通过团队授予访问权限，根据工作需要保留工具和数据，并在人们改变角色时保持最新的访问权限。
决策摘要
MCP 访问治理决定谁可以使用哪个 MCP 连接、工具和数据，并随着时间的推移保持答案的正确性。将每个请求与一个人而不是共享密钥联系起来，通过团队授予访问权限，根据工作需要保留工具和数据，定期审查访问权限并测试撤销是否有效。网关可以将这些规则应用于它收到的请求；上游系统自身的权限仍然设置外部限制。
MCP访问治理意味着什么
模型上下文协议 (MCP) 允许 Claude Code、Cursor 或 Codex 等 AI 客户端通过提供工具的服务器连接到公司系统：搜索工单队列、读取文档、更新客户记录。每个工具请求都会代表某人到达系统。
Access 治理会询问您的身份团队已经针对应用于这些请求的任何应用程序提出的问题。谁可以使用这个连接？每个人需要哪些工具和数据？谁同意了该访问权限？当他们的角色发生变化时，访问权限会以多快的速度结束？
有一个区别很重要。 智能体通常根据刚刚读取的内容来选择调用哪个工具以及发送什么内容。一个人可能有权使用某个工具，而无需考虑智能体可以使用该工具提出的每项请求。这使得狭窄的权限和每个请求的清晰记录比平时更加重要。
访问是分层决定的
单个工具请求会传递多个访问决策。把它们写下来可以看出哪个系统强制执行每一项，以及哪里还存在差距。
上游系统自身的权限是外部限制。网关规则可以缩小某人可以通过它执行的操作，但它无法授予他们凭据缺乏的权限。
| 图层 | 问题 | 示例控件 |
|---|---|---|
| 身份 | 谁提出请求？ | 使用智能体的人员单点登录 |
| 成员资格 | 他们还属于组织和团队吗？ | 自动同步的目录组 |
| 客户端会话 | 该客户是否仍获得授权？ | 每个客户端可以撤销的会话 |
| 连接 | 他们能使用这个系统吗？ | 连接分配给特定团队 |
| 工具 | 他们可以使用哪些操作？ | 审查了工具，并再次审查了更改 |
| 资源 | 哪些记录、文件夹或项目？ | 允许的资源或路径前缀 |
| 凭据 | 上游系统看到谁的权限？ | 每个人自己的 OAuth 授权范围较窄 |
将每个请求与一个人联系起来
共享 API 密钥是治理访问崩溃的常见位置。当每个人的智能体使用一个Token时，上游系统会看到单个用户，撤销它会影响每个人，并且记录无法显示谁请求了什么。
优先选择每个人自己对上游系统的授权（通常通过 OAuth），并让他们使用您的常规身份提供商登录到任何网关。 MCP 授权规范基于 OAuth 2.1。它期望服务器只接受为其颁发的令牌，并且禁止将客户端的令牌直接传递到另一个服务。
有些工作适合服务身份，例如无人在场的预定工作。为该身份提供一个负责任的所有者、有效的最窄权限及其自己的记录，因此其活动永远不会被误认为是一个人的活动。
通过团队授予访问权限
将连接一次分配给一个人很难回顾，而且很容易忘记。相反，将它们分配给团队，最好是来自您的身份提供商的组，以便新加入者获得正确的访问权限，而离开者在目录更改时会失去该访问权限。
开始狭窄。将敏感的连接提供给需要它的团队而不是整个组织，然后为特定工具或资源添加条件。在示例性的财务团队中，每个人都可以阅读一个文件夹中的发票，而一小部分人可以更新付款详细信息。
注意间接到达的访问。两个团队中的某人可以通过任一团队访问连接，因此将他们从一个团队中删除并不一定会删除他们的访问权限。
让智能体能够访问工作所需的内容
OWASP 将过度代理列为基于大型语言模型构建的应用程序的主要风险之一。如果智能体被赋予比其任务所需更多的功能、权限或自主权，则当它被误导或完全错误时，可能会造成伤害。提示注入是发生的一种方式，其中智能体读取的文本尝试重定向它。
MCP 的最小特权在三个级别上起作用。仅启用工作流程所需的工具。将这些工具限制在工作涉及的资源范围内。仅请求启用的工具所需的 OAuth 范围，因为连接的令牌通常可供该连接上的每个工具使用。 MCP 安全指南建议从最小范围开始，仅在需要时要求更多范围。
阅读值得关怀，也值得改变。只能读取客户记录的工具仍然可能会暴露它们。一种实用的模式是为试点小组提供只读访问权限，确认边界成立，并在团队了解智能体的行为方式后允许进行更改。
审查访问权限和测试撤销
访问漂移。项目结束，人员更换团队，暂时的例外变成永久性的。将 MCP 连接包含在您已经运行的访问审核中，每个连接的所有者确认谁应该保留访问权限。有用的审核涵盖以下几点。
然后直接测试撤销。删除测试成员并重复来自已登录客户端的请求。应拒绝该请求，并且较早的审批不应恢复访问权限。
- 今天谁可以使用每个连接，以及通过哪个团队或例外。
- 启用了哪些工具和资源，以及是否仍然需要它们。
- 连接使用谁的凭据以及它们授予哪些范围。
- 哪些客户会话仍然处于活动状态，尤其是对于已经离开的客户。
- 期间使用的内容与允许的内容进行比较。
将请求与批准分开
对于产生严重后果的行为，例如发送付款、删除记录或向客户发送电子邮件，仅访问可能是不够的。其他人可以在运行之前查看建议的操作。该审核者不应该是请求者，并且决定应该涵盖具体操作而不是授予开放式许可。
保持此审核的适当性。要求对每一个小动作进行审查会造成疲劳，并使重要的请求更难发现。根据错误可能造成的危害程度来选择需要审查的操作。
保留访问和使用的证据
两种证据回答不同的问题。当前访问显示了今天谁可以使用连接以及原因。请求记录显示谁使用了它、决定了什么以及接下来发生了什么。访问审查需要两者。
保持记录相称。决策记录很少需要完整的提示或响应，存储这些内容本身就产生了隐私义务。记录也只涵盖他们观察到的路线；绕过网关的请求需要自己的控制。
Durin 的适用位置
Durin 将访问治理应用于通过其网关路由的 MCP 请求。在应用团队规则之前，每个请求都必须通过当前身份、成员资格、团队、连接、凭据、经过审查的工具、资源和检查检查。 连接的范围可以限定为团队，团队规则可以为特定工具、资源或人员添加条件。
人们登录到自己的 Durin 端点，上游请求使用为该连接配置的提供商凭据； Durin 不会将自己的令牌传递给提供商。撤销成员资格或客户端会话适用于以后的请求，早期的审批无法恢复访问。 Enterprise 组织可以从其身份提供商同步用户和组；每个套餐都提供本地用户、群组和邀请。
经过检查的请求可以在默认情况下继续进行这些检查。管理员可以选择默认拒绝工具访问或要求其他管理员审核建议的更改。访问图显示当前谁可以使用连接以及原因，而审计显示请求运行时记录的决策。不通过 Durin 的请求需要自己的控制。