MCP 工具也有供应链风险：注册中心、签名校验、版本锁定与白名单

MCP 把模型连接文件、数据库、浏览器和业务系统的方式标准化了。对开发者来说，这意味着一个客户端可以快速发现并接入许多工具；对攻击者来说，这也意味着只要一个工具进入可信执行链，就可能同时获得进程权限、网络权限、令牌和模型传来的业务参数。风险并不只发生在工具执行时，还可能出现在搜索、下载、解析依赖、自动升级和配置分发的每一个环节。

最危险的误解是"能在注册中心搜到，就等于经过安全认证"。注册中心解决的首先是发现和元数据分发，命名空间验证能减少冒名发布，却不能替使用方审计服务器源码、依赖树、构建过程和运行权限。一个发布者可以真实拥有自己的命名空间，但其新版本仍可能误传密钥、扩大文件访问范围，甚至在账号被接管后发布恶意制品。

这篇文章不讨论如何绕过平台防护，也不会把"永远不安装第三方工具"当答案。我们要做的是建立一条能在团队里执行的最小治理链：从注册中心取得候选元数据，依据稳定身份和版本形成审批记录，下载后核对摘要或签名，只允许经过批准的启动方式和权限集合，升级时重新评估差异，并为撤回保留明确的停止路径。

1. 先画出真正的供应链

一次看似简单的"安装 MCP Server"，至少涉及六个主体：工具作者、源码托管平台、构建流水线、包或镜像仓库、MCP 注册中心、最终运行工具的客户端。它们保存的不是同一种东西。源码仓库保存可审查的源文件，包仓库存放实际被安装的制品，注册中心主要分发服务器描述及安装信息，客户端最终决定用哪个命令、哪个版本和哪些环境变量启动。
#mermaid-svg-ymEdW020VZEB4lZI{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-ymEdW020VZEB4lZI .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-ymEdW020VZEB4lZI .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-ymEdW020VZEB4lZI .error-icon{fill:#552222;}#mermaid-svg-ymEdW020VZEB4lZI .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-ymEdW020VZEB4lZI .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-ymEdW020VZEB4lZI .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-ymEdW020VZEB4lZI .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-ymEdW020VZEB4lZI .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-ymEdW020VZEB4lZI .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-ymEdW020VZEB4lZI .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-ymEdW020VZEB4lZI .marker{fill:#333333;stroke:#333333;}#mermaid-svg-ymEdW020VZEB4lZI .marker.cross{stroke:#333333;}#mermaid-svg-ymEdW020VZEB4lZI svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-ymEdW020VZEB4lZI p{margin:0;}#mermaid-svg-ymEdW020VZEB4lZI .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-ymEdW020VZEB4lZI .cluster-label text{fill:#333;}#mermaid-svg-ymEdW020VZEB4lZI .cluster-label span{color:#333;}#mermaid-svg-ymEdW020VZEB4lZI .cluster-label span p{background-color:transparent;}#mermaid-svg-ymEdW020VZEB4lZI .label text,#mermaid-svg-ymEdW020VZEB4lZI span{fill:#333;color:#333;}#mermaid-svg-ymEdW020VZEB4lZI .node rect,#mermaid-svg-ymEdW020VZEB4lZI .node circle,#mermaid-svg-ymEdW020VZEB4lZI .node ellipse,#mermaid-svg-ymEdW020VZEB4lZI .node polygon,#mermaid-svg-ymEdW020VZEB4lZI .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-ymEdW020VZEB4lZI .rough-node .label text,#mermaid-svg-ymEdW020VZEB4lZI .node .label text,#mermaid-svg-ymEdW020VZEB4lZI .image-shape .label,#mermaid-svg-ymEdW020VZEB4lZI .icon-shape .label{text-anchor:middle;}#mermaid-svg-ymEdW020VZEB4lZI .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-ymEdW020VZEB4lZI .rough-node .label,#mermaid-svg-ymEdW020VZEB4lZI .node .label,#mermaid-svg-ymEdW020VZEB4lZI .image-shape .label,#mermaid-svg-ymEdW020VZEB4lZI .icon-shape .label{text-align:center;}#mermaid-svg-ymEdW020VZEB4lZI .node.clickable{cursor:pointer;}#mermaid-svg-ymEdW020VZEB4lZI .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-ymEdW020VZEB4lZI .arrowheadPath{fill:#333333;}#mermaid-svg-ymEdW020VZEB4lZI .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-ymEdW020VZEB4lZI .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-ymEdW020VZEB4lZI .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ymEdW020VZEB4lZI .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-ymEdW020VZEB4lZI .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ymEdW020VZEB4lZI .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-ymEdW020VZEB4lZI .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-ymEdW020VZEB4lZI .cluster text{fill:#333;}#mermaid-svg-ymEdW020VZEB4lZI .cluster span{color:#333;}#mermaid-svg-ymEdW020VZEB4lZI div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-ymEdW020VZEB4lZI .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-ymEdW020VZEB4lZI rect.text{fill:none;stroke-width:0;}#mermaid-svg-ymEdW020VZEB4lZI .icon-shape,#mermaid-svg-ymEdW020VZEB4lZI .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ymEdW020VZEB4lZI .icon-shape p,#mermaid-svg-ymEdW020VZEB4lZI .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-ymEdW020VZEB4lZI .icon-shape .label rect,#mermaid-svg-ymEdW020VZEB4lZI .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ymEdW020VZEB4lZI .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-ymEdW020VZEB4lZI .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-ymEdW020VZEB4lZI :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 工具作者与源码仓库
构建流水线
包仓库或镜像仓库
MCP 注册中心元数据
下载与摘要校验
候选发现
身份与策略审批
受限安装区
权限受控的 MCP 进程
审计与撤回
版本升级

如果只检查注册中心页面，真实执行的制品可能已经在另一个环节被替换；如果只检查源码仓库，构建产物也未必来自所看的提交；如果只锁定包名而没有版本，下一次安装可能拿到完全不同的代码。供应链治理的关键不是再找一个"绝对可信"的图标，而是把身份、内容和运行权限分别固定，再把它们连接成一条可追溯记录。

这条链上还存在两个容易忽略的输入。第一是安装配置，它可能包含远程 URL、包参数和环境变量名；第二是服务器向客户端动态暴露的工具描述。即使二进制没有变化，配置或工具能力变化也会改变风险。因此审批对象不能只有一个包名，还应包含版本、摘要、来源、启动方式、可见工具、所需权限和审批时间。

2. 威胁模型：先回答工具能碰到什么

不同 MCP Server 的风险等级完全不同。只读取公开天气数据的远程服务，与能执行终端命令、读写工作区或查询生产数据库的本地服务，不应共用同一套默认策略。评估时先列出资产，再讨论攻击路径。资产通常包括本机文件、浏览器会话、云服务令牌、数据库凭据、内部文档、模型上下文以及工具执行产生的结果。

常见风险可以分成五类。第一类是身份混淆，例如名称相似、仓库迁移后被重新占用、搜索结果把非官方实现排在前面。第二类是制品替换，例如相同版本标签指向了不同内容、下载站被篡改、镜像标签漂移。第三类是依赖污染，顶层项目没有恶意代码，但间接依赖的新版本带来问题。第四类是权限扩张，更新后开始读取更多目录或新增高风险工具。第五类是运行时诱导，不可信文档或网页内容通过提示注入，试图让模型调用本来不该调用的工具。

还要区分"发布者真实"和"软件安全"。命名空间验证只能回答某个发布动作是否由被认可的账号或域名控制者完成，不能证明代码没有漏洞。签名能证明制品来自某把私钥且内容未改变，也不能证明签名者值得信任。白名单能限制允许运行的对象，却无法代替最小权限。每个机制只回答一个问题，叠加后才能形成纵深防御。

3. 注册中心适合发现，不适合替你下结论

官方 MCP Registry 提供版本化服务器元数据和公开读取接口，发布侧通过 GitHub 身份或域名所有权等方式约束命名空间。这个设计很重要，因为稳定命名空间能显著降低随意冒名。但使用方仍应把注册结果当作"候选清单"，而不是直接生成可执行配置。

消费注册中心数据时至少保存以下字段：规范化服务器名、明确版本、源码仓库 URL 与稳定仓库标识、包或镜像坐标、注册记录状态、抓取时间、原始响应摘要。稳定仓库标识比仓库名称更可靠，因为名称可以修改，仓库删除后也可能出现同名的新仓库。若注册元数据缺少源码来源或制品定位信息，应进入人工评审，而不是自动补全一个看起来合理的地址。

状态同样重要。服务可能处于 active、deprecated 或 deleted。定期同步时不能只拉"最新可见列表"，否则已经批准的服务器被撤下后，本地系统可能完全不知道。更稳妥的做法是保留最后一次可信快照，并处理删除和弃用事件：停止新安装、标记现有实例、通知负责人，最后依据业务影响决定隔离或下线。

注册中心搜索也不应直接驱动自动安装。关键词匹配容易受到命名和描述影响，搜索排序不是信任排序。客户端可以展示候选项，但高权限工具必须由明确的管理员动作进入批准清单。个人开发环境也最好保留一份机器可读策略文件，这比"我记得这个包是官方的"可靠得多。

4. 用一份小而明确的批准清单固定身份

白名单不是只写几个包名。一个可执行的批准条目至少需要固定来源、版本、摘要、启动入口和权限。下面使用 JSON，是因为 Python 标准库可以直接解析，也方便代码评审。真实团队可把文件放在受保护的配置仓库中，由代码所有者审批；不要允许普通运行进程自行修改它。

{
  "schema_version": 1,
  "servers": {
    "io.example/readonly-docs": {
      "version": "1.4.2",
      "artifact": "readonly_docs-1.4.2-py3-none-any.whl",
      "sha256": "替换为审批时记录的64位十六进制摘要",
      "source_repository": "https://github.com/example/readonly-docs",
      "repository_id": "123456789",
      "command": ["python", "-m", "readonly_docs"],
      "allowed_tools": ["search_docs", "read_doc"],
      "allowed_roots": ["D:/knowledge/public"],
      "network": "deny",
      "approved_by": "security-team",
      "approved_at": "2026-09-21"
    }
  }
}

这里故意没有"自动接受同一主版本的最新小版本"。语义化版本表达的是作者承诺，不是安全边界；补丁版本同样可以新增依赖、改变安装脚本或扩大网络行为。需要频繁升级时，可以让自动化生成差异报告，但最终批准仍应落到一个不可歧义的具体版本和内容摘要。

allowed_tools 也不能省。MCP Server 升级后可能出现新工具，若客户端默认全部暴露给模型，工具能力会在没有审批的情况下扩大。更安全的行为是取服务器实际工具集合与批准集合的交集，并对新增项报警。这样新功能不会偷偷进入生产，但已批准能力仍可继续运行。

5. 摘要校验：确认下载内容没有变化

SHA-256 不能判断软件是否善良，但能回答"当前文件是否与审批时看到的文件完全一致"。审批者先从可信渠道取得制品，完成源码、依赖和行为审查后记录摘要；部署端下载后再次计算并比较。不要从下载文件所在的同一未验证页面同时获取制品和摘要，否则两者可能一起被替换。

下面的脚本只使用 Python 标准库。它拒绝软链接、检查文件名、限制文件大小并用恒定时间比较摘要。运行方式是 python verify_artifact.py policy.json io.example/readonly-docs dist/文件名.whl。校验通过只代表内容匹配，后续仍需在隔离环境安装和启动。

# verify_artifact.py
from __future__ import annotations

import hashlib
import hmac
import json
import sys
from pathlib import Path

MAX_ARTIFACT_BYTES = 500 * 1024 * 1024


def sha256_file(path: Path) -> str:
    digest = hashlib.sha256()
    with path.open("rb") as stream:
        for block in iter(lambda: stream.read(1024 * 1024), b""):
            digest.update(block)
    return digest.hexdigest()


def verify(policy_path: Path, server_name: str, artifact_path: Path) -> None:
    policy = json.loads(policy_path.read_text(encoding="utf-8"))
    entry = policy["servers"].get(server_name)
    if entry is None:
        raise PermissionError(f"服务器未获批准：{server_name}")
    if artifact_path.is_symlink() or not artifact_path.is_file():
        raise ValueError("制品必须是普通文件，不能是符号链接")
    if artifact_path.name != entry["artifact"]:
        raise ValueError("制品文件名与批准记录不一致")
    if artifact_path.stat().st_size > MAX_ARTIFACT_BYTES:
        raise ValueError("制品超过本地安全上限")
    expected = entry["sha256"].lower()
    if len(expected) != 64 or any(c not in "0123456789abcdef" for c in expected):
        raise ValueError("策略中的 SHA-256 格式错误")
    actual = sha256_file(artifact_path)
    if not hmac.compare_digest(actual, expected):
        raise PermissionError(f"摘要不匹配：expected={expected}, actual={actual}")
    print(f"校验通过：{server_name}@{entry['version']} {actual}")


if __name__ == "__main__":
    if len(sys.argv) != 4:
        raise SystemExit("用法：python verify_artifact.py policy.json SERVER ARTIFACT")
    verify(Path(sys.argv[1]), sys.argv[2], Path(sys.argv[3]).resolve(strict=True))

这个脚本不负责下载，故意把网络获取和本地校验分开。部署系统应该先把文件放入不可执行的暂存目录，校验通过后再移动到按摘要命名的只读缓存。以摘要作为缓存键，可以避免同名文件覆盖；旧版本在回滚窗口内保留，但不能继续从"latest"标签重新拉取。

6. 签名校验：证明谁对这份内容负责

摘要需要一个可信分发渠道。数字签名把"内容摘要"与发布者私钥关联起来，验证方持有经过审批的公钥，就能确认内容没有变化并且签名来自对应私钥。这里仍有一个根本问题：公钥第一次如何进入信任库。最稳妥的是通过组织配置仓库、设备管理系统或线下核验完成信任锚分发，而不是从制品旁边临时下载公钥。

下面示例用 cryptography 验证 Ed25519 分离签名。它适合说明最小流程：批准者保存公钥指纹，部署端读取公钥和签名，对制品原始字节验证。真实制品很大时可对已定义格式的摘要声明签名，但声明必须绑定算法、服务器名、版本和摘要，避免同一个签名被挪用到别的上下文。

# verify_signature.py
from __future__ import annotations

import base64
import hashlib
import sys
from pathlib import Path

from cryptography.exceptions import InvalidSignature
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey


def fingerprint(public_key_pem: bytes) -> str:
    key = serialization.load_pem_public_key(public_key_pem)
    if not isinstance(key, Ed25519PublicKey):
        raise TypeError("只接受 Ed25519 公钥")
    raw = key.public_bytes(
        encoding=serialization.Encoding.Raw,
        format=serialization.PublicFormat.Raw,
    )
    return hashlib.sha256(raw).hexdigest()


def verify(artifact: Path, signature_file: Path, public_key_file: Path,
           approved_fingerprint: str) -> None:
    public_key_pem = public_key_file.read_bytes()
    actual_fingerprint = fingerprint(public_key_pem)
    if actual_fingerprint != approved_fingerprint.lower():
        raise PermissionError("公钥指纹不在批准记录中")
    key = serialization.load_pem_public_key(public_key_pem)
    signature = base64.b64decode(signature_file.read_text(encoding="ascii"), validate=True)
    try:
        key.verify(signature, artifact.read_bytes())
    except InvalidSignature as exc:
        raise PermissionError("制品签名无效") from exc
    print(f"签名有效，公钥指纹：{actual_fingerprint}")


if __name__ == "__main__":
    if len(sys.argv) != 5:
        raise SystemExit("用法：python verify_signature.py ARTIFACT SIGNATURE PUBLIC_KEY FINGERPRINT")
    verify(Path(sys.argv[1]), Path(sys.argv[2]), Path(sys.argv[3]), sys.argv[4])

示例读取整个文件是为了保持代码直观，适合小型包；超大镜像应使用成熟的镜像签名和透明日志工具，而不是自己发明签名格式。更不能把私钥放进仓库或构建镜像。私钥应由专门的密钥服务或受保护的 CI 身份使用，并有轮换、吊销与审计机制。

签名验证失败时不要提供"临时跳过"按钮。应保留失败文件的隔离副本和来源信息，通知维护者重新发布。公钥轮换也不能直接接受服务器声明的新公钥，应由旧信任链签署、组织管理员批准，或通过独立渠道重新核验。

7. 版本锁定不只是把 latest 换成数字

版本锁定至少有三层。第一层锁定 MCP 注册记录版本；第二层锁定真实包或镜像版本；第三层锁定完整依赖解析结果和制品摘要。仅在启动命令中写 package==1.4.2，若安装器仍会动态解析未锁定的间接依赖，最终环境依然可能变化。容器的 1.4.2 标签也可能被重推，应该进一步固定镜像 digest。

Python 生态可以使用带哈希的锁文件，并在干净虚拟环境中从批准源安装；Node.js 应提交锁文件并使用不会重写锁的安装模式；容器则记录 name@sha256:...。关键不是选择哪一种工具，而是让同一批准记录在不同时间和机器上解析出相同字节。如果做不到可重复，就无法证明测试过的东西就是上线的东西。

升级流程也要显式化。先同步候选版本，比较注册元数据、源码提交、依赖锁、工具列表、权限声明和制品摘要；在隔离环境执行功能与安全测试；生成新的批准记录；最后分批替换。旧版仅在确定没有已知高危问题且仍处于回滚窗口时保留。发现制品被撤回或签名密钥泄露时，不应回滚到同一信任链上的另一个未知版本，而要直接隔离并重新评估。

8. 安装完成后，仍要限制启动边界

供应链校验解决的是"运行哪一份代码"，最小权限解决的是"这份代码能造成多大影响"。本地 MCP Server 本质上是普通进程，继承启动用户可访问的文件、环境变量和网络。不要把客户端的整个环境原样传给子进程，更不要因为安装方便就使用管理员账号运行。

启动器应从策略文件构造一个最小环境，只传入服务器明确需要的非敏感配置。敏感令牌由短期凭证服务按需下发，并限制受众、范围和有效期。文件访问根目录使用操作系统权限或容器挂载约束；网络默认拒绝，只允许必须的目标；数据库账户使用只读角色并限制可见对象。进程超时、内存和并发也应有限额，防止异常工具拖垮客户端。

下面的最小启动器展示三个原则：命令必须与批准记录完全一致；环境变量从空白最小集合构造；服务名不存在时直接拒绝。操作系统级沙箱仍需由容器、受限账户或平台策略提供，不能靠 Python 的 subprocess 参数模拟。

# launch_approved.py
from __future__ import annotations

import json
import os
import subprocess
import sys
from pathlib import Path


def launch(policy_path: Path, server_name: str) -> int:
    policy = json.loads(policy_path.read_text(encoding="utf-8"))
    entry = policy["servers"].get(server_name)
    if entry is None:
        raise PermissionError(f"未批准的服务器：{server_name}")
    command = entry.get("command")
    if not isinstance(command, list) or not command or not all(isinstance(x, str) for x in command):
        raise ValueError("批准命令格式错误")
    safe_env = {
        "PATH": os.environ.get("PATH", ""),
        "PYTHONUTF8": "1",
        "MCP_ALLOWED_ROOTS": os.pathsep.join(entry.get("allowed_roots", [])),
    }
    completed = subprocess.run(
        command,
        env=safe_env,
        cwd=Path(__file__).resolve().parent,
        stdin=subprocess.DEVNULL,
        timeout=60,
        check=False,
    )
    return completed.returncode


if __name__ == "__main__":
    if len(sys.argv) != 3:
        raise SystemExit("用法：python launch_approved.py policy.json SERVER")
    raise SystemExit(launch(Path(sys.argv[1]), sys.argv[2]))

不要把允许目录只作为环境变量后就宣称实现了隔离；服务器代码完全可以忽略它。真正的强制边界必须来自操作系统 ACL、容器只读挂载、网络策略或数据库授权。环境变量只是在可信实现中的配置，而不是安全沙箱。

9. 工具描述也要做差异审批

客户端通常在连接后调用 tools/list 获取工具名称、说明和输入 Schema。模型正是依据这些描述决定何时调用工具。因此工具描述既是功能接口，也是模型行为的一部分。新版本即使没有新增二进制权限，只要把描述改成"遇到任何问题都应优先调用"，就可能显著增加调用频率和数据外传范围。

建议每次批准时保存规范化后的工具清单：工具名、描述摘要、输入字段、必填项以及输出内容类别。启动后将实际清单与批准快照比较。缺少已批准工具可视为兼容性故障；出现新增工具、字段从可选变必填、参数语义改变，应阻止自动暴露并要求复审。

Schema 校验只能检查结构，不能证明业务参数安全。文件路径要在客户端解析为绝对路径后确认位于允许根目录；URL 要限制协议和目标域，阻断本地地址与云元数据地址；数据库查询要由只读连接和语句级策略共同保护；所有有外部副作用的工具应在界面展示关键参数并要求用户确认。模型输出永远不能替代授权判断。

10. 不可信内容与 MCP 工具调用要分层

网页、邮件、PDF 和搜索结果都可能包含对模型的诱导文字。MCP 协议不会自动把这些内容变安全。正确的边界是：内容层只提供事实候选，策略层独立判断当前用户、当前会话是否允许调用某工具，执行层再次验证具体参数。即使模型声称"文档要求上传整个目录"，策略层也应因为目标不在许可范围而拒绝。

高风险工具不要仅依赖自然语言提示词。例如发送邮件、删除文件、修改工单、运行代码和访问生产数据，应使用确定性规则校验身份、资源范围和操作类型。可以让模型建议动作，但不能让模型自行扩大权限。对读操作也要注意批量外泄：单次读取一个文件看似低风险，循环调用可能汇总整个目录，因此还需要速率、数量和总字节上限。

工具返回值同样是不可信输入。客户端展示时需要转义，模型再次使用时要标明这是数据而不是系统指令。服务器报错不应泄露环境变量、绝对路径、访问令牌和完整堆栈；详细诊断写入受控日志，对用户只返回必要信息。

11. 如何验证这套策略真的生效

验收不能只跑一次正常安装。至少准备四组测试。第一组是完整性：修改制品任意一个字节，摘要和签名校验必须失败。第二组是身份：替换为另一把公钥，即使签名本身有效，也必须因为指纹不在批准记录中失败。第三组是版本：注册中心出现新版本或同名不同仓库时，系统只应产生候选告警，不能自动替换运行版本。第四组是能力：服务器新增一个工具或请求未批准目录时，客户端必须隐藏或拒绝。

再做故障演练：注册中心暂时不可用时，已批准版本能否依据本地策略继续受控运行；制品仓库返回错误页面时，文件类型、大小和摘要检查能否拦截；批准文件损坏时系统是否选择失败关闭；签名密钥撤销后如何定位所有受影响实例；工具进程超时后能否被终止且不留下孤儿进程。

验证结果应绑定策略版本和环境版本，保留通过与失败的证据。不要只保存"测试通过"四个字。记录被测试的服务器名、版本、摘要、工具清单摘要、权限集合、测试时间和执行者。这样出现问题时能回答哪些实例使用了受影响制品，而不是全网逐台猜测。

12. 审计日志要记录决定，不要复制秘密

建议记录五类事件：发现候选、批准或拒绝、安装校验、进程启动、工具调用。每条日志包含时间、主体、服务器稳定身份、版本与摘要、策略版本、结果和原因码。工具调用记录工具名、参数的脱敏摘要、目标资源类别、是否经过用户确认、耗时和结果状态；不要默认保存文档全文、数据库结果和令牌。

策略拒绝应有稳定原因码，例如 SERVER_NOT_APPROVED、ARTIFACT_HASH_MISMATCH、TOOL_NOT_ALLOWED、PATH_OUTSIDE_ROOT。稳定原因码方便监控和统计，也避免把内部路径拼进面向用户的错误消息。对重复摘要失败、短时间大量拒绝和已撤回版本启动，应设置告警。

审计系统自身也需要访问控制和保留策略。日志可以证明发生过什么，却也可能集中包含敏感元数据。仅授权安全和运维人员查询，按业务需要设定保留时间，并确保工具进程不能修改自己的审计记录。

13. 典型失败模式与修正方法

第一种失败是只锁版本号，不锁内容。修正方法是为最终制品记录不可变摘要，容器使用 digest，依赖使用带哈希锁。第二种失败是签名文件和公钥都从同一下载目录获取。修正方法是把公钥指纹通过独立受控渠道预置。第三种失败是白名单只有服务器名。修正方法是把来源、版本、摘要、命令、工具与权限组成一个不可分割的批准条目。

第四种失败是升级后沿用旧审批。修正方法是每个新制品都生成差异，至少重新检查依赖、能力和权限。第五种失败是客户端校验通过后以管理员权限运行。修正方法是使用专用低权限账户和系统级隔离。第六种失败是把"只读工具"当成无风险；读取内部资料并发送到外部同样是泄露，应限制数据域和网络出口。

第七种失败是为了可用性设置全局跳过开关。临时跳过通常会变成永久配置，并掩盖真实攻击。紧急业务确实需要例外时，应使用时效极短、限定单个制品、需要双人审批且完整审计的例外记录，而不是关闭整个校验链。

14. 一套可以落地的发布与撤回流程

发布前，由维护者提交服务器身份、源码位置、构建方式、制品摘要、签名、依赖清单、工具列表和权限需求。评审者确认注册命名空间与源码身份一致，检查关键代码和依赖变更，在隔离环境运行测试，随后把具体版本写入批准清单。部署端只能从批准清单解析安装计划，并在本地再次校验摘要与签名。

运行期间，客户端仅暴露批准工具，操作系统强制文件和网络边界，调用日志持续进入独立审计系统。同步任务定期观察弃用、删除、新版本和安全公告，但只生成候选，不直接升级。负责人依据风险和业务窗口安排复审。

撤回时，先阻止新启动和新安装，再终止或隔离现有进程，吊销相关短期凭证，定位使用同一摘要和签名密钥的实例，最后选择经过重新批准的替代版本。若怀疑凭证被工具读取，应按暴露事件处理并轮换，而不是仅卸载软件。

15. 本地进程与远程 MCP 服务要分别治理

前面的示例主要针对通过标准输入输出启动的本地服务器。远程 MCP 服务不把代码安装到用户电脑，但不能因此认为没有供应链风险。客户端依赖的对象从本地制品变成了域名、TLS 证书、服务端部署版本和授权配置。远端运营方可以在不改变 URL 的情况下更新代码，所以本地摘要锁定无法直接证明实际服务实现。此时应把服务身份、协议端点、所有者、数据处理区域、承诺的版本头和安全联系人纳入批准记录。

远程接入尤其要防止端点漂移和凭证误投。客户端只允许 HTTPS，规范化后精确匹配批准的主机与路径，不跟随跨域重定向携带授权头，也不接受服务器让客户端临时改连陌生地址。访问令牌的受众必须绑定目标服务，权限范围只覆盖批准工具，生命周期尽量短。不同 MCP Server 不应复用同一高权限令牌，否则任一服务被攻破都可能横向访问其他系统。

远程服务的能力快照仍然有效。每次连接获取工具列表后，与批准版本比较；服务端悄然新增写操作时，客户端保持不可见。若运营方能够提供签名发布声明、透明变更记录或可验证构建证明，可作为额外证据，但客户端仍要执行自己的工具白名单与参数授权。供应商证明降低的是身份和变更不透明风险，不会代替调用时的业务权限校验。

还要提前约定故障策略。远程服务身份验证失败、证书异常或能力集合变化时，应停止调用并给出明确错误，而不是自动降级到匿名连接。网络不可用时可以展示缓存的只读结果，但缓存必须绑定用户权限、服务版本和过期时间；涉及实时状态、交易或配置的结果不能假装仍然有效。

16. 给风险分级，但不要用总分掩盖红线

当团队接入几十个工具时，需要统一的评审顺序。可以从数据敏感度、操作副作用、网络范围、凭证强度、维护活跃度和可回滚性六个维度建立分级。只读取公开数据且没有凭证的工具可走轻量审批；读取内部文档、访问客户信息或具备写操作的工具必须进入严格评审和人工确认。

风险分级适合决定投入多少审查资源，不适合把不可接受行为平均掉。比如一个工具源码透明、维护活跃，却要求读取整个用户目录并向任意公网地址通信，不能因为其他项目得分高就判定"总体低风险"。路径越界、任意命令执行、无限制网络出口、长期高权令牌和无法审计的写操作，应设置为独立红线。

评审表还应描述实际业务路径，而不是抽象写"需要文件权限"。要写清读取哪个目录、什么扩展名、每次最大多少数据、输出发往哪里、用户是否看到确认界面、失败后是否会产生部分写入。具体约束才能转成运行策略和测试用例，模糊描述只会在事故后变成争论。

批准也应有复审期限。没有更新不代表没有风险：依赖可能出现漏洞，域名可能过期，维护者账号可能变更，业务数据等级也可能提升。对高权限工具设置较短复审周期，对低风险工具周期可放宽；一旦出现撤回、安全公告、所有权变化或能力差异则立即触发复审，而不是等日历到期。

17. 建立最小物料清单和责任映射

出了安全公告后，最耗时的问题通常不是"漏洞原理是什么"，而是"我们到底在哪些机器上运行了它"。因此每次安装要生成本地物料记录：MCP 服务器身份、制品摘要、直接与间接依赖版本、运行主机或环境、策略版本、负责人和安装时间。它不一定要采用复杂格式，先保证能按摘要、包名和依赖名反向查询。

物料清单必须来自实际解析并安装的环境，而不能只复制项目声明文件。声明写了宽泛版本范围，锁文件和最终环境才代表真正运行的内容。容器场景还要记录基础镜像 digest；远程服务则记录供应商发布版本和连接时观测到的能力摘要。部署完成后对实际环境再采集一次，发现与批准计划不同就失败，而不是在报告中标一个警告继续运行。

责任映射同样重要。每个批准工具至少有业务负责人和技术负责人：前者判断这个能力是否仍有业务需要，后者处理升级、漏洞和故障。只有"安全团队批准"而没有业务所有者，工具往往会永久留存；只有开发者名字而没有替补，人员变动后就无人维护。到期无人确认的高权限工具应自动停止新授权，并进入下线流程。

这套记录还能帮助做最有效的减法。定期统计最近调用时间、用户数量和失败率，长期无人使用的工具优先撤销，而不是一直为它支付补丁、密钥和审计成本。减少一个不需要的高权限进程，通常比给它再增加一层检测更可靠。

小结

MCP 让工具接入更统一，却没有消除传统软件供应链问题。注册中心帮助发现并约束发布身份，摘要固定内容，签名把内容与信任锚关联，版本锁保证可重复，白名单限定允许的能力，系统级最小权限控制事故半径。它们彼此不能替代。

最值得先做的不是搭建庞大的安全平台，而是建立一份可评审的批准清单和一个失败关闭的校验入口：没有明确版本不装，没有匹配摘要不运行，没有批准工具不暴露，没有必要权限不授予。等服务器数量和团队规模增长后，再把同一套规则接入制品库、签名服务和集中策略系统，治理模型仍然不需要推倒重来。

参考资料

• MCP Registry 官方仓库与说明
• MCP Official Registry API
• MCP Registry Authorization
• MCP Registry OpenAPI 与 Repository 稳定标识
• Python hashlib 标准库
• Python hmac.compare_digest
• Cryptography Ed25519 文档
• SLSA 供应链安全规范
• Sigstore Cosign 验证文档