MCP 网关安全：证明每个工具调用都通过了大门

MCP 网关安全性不是通过在架构图中放置代理来建立的。可防御的默认值更严格： 证明每个受保护的生产工具调用都经过了预期的网关，使用了预期的策略修订，携带经过验证的身份和最小特权范围，生成审核收据，并以经过验证的效果或显式等待状态结束 。 这种区别很重要，因为“网关”描述的是一种安置，而不是一种结果。当前的美国搜索结果混合了网关产品、比较、架构解释和安全声明。他们的共同承诺是代理和 MCP 服务器之间的中央控制点。操作问题是该点是否确实拥有特定的呼叫。 这MCP授权规范定义 HTTP 传输、受保护资源元数据、发现和范围选择的授权。协议的安全最佳实践要求实施者考虑混淆代理风险、代币受众验证、代币传递风险、同意和可审计性。这两份文件都没有将中介的存在本身变成每条路线都受到控制的证据。 在路由流量之前定义证据契约 从足够小的路由清单开始，以便在网关配置旁边提供： 该清单创建了五个可测试的断言： 1. 请求通过指定网关而不是直接服务器 URL 传递； 2. 网关验证非秘密工作负载或用户身份； 3. 该决定来自预期的新政策修订； 4. 授予的范围涵盖了选定的工具，而没有悄悄扩大访问范围； 5. 网关发出可以连接到下游结果的审计收据。 路线断言不是理论上的。 Cloudflare 的当前MCP 服务器门户文档描述了工具调用的可选网关路径，而后台同步直接连接到上游服务器。它还警告被阻止的用户仍然可以使用上游服务器的直接 URL，除非在该服务器上强制执行身份验证。这些是合法的特定于产品的行为，而不是通用的 MCP 规则，但它们演示了为什么库存必须包含 所有 路径，而不是假设门户或网关已消除侧门。 每个决定记录一个无内容的信封。它不需要提示、工具参数、结果主体、访问令牌或秘密： 不透明标识符足以测试路由所有权、身份执行、策略新鲜度、范围覆盖范围、批准状态和收据连续性。将秘密价值观保留在其源头。如果事件需要内容检查，请将其视为具有自己的保留边界的单独的、明确授权的工作流程。 授权和策略执行相关但不可互换。 MCP 规范规定授权对于实现来说是可选的；当支持HTTP授权时，受保护服务器充当OAuth资源服务器。因此，网关无法通过记录不记名令牌的存在来制造证据。它必须验证预期的资源和身份，评估相关的工具策略，并保留足够的非秘密证据来解释决策。 MCP 安全指南明确将代币传递识别为反模式，因为它可以绕过控制并损害责任。 重放八项“允许”隐藏的状态 随附的装置包含八个综合请求。它的分类器按操作顺序应用门： 本地运行： 每个判决都需要不同的有界响应： 判决 证据表明什么 下一步行动 GATEWAY BYPASS 受保护的呼叫使用了另一个路由或网关身份 库存客户端和上游端点；关闭或单独治理直接路径 IDENTITY NOT ENFORCED 路线位于中心，但呼叫者未经验证 拒绝匿名生产调用并修复边界处的工作负载或用户身份 POLICY DRIFT 该决定使用了旧的修订版或过时的证据 在重试之前，使正在运行的网关与已批准的策略工件保持一致 AUTHORIZATION GAP 该工具或其所需范围与决策不匹配 拒绝调用、缩小范围并添加工具级回归案例 AUDIT GAP 呼叫可能已被允许，但不存在可加入的收据 修复日志记录/导出路径；保持判决未知而不是绿色 EFFECT UNCERTAIN 运输或工具完成并不能证明目的地 在重试之前读取目的地，尤其是在超时之后 WAITING 受保护的操作具有指定的批准依赖项 通知业主并保留期限；不要给代理贴标签卡住 HEALTHY 路线、身份、政策、范围、审核、批准和效果一致 通过事件审查窗口保留收据 该优先级可以防止方便的批准等待隐藏绕过或过时的策略。 WAITING 仅在路由、身份、策略、授权和审计门通过后才可用。同样，成功的下游效果并不能成为绕过控制路径的调用的借口。 这个实验故意没有内容。它检查标准化合同，而不是实时网关产品。将网关的字段映射到设备，而不是像 MCP 标准化那样复制字段名称。协议定义消息和授权行为；网关策略修订标识符、审计收据形状和目的地验证器仍然是实施选择。 将权限与结果效果分开 允许决策仅证明策略允许尝试。它不能证明该工具运行过一次、更改了预期目的地或生成了所请求的可交付成果。 对于突变，将网关收据连接到目标收据： 这在超时后尤其重要。由于网关未收到响应而重试可能会重复上游系统已提交的效果。 EFFECT UNCERTAIN 指示操作员首先协调目的地。网关可以限制速率或授权重试，但目的地通常是判断原始效果是否存在的更强源。 对于只读工具，结果可能是模式检查、新鲜度断言或与任务所需字段的确定性比较。对于写入，首选 API 读回、不可变对象版本、提供者消息 ID、提交哈希加检查或其他目的地拥有的收据。当承诺的结果存在于其他地方时，工具的 JSON RPC 成功结果会较弱。 实际的部署可以保持狭窄： 1. 选择一台生产 MCP 服务器和一款高影响力工具。 2. 枚举每个客户端端点以及可以到达它的直接上游 URL。 3. 在部署证据中固定网关身份和策略修订。 4. 使用不透明的请求 ID 发送一项允许的探测和一项拒绝的探测。 5. 验证调用者身份、所需范围、工具决策、新鲜度以及两者的审核收据。 6. 尝试记录的直接路由并证明它被阻止或明确受管控。 7. 执行需要批准的调用并将其保留为 WAITING 直到指定所有者决定。 8. 模拟上游效果后的超时，然后证明 Runbook 在重试之前读取目标。 9. 在网关、身份提供商、策略、客户端或 MCP 服务器更改后重复探测。 有限制。该夹具不会测试特定供应商的解析器、DLP 引擎、提示注入防御或漏洞扫描器。它并不能证明中央网关是适合每个本地 STDIO 服务器的正确架构。本地进程可能需要主机级控制而不是网络网关。它还没有使 Sidewisp 成为必需的模型或工具网关。 Sidewisp 的预期作用是相邻的：将可达性、进度、工具、结果、时间和预算证据带入代理健康视图中，并维护恢复方面的人类权威。 Sidewisp 目前处于私密预览阶段。 现场体验是早期访问网站和交互式演示；未发货生产 MCP 网关适配器、实时监控引擎和自动恢复执行器。将强制收据与您当前的网关和目标系统一起使用，而不是假设 Sidewisp 当前正在监视或修复它们。 该解决方案是具体的：清点路线、锁定登机口和策略、验证身份和最低权限范围、需要可加入的审核收据、保留合法等待，并在宣布成功之前检查目的地。仅当控制路径和效果一致时，MCP 网关安全性才成为操作证据。