MCP Gateway Runtime

wiki/ai/concepts/MCP-Gateway-Runtime.md

分类：ai / concepts · 更新：2026-09-12 09:18 最近更新

MCP Gateway Runtime

身份与凭证边界： enterprise-mcp-persona-credential-boundaries 将 User/Non-user 与下游 credential 分轴，强调 User→SA 必须在附加凭证前验 entitlement。论文的机器 ROPC 做法与 RFC 9700 §2.4 冲突；RFC 8693 历史 act 仅作信息记录，不是双边授权证明，撤销也不会自动传播。详细标准对照与 contested 标记保留在 source。^[raw/articles/enterprise-mcp-persona-credential-boundaries-2026-09-12.md] ^[raw/articles/rfc9700-oauth-security-selected-sections-2026-09-12.md] ^[raw/articles/rfc8693-token-exchange-selected-sections-2026-09-12.md]

联邦取证边界： a2a-output-attestation-and-delegation-ancestry 将 released bytes、祖先路径与跨 deployer 双边授权分成不同证据。Gateway 的 trace ID/凭据不自动证明父方同意；本地 nonce 去重不自动成为跨 gateway 防重放。若采用双签，应另验公钥准入、在线 co-sign、撤销传播和独立业务状态，而不是只增加一条审计日志。^[raw/articles/a2a-output-attestation-and-delegation-ancestry-2026-09-11.md]

边界反例： [[grafana-mcp-session-identity-and-egress-boundaries

Grafana MCP]] 说明 session 格式不是身份，凭据不外发也不等于出站受限；入站认证、工具授权、凭据绑定、实际目的地需分别验证。[[pillar-docker-socket-sandbox-trust-handoff

Docker daemon 旁路]] 提醒：控制面还要覆盖 agent 能借用的内网/本地代理权限，不只检查直接工具调用。^[raw/articles/grafana-mcp-session-identity-and-egress-boundaries-2026-09-10.md] ^[raw/articles/pillar-docker-socket-sandbox-trust-handoff-2026-09-10.md]

定义

MCP Gateway Runtime 指把远程 MCP 工具调用放到网关层治理的运行时形态：客户端、Agent、工具服务器不再只是一条点对点长会话链路，而是通过网关承载协议版本协商、工具发现、路由、鉴权、限流、计量、Schema 校验、状态隔离和新旧协议桥接。

[[higress-mcp-gateway-api-inference-extension

Higress v2.2.4 的案例]]显示，MCP 2026-07-28 的无状态 HTTP Tools 基线会把远程工具调用从“先 initialize、再依赖 Session ID 续会话”推向“每个请求带齐协议版本、客户端身份和能力”的模式。这样更适合横向扩容：请求可以落到任意后端实例，网关也更容易在解析完整 JSON Body 前基于 Header 做路由、鉴权、限流和计量。

为什么重要

Agent 工程里的工具调用一旦进入生产，问题就不再只是“模型会不会调用工具”，而是：工具服务器能否横向扩容，旧 MCP Server 如何兼容，新客户端如何逐步迁移，工具入参错误是否能在边界被拦截，Cookie / Session / 内部路由 Header 是否会跨服务泄漏。

这使 MCP Gateway 成为 Harness-Engineering 的基础设施层：它把工具使用从 prompt 约束提升到可执行的网络边界和协议边界。对 Hermes 来说，MCP Server、REST 工具、内部管理 API、外部 SaaS 工具都不应裸暴露给长期 Agent loop；更稳的形态是通过 gateway/runtime 统一收口，保留可观测、可限流、可回滚、可审计的轨迹。

关键设计点

无状态请求优先：每次工具调用自带协议版本、客户端身份和能力，减少对协议级 Session 的依赖。
显式桥接路径：modern 到 modern、modern 到 legacy、legacy 到 legacy 应该是显式策略，而不是升级时静默切换。
边界前置校验：Origin、媒体类型、请求大小、JSON-RPC 消息、Header/Body 一致性、输入 Schema 应尽量在网关边界被验证。
状态与凭据隔离：默认隔离 Cookie、Session、Last-Event-ID、内部路由 Header 和无关凭据，避免代理层把一个工具的状态泄漏到另一个工具。
数据面可验证：如果控制面或 Endpoint Picker 选出了目标端点，数据面必须能证明请求实际送到了对应 PodIP:port 或给出真实 served endpoint。

与推理网关的关系

MCP Gateway 处理的是 Agent 工具调用的协议与治理边界；Gateway API Inference Extension 处理的是大模型推理流量如何落到正确模型端点。二者共同说明：AI 基础设施正在从“把 HTTP 请求转发出去”升级为“理解 Agent 工具、模型端点、队列、缓存、LoRA Adapter、数据并行端口和验证回传”的控制面。

这和 Context-Engineering 也有关：工具列表、工具 schema、协议版本、服务能力发现结果，本身就是 Agent 的上下文。它们应当由 runtime 可靠提供，而不是靠提示词里手写一段过期说明。

开放问题

MCP 2026-07-28 的 Resources、Prompts、Tasks、Subscriptions、MCP Apps、完整 OAuth 等能力在生产网关中如何分阶段落地。
Gateway 如何为不同风险等级的工具提供不同策略：只读、需审批、需 sandbox、需审计回放。
Hermes 若接入更多 MCP Server，应该优先把哪些工具放到统一 gateway policy 下，而不是逐个工具靠 prompt 防误用。

写入记录

2026-08-20 19:24 CST：根据阿里云云原生 Higress v2.2.4 文章新增概念页，提炼 MCP Gateway Runtime 对 Agent 工具调用、协议桥接和推理网关治理的意义。

2026-09-01 补充：从 MCP 聚合到 MCP / A2A / REST / gRPC 联邦控制面

[[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]] 补充了 MCP Gateway Runtime 的协议联邦维度：gateway 不只代理 MCP server，也可能把 A2A server、REST/gRPC API、OpenAI/Anthropic agent routing、tools/prompts/resources registry、Admin UI、auth、rate limiting、retry、OTel/Prometheus observability 与 Redis/Kubernetes federation 收到同一个控制面。

这和 [[toolhive-enterprise-mcp-runtime

ToolHive]]、[[gate22-mcp-gateway-control-plane

Gate22]]、[[agentflow-flow-centric-agent-security-policy

AgentFlow]] 形成互补：ToolHive 强调企业 registry/runtime/portal，Gate22 强调 bundle/allow-list，AgentFlow 强调信息流策略，而 ContextForge 强调异构后端联邦与跨 gateway trust。对 Hermes 来说，未来 tool registry 不应只记录“这是 MCP server”，还应记录 backend protocol、identity model、credential boundary、policy surface、trace destination、federation risk 和 tool routing explainability。

ContextForge README 中的 UAID cross-gateway routing 安全要求也应进入 Hermes 的高风险工具接入门槛：跨 gateway 调用必须显式 domain allowlist、JWT trust、AUTH_REQUIRED=true、UAID_FORWARD_AUTH=true，默认 fail-closed，并保留 source gateway / user audit trail。否则联邦 gateway 会把多个系统的 blast radius 合并到一个 agent-facing endpoint。

写入记录

2026-09-01 09:00 CST：补充 IBM ContextForge 对 MCP/A2A/REST/gRPC 联邦控制面、跨 gateway trust、观测 receipt 与 Hermes tool registry 字段的启发。

2026-08-22 补充：从协议网关到组织级工具控制面

[[gate22-mcp-gateway-control-plane

Gate22]] 补充了 MCP Gateway Runtime 的组织治理维度：管理员接入远程 MCP server 后，不是把全部工具直接暴露给 agent，而是定义凭据模式、function-level allow list 和可组合 bundle；开发者得到的是一个统一 MCP endpoint，工具面可被压缩为 search/execute，同时保留审计路线。

这把 [[higress-mcp-gateway-api-inference-extension

Higress v2.2.4]] 所强调的协议/数据面治理推进到团队工作流：MCP gateway 不只是负载均衡或协议桥接，也是权限、凭据、上下文压缩、工具 diff、审计和未来预算控制的控制面。Hermes 若把多个内部 API、文件、GitHub、浏览器、数据库工具接进长期 loop，应优先按风险分 bundle，而不是让每个 cron 都继承全量工具面。

写入记录

2026-08-22 09:30 CST：补充 Gate22 对 MCP Gateway Runtime 的组织级权限、bundle 和审计启发。

2026-08-23 补充：Kubernetes MCP Gateway 的数据面/控制面分离

[[microsoft-mcp-gateway-kubernetes-control-plane Microsoft MCP Gateway]] 提供了一个更偏基础设施的 MCP Gateway Runtime 样本：数据面负责 /adapters/{name}/mcp 与 tool router gateway，控制面负责 adapters/tools 的部署、更新、删除、状态和日志；metadata store 保存 server/tool 定义，session affinity 支持有状态 MCP server。

这说明 MCP Gateway 的生产价值不只是协议桥接，而是把工具注册、生命周期、路由、鉴权、日志和未来 agent/session 管理收口为可审计控制面。与 [[gate22-mcp-gateway-control-plane

Gate22]] 的 bundle/allow-list 视角相比，Microsoft 项目更强调 Kubernetes 下的部署与状态管理；两者合起来覆盖组织权限和运行时生命周期两端。

写入记录

2026-08-23 09:00 CST：补充 Microsoft MCP Gateway 对 Kubernetes MCP 数据面/控制面分离、session-aware routing 和 tool lifecycle 的启发。

2026-08-25 补充：从 MCP gateway 到组织级 control plane

[[deco-studio-mcp-control-plane

deco Studio]] 显示 MCP Gateway Runtime 的更高层形态：不是只聚合 server，而是把 agents、connections、models、Virtual MCPs、SSO/RBAC、encrypted token vault、trace/cost/error observability 和 event bus 统一到组织级 control plane。

这提示 Hermes 的 MCP/runtime 设计应维护 connection registry 和 tool contract：工具属于哪个 workspace/project，凭据如何保存，谁能调用，调用如何计费和审计，schema/权限检查是否由 runtime 自动执行。否则“接入更多 MCP server”会扩大工具面和凭据面，而不是形成可治理 agent platform。

2026-08-26 补充：MCP gateway 需要独立 agent identity 与 approval ledger

[[keidai-mcp-gateway-identity-control-plane

Keidai]] 补充了 MCP Gateway Runtime 的身份与凭据边界：Fuda 颁发短期 agent JWT，Torii 在 MCP 边界解析 backend credentials、执行 group policy、维护 approval gate 和 call trace，Shaiden runtime 在 gated task 上 park/resume。相比只把多个 MCP server 聚合成一个 endpoint，这种设计把“谁在调用、凭据归谁、谁批准、调用证据在哪”拆成可审计的控制面。

这对 Hermes 的启发是：未来接入高风险 MCP/tool 时，不应只扩展工具列表，而应先定义 agent/job identity、credential resolver、approval store、call trace 和 operator edge。否则长期无人 loop 会把权限扩张隐藏在“工具更多、能力更强”的表象下。

写入记录

2026-08-26 09:01 CST：补充 Keidai 对 MCP gateway 身份、凭据、审批、call trace 与 gated task park/resume 的启发。
2026-08-25 09:05 CST：补充 deco Studio 对组织级 MCP control plane、connection registry、RBAC、trace/cost observability 的启发。

2026-08-27 补充：MCP runtime 需要 registry、permission profile 与组织入口

[[toolhive-enterprise-mcp-runtime

ToolHive]] 把 MCP Gateway Runtime 进一步拆成 Gateway、Registry Server、Runtime 和 Portal：Registry 负责可信 server 目录、group 和配置；Runtime 负责本地容器或 Kubernetes 部署与生命周期；Gateway 负责统一 endpoint、SSO/OIDC、authz、tool filtering、semantic tool search 和 audit；Portal 负责组织内发现、请求和管理。

[[onecli-team-agent-harness

OneCLI]] 从 team-agent 角度补充了另一种 gateway：agent 在 sandbox 中运行，outbound request 经过 Rust Gateway 才注入凭据并执行 policy，凭据不直接交给 agent。这对 Hermes 的启发是，MCP/tool 接入不应只维护“可用工具列表”，而应维护 per-job identity、permission profile、credential resolver、approval ledger 和 call trace。

写入记录

2026-08-27 09:00 CST：补充 ToolHive 与 OneCLI 对 MCP registry、runtime、gateway 凭据注入、权限 profile 和组织入口的启发。

2026-08-28 补充：本地权限网关与轨迹级 policy proxy

[[aipermission-local-permission-gateway

AIPermission]] 和 [[gatra-zero-trust-agent-security-proxy

GATRA]] 把 MCP Gateway Runtime 的控制面进一步拆成两种互补形态：AIPermission 偏本地开发者 credential boundary，强调凭据留在 localhost gateway 内，agent 只拿 scoped token、connector/action permission、approval 和 audit；GATRA 偏 data-plane policy proxy，强调 Ed25519 capability token、CEL policy、ephemeral directive、trajectory spending cap 和 dry-run audit。

对 Hermes 来说，这说明未来高风险 MCP/tool 接入不应只维护“工具列表”，而应维护 job identity、credential profile、capability token、monotonic task directive、trajectory budget、policy verdict、approval ledger 和 revoke/expiry。单步 allow list 只能防一部分风险；长期 loop 的真实边界需要跨调用累计和可审计证据。

2026-08-29 补充：MCP/control plane 需要 flow policy 与 authority propagation

[[agentflow-flow-centric-agent-security-policy

AgentFlow]] 把 MCP Gateway Runtime 的治理对象从“请求是否允许”扩展到“数据与授权是否沿 agent trajectory 流向允许的 sink”。它的 flow/path rules、task-scoped capability、controlled release、stateful taint semantics 和 bounded SMT verifier，补上了仅靠 function allow-list 或 per-request token 难以覆盖的组合风险。

这和 [[gatra-zero-trust-agent-security-proxy

GATRA]]、[[aipermission-local-permission-gateway

AIPermission]] 形成互补：AIPermission 保护本地 credential boundary，GATRA 控制 request/capability/budget trajectory，AgentFlow 约束 sensitive fields、release sink 与 delegation boundary。Hermes 若未来接入内部 MCP/API，不应只登记 server 和 action，还应记录 data labels、authority scope、release rule、delegation policy 与 verifier/dry-run audit。

写入记录

2026-08-29 09:01 CST：补充 AgentFlow 对 MCP Gateway Runtime 的 flow-centric policy、stateful taint、authority propagation 和 bounded verifier 启发。

2026-08-30 补充：MCP 治理要先有 inventory 与 security preflight

[[golf-scanner-mcp-server-security-audit

Golf Scanner]] 补充了 MCP Gateway Runtime 的前置层：在建设 gateway、RBAC、approval、budget 和 audit 之前，团队必须先知道开发者机器和 IDE 中实际配置了哪些 MCP server。它把 Claude Code、Cursor、VS Code、Windsurf、Gemini CLI、Kiro、Antigravity 等工具中的 MCP 配置扫描出来，并按命令、凭据、脚本/二进制位置、容器权限、registry、漏洞、GitHub trust、digest/signature、OAuth 等信号做风险评分。

这说明 MCP control plane 不应只从“新 server 如何接入”开始，也要覆盖“已有 server 如何发现、分类、审计和下线”。对 Hermes 来说，未来 tool/MCP registry 应包含配置来源、transport、命令/包/镜像、credential boundary、audit timestamp、risk verdict 和是否允许无人 cron 使用；未审计 server 默认只能 read-only 或 HOLD。

写入记录

2026-08-30 09:00 CST：补充 Golf Scanner 对 MCP inventory、security preflight 与 Hermes tool registry 字段的启发。

2026-09-01 补充：MCP / Agent Runtime / Gateway 主题簇

本页作为 [[MCP-Gateway-Runtime

MCP / Agent Runtime / Gateway]] 主题簇的中心页，和 [[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]]、Context-Engineering、Harness-Engineering、Loop-Engineering、Agent-Benchmarks 共同描述“agent 工具面如何从单个 MCP server 升级为可治理 runtime”。

主题簇的分工是：[[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]] 提供 MCP/A2A/REST/gRPC federation control plane 样本；Context-Engineering 解释工具 registry、schema、权限和 trace 为什么也是上下文；Harness-Engineering 规定工具/权限/验证/审计合同；Loop-Engineering 处理长期 agent 如何跨轮调度、恢复和静默/打断；Agent-Benchmarks 则评估 runtime、gateway、sandbox 与 verifier 是否真的提升可靠性。

写入记录

2026-09-01 21:16 CST：补齐 MCP / Agent Runtime / Gateway 主题簇互链，明确本页在 runtime、context、harness、loop、benchmark 之间的分工。

2026-09-02 补充：本地 MCP gateway 是个人工作台的控制面

[[moor-local-mcp-gateway-manager

Moor]] 补充了 MCP Gateway Runtime 的本地/个人维度：它把多个 MCP server 收敛到一个 localhost endpoint，通过 Profile 决定当前 agent 暴露哪些 server/tool，并从 Claude Code、Codex、OpenCode、Cursor、Kimi Code、dsh、Grok Build、Pi 等客户端扫描既有 MCP 配置。

这和 [[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]] 的企业/联邦控制面形成谱系：ContextForge 解决 MCP/A2A/REST/gRPC 跨后端联邦，Moor 解决开发者机器上多 agent 客户端、多 MCP server、工具面漂移和审计入口。对 Hermes 来说，未来工具治理应同时覆盖本地 profile 和远程 federation：每日 radar、代码任务、发布任务不应共享全量工具面，而应按 job identity / risk tier / profile 暴露最小可用工具，并记录调用 receipt。

写入记录

2026-09-02 09:00 CST：补充 Moor 对本地 MCP gateway、Profile 过滤、跨客户端配置发现和 Hermes tool profile/audit 的启发。

2026-09-02 补充：A2A 是 agent-to-agent federation 维度

A2A-Agent2Agent-Protocol 补充了本主题簇的 agent-to-agent 层：MCP 处理 agent-to-tool / agent-to-resource，A2A 处理 agent-to-agent delegation / collaboration。对 gateway/runtime 来说，治理对象不再只是 tool registry，也包括 Agent Card、Agent Discovery、agent registry、task lifecycle、streaming/push notification、跨 agent trace 与委托权限。

架构边界应按对象判断：稳定函数、数据库、API、资源访问优先 MCP；需要多轮协商、长期状态、artifact、异步通知或自有工具链的远程能力优先 A2A。

写入记录

2026-09-02 21:23 CST：补充 A2A-Agent2Agent-Protocol 与本主题簇的关系，明确 A2A 在 agent-to-agent delegation、Agent Card、Discovery、task lifecycle 和实践案例雷达中的位置。

2026-09-03 补充：A2A Samples 让 gateway registry 扩展到 AgentCard receipt

[[a2a-samples-agent-card-discovery-interoperability

A2A Samples]] 提供了 A2A runtime 的实践样本：CLI host 读取远端 AgentCard；multiagent/web host 动态添加 remote agents 并委托任务；content_creation 和 weather/Airbnb planner 显示跨语言/跨框架 agent 可替换协作；AG2 与 weather sample 显示远端 agent 内部仍可调用 MCP/custom tools。

这要求 MCP-Gateway-Runtime 的 registry schema 从 tool/server 扩展到 agent card：card_url、card_hash、skills、input/output modes、streaming/push、auth scheme、owner、risk tier、last_verified_at、sanitization verdict、trace destination 和 allowed delegation scope 都应成为控制面字段。否则 A2A discovery 会把外部 agent 自述混入上游上下文，形成新的供应链注入与不透明委托风险。

写入记录

2026-09-03 09:00 CST：补充 A2A Samples 对 gateway registry、AgentCard receipt、跨 agent 委托和 A2A+MCP 组合控制面的启发。

2026-09-03 补充：知识点雷达与自我优化入口

AI-Knowledge-Point-Radar 把 MCP Gateway / federation control plane 设为核心雷达轴；LLM-Wiki-Optimization-Log 则要求这类 gateway/runtime 页面在发布前完成索引、CVM 与主题簇互链验证。

写入记录

2026-09-03 21:00 CST：加强与 AI-Knowledge-Point-Radar、LLM-Wiki-Optimization-Log 的 wikilink 串联，统一从知识点价值和机制闭环维护本页。

2026-09-04 补充：policy gateway 把 MCP control plane 推到动作级审批与证据链

[[aegisflow-local-first-policy-gateway AegisFlow]] 补充了 MCP Gateway Runtime 的本地 policy-gateway 形态：它不只聚合 MCP upstream，而是把 MCP、OpenAI-compatible API、Anthropic Messages API、GitHub、shell、SQL、HTTP 等动作归一成 ActionEnvelope，再按 protocol/tool/target/capability/actor/task/session 做 allow、review、block 决策。

这让 gateway 的治理对象从“server/tool 是否可见”升级到“某个 job identity 在某个 task 中能否执行某个具体动作”。对 Hermes 来说，未来工具注册表应同时记录 tool/server、risk tier、default decision、approval receipt schema、credential broker、evidence destination 和 direct-tool-bypass 风险；否则 agent 只要绕过 gateway 直接用 shell/editor，就会让 policy 边界失效。

写入记录

2026-09-04 09:00 CST：补充 AegisFlow 对动作级 policy gateway、review-resume、scoped credential 与 signed evidence chain 的启发。

2026-09-05 补充：MCP trust layer 需要 human identity、consent 与 policy verdict

[[permit-mcp-gateway-enterprise-trust-layer

Permit MCP Gateway]] 补充了 MCP Gateway Runtime 的企业 trust-layer 维度：gateway 不只是代理多个 MCP server，而是在每次 agent action 上绑定 human identity、session-scoped token、fine-grained authorization、consent screen、monitor/govern 与 audit trail。

这和 [[aegisflow-local-first-policy-gateway AegisFlow]] 的动作级 envelope 形成互补：AegisFlow 强调本地 allow/review/block 与 evidence chain，Permit 强调企业 SaaS/MCP 的身份继承、OPA/RBAC/ABAC/ReBAC 与同意界面。对 Hermes 来说，高风险工具注册表应增加 human_identity、job_identity、credential_scope、consent_required、policy_verdict、audit_receipt 和 gateway_bypass_risk 字段。

写入记录

2026-09-05 09:00 CST：补充 Permit MCP Gateway 对 enterprise trust layer、identity/consent/policy/audit 的启发。

2026-09-06 补充：task envelope 是 runtime/gateway 的前置控制合同

[[agentmesh-runtime-gateway-task-envelope-sandboxclaim

AgentMesh Runtime Gateway]] 补充了 MCP Gateway Runtime 的 task-level planning 维度：在 action 进入 MCP/A2A/tool gateway 前，系统先把目标、requested capabilities、context refs、data classification、tenant trust、mutation impact、budget、deadline、idempotency key 和 evidence requirement 放进 versioned task envelope，再决定 agent、runtime placement、approval/deny 和 receipt。

这和 [[aegisflow-local-first-policy-gateway

AegisFlow]] 的 action envelope 形成上下两层：task envelope 决定“这类任务能在哪个隔离等级、拿哪些能力、是否值得继续”；action envelope 决定“某一次具体工具调用是否 allow/review/block”。对 Hermes 来说，高风险工具注册表不应只记录 server/tool，也应绑定 job/task envelope：无人雷达、wiki 写入、CVM 发布、代码修改、生产部署分别需要不同 capability set、可写路径、runtime profile、budget 和 evidence boundary。

写入记录

2026-09-06 09:00 CST：补充 AgentMesh 对 task envelope、runtime placement、SandboxClaim、OTel receipt 与 task/action 双层控制面的启发。

2026-09-07 补充：registry-to-runtime bridge 是 gateway 控制面的前置层

[[dsh-nacos-bridge-registry-to-harness-runtime

dsh-nacos-bridge]] 提醒 MCP/A2A gateway 之前还有一个 registry-to-runtime bridge 层：能力提供方把 MCP server 或 A2A Agent Card 注册到 Nacos，bridge 负责发现、diff、mount/unmount 和健康检查，harness runtime 再决定模型、memory、session、skills 如何使用这些能力。

这与 [[agentmesh-runtime-gateway-task-envelope-sandboxclaim

AgentMesh Runtime Gateway]] 的 task envelope 形成上下游关系：registry bridge 维护“有哪些能力可用”，task planner 决定“本任务可用哪些能力”，action gateway 决定“这次调用是否允许”。Hermes 的 tool registry 后续应增加 capability snapshot、schema/card hash、last_seen、health、mount status 与 stale rejection 字段。

写入记录

2026-09-07 09:00 CST：补充 dsh-nacos-bridge 对 MCP/A2A registry-to-runtime bridge、动态能力装配和 capability snapshot 的启发。

2026-09-08 补充：AI asset control plane 把 registry、credential、A2A proxy 与 observability 绑成 receipt

[[agentic-community-mcp-gateway-registry-ai-asset-control-plane

MCP Gateway & Registry]] 把 MCP servers、A2A agents、skills 和 custom entities 都登记为 AI assets，并用同一套 registry/gateway/auth/audit 模型治理。它补充了本页对 federation control plane 的一个关键要求：control plane 不只记录 server endpoint，还要记录 asset type、schema/card、owner、scope、credential boundary、scan verdict、audit sink、OTel metrics、rate-limit/quarantine 与 federation source trust。

尤其值得吸收的是 A2A reverse-proxy 与 per-user egress credential 两个边界：前者让 Agent Card 与 JSON-RPC call 可以选择进入 gateway 数据面并用 invoke_agent gate 控制，后者让第三方 SaaS MCP token 保存在 vault，由 gateway 按目的地注入，coding assistant 只持有 ingress token。对 Hermes 来说，下一版 tool/agent registry 应从“有哪些工具”升级为“每个 job identity 能发现、调用、下线哪些 AI assets，并留下什么 receipt”。

写入记录

2026-09-08 09:01 CST：补充 MCP Gateway & Registry 对 AI asset control plane、A2A reverse-proxy、per-user egress credential、registration gate、audit/OTel 与 quarantine 的启发。

2026-09-09 补充：MCP tool 不应只注册，也要被选择、评测和拦截

[[osworld-mcp-tool-invocation-computer-use-benchmark

OSWorld-MCP]] 把 MCP tool surface 放进 computer-use benchmark，说明 gateway/registry 的价值不止“暴露 158 个工具”，还要让 agent 在 GUI action 与 MCP call 之间做 route choice，并记录 tool-beneficial task、distractor、Tool Invocation Rate、step/cost 和 fallback。工具面越大，越需要按任务生成最小可见工具集，否则 tool schema 会变成上下文噪音和误用入口。

[[agenttrust-runtime-safety-interception

AgentTrust]] 从安全侧补上 action-time membrane：即使 MCP tool 已被注册和授权，每次具体动作仍要经过 normalized action、risk category、policy verdict、safe fix、RiskChain 与 fail-safe review。[[a2a-v1-protocol-binding-governance

A2A v1]] 则提醒同一 registry 还要为 agent assets 记录 supportedInterfaces、protocolVersion、transport binding 与兼容层。因此下一版 MCP/A2A control plane receipt 应同时覆盖：asset discovery、tool-route decision、action interception、protocol-binding compatibility 和 audit/trace。

写入记录

2026-09-09 09:01 CST：补充 OSWorld-MCP、AgentTrust、A2A v1 对 MCP tool-route、action-time safety membrane 与 protocol-binding receipt 的启发。
2026-09-10 09:11 CST：新增 Grafana 身份/出站分离与 Docker daemon 隐式权限反例入口；不再长篇重复追加来源摘要。
2026-09-11 09:09 CST：补充跨 deployer 输出绑定、双边授权与跨 verifier replay 边界入口；未部署网关或修改权限策略。
2026-09-12 09:17 CST：增加 persona×credential、User→SA entitlement 与 RFC 对照入口；明确 ROPC 冲突和 actor-history/撤销边界。