MCP Registry 治理：发现、来源与安全安装

核心结论

MCP Registry 解决的是发现问题，不会自动解决信任、授权、Package 安全、Tenant、计费或运营问题。

Registry 条目
      |
      v
审核来源 + 固定 Artifact 或 Endpoint
      |
      v
隔离安装 + Runtime Policy
      |
      v
已认证 Tool 调用 + 对象授权

“官方”不是安全属性。每次安装都应记录 Registry 实现、Schema 版本、来源 URL、Artifact Digest 或 Endpoint Owner、审核结论，以及将元数据转化为安装的 Runtime Policy。

Registry、Catalog 与 Package Repository

这些词代表不同层次：

官方 MCP Registry 仓库和服务可能独立于 Client Marketplace 与私有 Catalog 演进。不要把每个 GitHub 列表、Marketplace 或 Package Index 都称为“GitHub MCP Registry”。

Manifest 应描述什么

使用目标 Registry 要求的准确 Schema。概念性 Manifest 可以包含：

{
  "name": "com.example/invoice-summary",
  "version": "1.4.0",
  "description": "Return an approved, read-only invoice summary.",
  "repository": {
    "url": "https://github.com/example/invoice-summary",
    "revision": "pinned-revision"
  },
  "artifacts": [
    {
      "type": "package",
      "registry": "package-registry",
      "identifier": "example-invoice-summary",
      "version": "1.4.0",
      "digest": "sha256:pinned-digest"
    }
  ],
  "transports": ["stdio"],
  "declared_side_effects": "read_only",
  "required_scopes": ["invoices.read"],
  "data_classes": ["tenant_invoice_metadata"]
}

这只是说明，不是通用 server.json。不同 Registry 可能使用不同字段、Package Record、Remote Record 或版本规则。应对目标 Schema 做校验，并把 Runtime Policy 保留在描述性 Metadata 之外。

Manifest 不应放 Secret。可以记录环境变量名称，但值、Token、Database URL 和 Private Key 必须放在 Secret Manager。

发现不是授权

搜索和语义匹配可以帮助 Host 提出能力建议，但应用仍需决定：

• Publisher 和 Artifact 是否获批；
• 哪个 Tenant 和 Principal 可以使用；
• 暴露哪些 Tools 和 Resources；
• 哪些数据可以离开边界；
• 外部副作用是否需要确认；
• 配额、成本和留存如何执行。

模型选择的 Registry 结果必须按不可信输入处理，不能据此选择 Owner、Role、Price、Credential 或 Destination。

来源审核

安装前应在审核记录中收集证据：

Namespace 或 Domain 验证可以证明控制权，是有用证据，但不是安全背书。

发布流程

可靠的发布流程应明确实现相关步骤：

1. 从固定 Release 生成 Metadata；
2. 按目标 Registry Schema 校验；
3. 验证 Source、Artifact、Endpoint 和 Namespace 所有权；
4. 执行依赖、Secret、License 和 Malware 检查；
5. 在 Sandbox 和代表性 Fixture 中测试 Tool Contract；
6. 记录 Capability、副作用、数据类别和 Required Scope；
7. 通过短期 CI 身份发布；
8. 保存审核记录和回滚引用。

不要声称通用的 mcp-publisher 命令、GitHub OAuth、DNS 证明或 OIDC 流程适用于所有 Registry。应使用目标 Registry 的当前文档并固定 CLI 版本。

Runtime 安装边界

安装 Server 可能授予文件、网络、凭证或外部 API 访问权，应按部署代码治理：

• 要求 Allowlist 或审批策略；
• 固定 Package 版本和 Digest；
• 使用专用 OS 身份运行本地进程；
• 隔离文件系统和网络；
• 只注入最小 Secret；
• 禁止环境继承中的 Ambient Credential 和宽泛权限；
• 记录有界且脱敏的审计事件；
• 执行 Staging、Canary、Rollback 和 Revoke；
• 卸载时删除 Artifact、Cache、Credential 和派生记录。

Agent 可以请求安装，但 Deployment Controller 或人工审批必须授权。

安全模型

采用纵深防御，同时将控制分配到正确层次：

不要把 Badge、Trust Score、Annotation 或自动扫描描述成授权。

企业私有 Catalog

私有 Catalog 可以包含审核过的内部 Server、镜像的公共条目或两者。应作为 Policy Service 设计：

• 将公共发现与内部审批分开；
• 要求 Tenant 和 Environment 标签；
• Allowlist Artifact 来源和域名；
• 保存来源、审核 Owner、过期时间和例外原因；
• 支持分阶段发布和紧急撤销；
• 防止公共条目静默替换内部 Artifact；
• 将 Secret 和 Runtime Policy 排除在 Catalog Metadata 之外；
• 同步删除和 Legal Hold 决策；
• 审计安装、升级、使用和移除。

API 兼容的索引不一定兼容每个 Client。应使用准确 Client 和 SDK 测试认证、Pagination、Version Selection、Transport Record 和 Error Semantics。

安全搜索与排序

排序应优先证据，而不是只看热度：

• Publisher 控制权已验证；
• 最近审核过的 Release；
• 可复现 Artifact 或 Source 关联；
• 已声明数据和副作用；
• 测试覆盖与兼容性证据；
• 漏洞和事件状态；
• 支持和弃用策略。

不要因为模型猜测相关、下载量更多或暴露 Tool 更多，就提高 Server 排名。能力越多，审核和爆炸半径成本越高。

撤销、升级与删除

发布前就规划生命周期：

不可变 Release 仍可以被撤销。不可变只防止静默修改，不会让有漏洞的版本变安全。

暴露前测试

Registry Metadata
  -> Schema 与来源测试
  -> Artifact 与依赖测试
  -> Sandbox Tool Contract 测试
  -> 身份、Tenant、对象与外发测试
  -> Canary 与 Rollback

至少测试：

• Manifest 畸形字段和未知字段；
• Package 与 Digest 不匹配；
• Namespace 或 Source 所有权不匹配；
• Credential 过期和错误 Token Resource；
• 跨 Tenant 对象访问；
• 恶意描述、Prompt、Resource 和 Tool Result；
• 超大输出和 Pagination；
• Cancellation、Timeout、Retry 和重复副作用；
• Package 升级和回滚；
• Registry 故障和过期 Metadata；
• 移除和删除传播。

实践清单

• [ ] 记录准确的 Registry、实现、Schema 版本和 Client。
• [ ] 分离 Registry、Catalog、Package、Source、Endpoint 和 Runtime 职责。
• [ ] 记录 Publisher、Source、Artifact Digest、Dependencies、Capabilities、Data 和 Egress。
• [ ] 将 Metadata、Annotation、Rating 和 Scan Result 视为证据，而非授权。
• [ ] 安装前要求审批，Agent 选择只作为建议。
• [ ] 隔离进程、凭证、文件系统和网络。
• [ ] 在 Runtime 执行 Principal、Tenant、对象、Purpose、Quota 和副作用策略。
• [ ] 测试升级、撤销、回滚、故障、重复投递和删除。
• [ ] 保存审核 Owner、过期日期、例外记录和事件联系人。

总结

MCP Registry 可以让能力更容易被发现，但发现只是第一步。可信路径应是：验证来源，固定 Artifact 或 Endpoint，审核声明的 Contract，以最小权限安装，在 Server 执行授权，并让回滚与删除真正可用。目录条目或热度信号不应替代安全决策。

一手来源

• Model Context Protocol Registry 仓库
• Model Context Protocol Specification
• Model Context Protocol Tools
• Model Context Protocol Authorization
• SLSA：Software Supply-chain Levels for Software Artifacts