← 返回藏书阁

MCP Gateway 1.31：发现凭据的用途隔离与真实执行路径验收

wiki/ai/sources/mcp-gateway-discovery-purpose-and-live-vend-131.md
分类：ai / sources · 更新：2026-10-04 09:04

MCP Gateway 1.31：发现凭据的用途隔离与真实执行路径验收

一句话结论 / 为什么重要

发现工具本身需要上游身份，但发现身份不该自动变成执行身份。 MCP Gateway & Registry 1.31.0（2026-09-23 发布；本轮 10-04 补读固定 tag）给了一个可迁移的做法：同一主体和同一上游的 discovery 与 runtime egress 分开寻址、加密绑定；选取凭据不跨身份回退；再分别检查注册/发现/调用的真实通路。对用户的 Hermes cron、群聊和个人会话尤其重要：不能把某个用户 OAuth 连接当作后台 job 的可继承能力。此处是外部项目机制，不表示 Hermes 已运行这个网关。^[raw/articles/mcp-gateway-131-discovery-purpose-and-live-vend-selected-2026-10-04.md]

一阶机制：从获取工具清单到真实效果

  1. 无人的 discovery 仍可能需要身份。 上游 initialize 先返回 401 时，网关可选机器 client_credentials、经 owner 同意后借用的用户发现身份，或 Entra app-only OBO 凭据；三层是排他 dispatch 而非依次试不同 principal。机器 token 获取失败时终止，不能偷偷换用户身份。默认 cognito 并不实现第三层：功能存在≠默认启用且有效。
  2. vault 地址与密文同时隔离用途。 egress token 与 borrowed discovery token 即使 user_id/provider/server 相同，purpose 仍分出独立地址，CredentialCodec._aad() 把非-egress用途附在 AES-GCM associated data；把密文从 egress 路径复制到 discovery 路径，解密 tag 校验会失败。为兼容旧密文，egress 的 AAD 字节不变。但配置未开加密时 legacy plaintext 可以被读写；即使开加密，只有启用 strict require_encrypted 才拒绝旧明文；不能泛化为所有部署默认加密。
  3. 调用不该借发现身份。 发布说明称 nginx 代理 tools/call，registry 的发现用 Python resolver 不在这条执行路径；真实调用带 caller 自己的 header。读到固定版的跨用途解密负例测试断言，但未在本机运行仓库测试；作者报告对 GitHub 托管 MCP 发现 45 tools，是作者端到端报告，不是本轮实测。
  4. 已写规则未必在实际路径执行。 同版修复 OBO target_audience/scope allowlist 原仅在未构造的模型 validator 中，write/vend 真正路径未覆盖。这说明要给每个批准动作标注 write → vend → proxy → downstream effect 的入口及断言，不能从 schema 合法推断真实出站安全。^[raw/articles/mcp-gateway-131-discovery-purpose-and-live-vend-selected-2026-10-04.md]

与既有知识的关系

agentic-community-mcp-gateway-registry-ai-asset-control-plane 已说明 AI asset catalog、原生/generic A2A 路由与成功码分层；本页只补 1.31.0 的发现用途和调用身份，不再写第二份项目介绍。langchain-per-caller-connections-credential-ownership 讲 owner/caller 映射，本例把用途下沉到 vault 地址和 AEAD；fides-gateway-ifc-policy-as-effectful-tool 提醒策略检查本身也可能有副作用，因此“先发现再拒绝”不能默认零 effect。MCP-Gateway-Runtime 的 ingress/egress 双凭据要扩展为“谁/什么用途/哪个阶段/哪个最终目标”。

可操作验收 / Hermes 与 llm-wiki

  • 在隔离 mock 网关设计 caller × purpose × protocol × stage × target × outcome 小矩阵：personal/cron/peer 三类主体；discovery、call、OBO vend 三阶段；机器 token 错误、owner 未同意、密文跨用途复制、allowlist 禁止 audience 各测拒绝且真实上游零调用。
  • 分别存注册时/发现时/调用时的 identity、policy verdict、凭据来源（只存类型与不可逆标识）、route、HTTP 返回与上游 effect。发现成功只能说明工具枚举成功，不能代表 tools/call 权限；401/403 要定位哪一跳。
  • 独立测每种部署有效配置：SECURITY_ALLOW_UNSAFE_SERVERS 默认 false 仍是整 server 屏蔽，打开后才有逐 tool 屏蔽；把工具显示/授权/调用分别核对。异构网关只复用验收矩阵，不直接移植它的 token 配置。

边界 / 未解

  1. Release 作者对 GitHub 的 hosted MCP 报告不是我们本机 E2E；固定 tag 的 selected release/code/test 阅读也不等于全量 diff 审计。
  2. 借用真实用户 OAuth 做后台发现虽有用途隔离，仍涉及同意范围、过期/撤销、owner 离职与审计归属；仅 AEAD 无法证明 consent 正确。
  3. 1.31 出站连接池按已验证 IP pinning，但 release 说明复用连接对第二个 hostname 不重新核对证书覆盖；跨 hostname 复用需专项测，不将“防 DNS rebinding”扩展成“TLS 身份已完全绑定”。联想 contextforge-egress-path-parity-dns-rebinding，需逐路径证明。
  4. 本轮 A2A 真实 Card 候选并不等于发现身份→任务成功→终态的完整链；本页不声称解决 A2A E2E 缺口。

写入记录

  • 2026-10-04 09:04 CST：固定 1.31.0 版本补读发布说明、凭据 codec 与测试断言，提炼 discovery/runtime 用途隔离、排他凭据分派与真实 write/vend 路径验收；未运行网关测试或部署。
藏书阁 · Published from llm-wiki · 2026-11-02 09:29:27