MCP 网关与 MCP 安全性：网关涵盖的内容
网关检查访问并记录其收到的智能体请求。查看它处理了哪些 MCP 安全风险以及哪些仍需要其他控制。
决策摘要
MCP 的网关是 AI 客户端与其使用的工具之间路径上的检查点。对于收到的请求，它可以检查谁在请求，应用访问规则，将凭据分开，阻止未经审查的工具，路由敏感更改以供审查并记录发生的情况。 MCP 安全性是更广泛的工作：它还涵盖提示注入、每台服务器的代码、笔记本电脑上的本地服务器以及绕过网关的每条路由。大多数团队需要网关和其他控件一起使用。
简短的回答
模型上下文协议 (MCP) 将 AI 客户端（例如 Claude Code 或 Cursor）连接到提供工具的服务器：搜索工单队列、读取文件、更新客户记录。网关位于这些客户端和服务器之间。客户端连接到一个受管端点，网关在传递每个请求之前检查该请求。
MCP 安全性更广泛。它涵盖了智能体工具使用可能出错的所有方式：模型遵循隐藏在内容中的指令、服务器的工具与其声称的不符、令牌在不应该的地方使用、智能体的访问权限超出其任务需求，或者无人知道连接的存在。
因此，比较的重点不是两种产品，而是范围。网关是 MCP 安全性中的一种控制措施，也是对其接收的请求的强大控制措施。问题是它在您的部署中处理哪些风险以及谁拥有其余风险。
每个 MCP 安全风险的处理位置
有两个来源提供了一个很好的起始列表。 MCP 安全最佳实践描述了特定于协议的攻击，例如令牌直通和混淆代理问题。 OWASP 的 MCP Top 10（在撰写本文时还是一个测试项目）将主要风险分为十类。
该表将这十个类别映射到网关可以贡献什么以及必须从其他地方获得什么。这是您自己审查的起点，而不是对任何特定产品的描述，因此请要求演示您所依赖的每一行。
| 风险 | 网关可以做什么 | 还需要什么 |
|---|---|---|
| Token管理不善和秘密暴露 | 让上游凭据远离设备并远离提示，尽管这使得网关成为有价值的目标 | 秘密商店和短暂、范围狭窄的Token |
| 通过范围蔓延来提升权限 | 限制每个团队的工具、资源和操作，并审查新的访问权限 | 缩小 OAuth 范围和定期访问审查 |
| 工具中毒 | 阻止工具，直到它们被审查并将更改的定义视为新审查 | 在审批之前审查服务器和标记更改的客户端 |
| 供应链攻击和依赖篡改 | Little：它不能检查服务器代码，只能限制连接哪些服务器 | 出处检查、固定版本和软件物料清单 |
| 命令注入和执行 | 部分：它可以拒绝超出审查模式的参数 | 服务器中的输入验证和安全命令处理以及沙箱 |
| 通过智能体读取的内容进行提示注入 | 限制被误导的智能体可以达到的范围并保留相应的更改以供审查 | 模型和客户端辩护和确认提示 |
| 身份验证和授权不足 | 检查收到的每个请求的身份和访问权限 | 每个服务器仍然强制执行自己的访问控制 |
| 缺少审计和遥测 | 记录路由请求的决策和结果 | 其他所有内容的客户端、服务器和端点日志 |
| 影子 MCP 服务器 | 对于从未收到的请求，没有任何内容 | 发现、端点清单、网络控制和简单的批准路径 |
| 上下文注入和过度共享 | 限制哪些工具可以读取和检查已配置的响应 | 数据分类和模型提供者的数据术语 |
网关的优点是什么
网关很有价值，因为它收到的每个请求都会经过相同的检查，无论哪个客户端发送它。它可以确认谁在询问，他们是否仍然属于该团队，以及他们是否可以使用这个连接、工具和资源。这些决策位于一个地方，而不是在每个客户端和服务器中不一致地重复。
它可以将凭据分开。人们登录到网关，网关使用为该系统颁发的凭据来调用上游系统。 MCP 规范禁止直接传递客户端的Token，因为这样做会绕过上游系统的控制，并且不会留下有关谁操作的明确记录。
它可以将工具视为要审查的事物。工具名称和描述是模型读取和操作的文本，因此保留未经审查的工具并将更改的定义视为新审查的网关可以弥补协议留下的空白。它还可以将敏感更改发送给审阅者并记录决策和结果。
网关有自己的安全职责
网关集中访问，因此它值得与任何为其他许多人保存凭据的系统一样受到同样的审查。在MCP安全最佳实践中，将客户端连接到第三方API的服务器称为代理服务器，它具有特定的义务。
此类代理必须在转发到第三方授权服务器之前征求每个客户端的同意，准确匹配重定向地址并验证 OAuth 状态参数。如果没有它们，攻击者可以利用用户之前的同意来获取用户从未授予的访问权限，规范中将其称为混淆代理攻击。
网关还代表人们获取元数据并调用上游服务器。该规范期望部署在服务器上的客户端能够防止服务器端请求伪造，例如通过要求 HTTPS、阻止私有地址范围和检查重定向。询问网关如何处理这些流量，以及如果它存储的凭据受到损害，会发生什么情况。
网关外面有什么
网关看到的是请求，而不是请求背后的推理。如果文档告诉模型将数据发送到某处，并且该请求是允许该人发出的请求，则仅策略检查无法区分指令的意图。 Anthropic 描述的即时注入远未解决问题。狭窄的权限和对后续行动的审查限制了危害；他们不会让内容变得值得信赖。
本地服务器也在其外部。在笔记本电脑上启动的服务器以用户的权限运行，其流量永远不会到达远程网关。 MCP 项目指南将这些视为需要端点和软件治理的普通软件。
工具注释（例如工具仅读取数据的提示）也不是强制执行。 MCP 维护者建议在确定性控制中保持安全保证。最后，当通过另一个路由使用相同的凭据时，网关的规则不适用，并且它无法看到客户端发送到其模型提供者的内容。
示例：包含隐藏说明的支持票
考虑一个说明性支持智能体，它读取票证并可以查找客户记录。收到的票证中包含告诉智能体导出完整客户列表并将其附加到回复中的文本。
模型可能遵循也可能不遵循说明；这取决于型号和客户。如果尝试，网关会检查此人是否可以在该资源上使用导出工具。如果该工具从未启用支持，则请求将被拒绝。如果已启用并且团队需要审核导出，则审核者会在运行任何内容之前看到确切的请求。
如果允许导出并且不需要审核，则网关没有什么可反对的：所给的规则允许该请求。这就是为什么工具设计和访问选择与检查点本身一样重要。
MCP 安全工具如何配合
作为 MCP 安全出售的产品通常执行与网关不同的工作。扫描程序会在您批准服务器包和工具描述之前检查隐藏的指令。运行时监视器在智能体工作时检查内容和行为。发现工具查找设备上配置的 MCP 服务器。
这些是对网关的补充，而不是取代它。扫描会通知您批准哪些服务器，检查会添加策略单独无法提供的内容检查，而发现会显示哪些路由仍然绕过您的控制。当您评估网关时，这些问题会显示它在您的部署中强制执行的内容：
- 网关实际上会看到哪些请求，哪些路由会绕过它？
- 客户端登录和上游凭据如何保持分离？
- 如何审查工具定义？当工具定义发生变化时会发生什么？
- 访问是否可以受到工具、资源和操作类型的限制，而不仅仅是连接？
- 对拟议变更的审核如何进行？审核者会看到什么？
- 记录是否将访问决策与操作结果分开？
Durin 的适用位置
Durin 通过网关为需要智能体请求一致规则和证据的团队提供 MCP 治理。对于通过它路由的请求，每个呼叫必须通过当前身份、成员资格、团队、连接、凭据、经过审查的工具、资源和检查检查。工具在经过审核之前会一直处于锁定状态，并且更改后的工具定义需要重新审核。 Durin 使用连接自己的凭据调用提供者，并且不会向上游传递自己的令牌。
经过检查的请求可以在默认情况下继续进行这些检查。团队可以默认拒绝访问或要求其他管理员审核建议的更改；然后，请求者在权限过期之前再次发送相同的请求。 Durin分别记录决策和结果，不确定的结果永远不会自动重复。
Durin 不会阻止提示注入，也无法控制绕过它的请求。其 Shadow MCP 发现报告注册设备上配置的 MCP 服务器，这可以帮助您找到这些路由；它不会阻止他们。模型、客户端、端点和服务器控制仍然是计划的一部分。