MCP 网关只会写审计日志还不够：用 cMCP 把策略、执行与可验证收据放进不同信任边界
给 AI Agent 接上 MCP 以后，真正棘手的问题并不是「它能不能调用工具」，而是「谁能证明这一次调用确实遵守了批准过的规则」。普通网关可以记录 allow/deny 结果，但策略引擎、日志和被治理的 Agent 往往仍在同一台机器、同一个管理员权限边界内：策略文件可以被替换，内存中的判断可以被篡改，事后日志也很难独立证明没有被重写。
cMCP（Confidential MCP Runtime）试图把这条链路拆开。它是一个 MIT 许可、仍处于 Developer Preview 的开源 MCP 网关：Agent 先将工具调用交给网关；网关在可信执行环境（TEE）内按 Cedar 策略评估请求，再决定放行、拒绝或脱敏；会话结束时输出带签名的 TRACE Claim。它的目标不是取代每一种 MCP Server，而是为高风险调用增加一个可验证的执行边界。
先区分三个问题：能拦截、能审计、能证明
很多治理方案停在前两层：把工具请求经由代理转发，并把结果写进审计系统。这对限流、提示注入检测和日常排障已经有价值，但仍要信任运行代理的操作系统和维护者。
cMCP 的核心主张是把策略决策放到被治理进程无法直接触及的边界里。启动时，它会将 Cedar 策略包的哈希纳入硬件证明材料；每一条工具调用都先由策略引擎处理；每个会话再生成 TRACE Claim。该 Claim 包含策略包哈希、运行时度量、审计链的根与末端，以及对规范化 JSON 的 Ed25519 签名。外部验证者据此检查签名、策略哈希、时效性和审计链一致性，而不是只接受运营方导出的一份日志。
这并不意味着 TEE 自动消除全部风险。它保护的是策略执行与证明材料之间的边界，不会替你写出正确的授权规则，也不会让不安全的上游 MCP Server 突然安全。cMCP 的 STATUS.md 和限制文档仍应作为上线前的阅读材料；尤其在 Developer Preview 阶段，接口和能力边界可能变化。
最小可复现路径：先在本机校准策略
官方 README 给出了不依赖硬件 TEE 的本地试用方式。CMCP_DEV_MODE=1 使用软件模式，适合学习策略与收据验证流程；它不是生产等价配置。一个重要的防护细节是显式绑定 loopback：已发布的 0.3.0 默认监听 0.0.0.0:8443，而开发模式会跳过 Bearer Token 要求，因此不能把默认开发配置暴露到局域网或公网。
python -m pip install cmcp-runtime cat > cmcp-config.yaml <<'YAML' attestation: provider: auto enforcement_mode: advisory listen_addr: "127.0.0.1:8443" policy_bundle_path: ./policies/ catalog_path: ./catalog.json YAML CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml
第一次部署使用 advisory 的价值在于观察真实请求会被哪些规则命中，而不立即中断业务；完成规则校准后再切换到默认的 enforcing。在 enforcing 模式下，拒绝的调用返回 HTTP 403 且不会转发；advisory 只记录拒绝结果但允许请求继续；silent 则评估但不记录也不拦截。后者可用于基线研究，却不应被误认为防护模式。
上线前可先让 CI 或部署流水线验证配置与策略包，而不是把格式错误留到网关启动时：
cmcp validate-config --config cmcp-config.yaml cmcp validate-bundle \ --bundle-path ./policies \ --expected-hash sha256:你的已批准策略包哈希
这里的哈希应来自经过评审、固定版本的策略工件。只把策略目录挂载进容器、却没有把审批后的哈希纳入发布记录，仍会留下「部署的究竟是不是评审版本」这一空洞。
调用路径如何变化
接入后，请求不再是 Agent → MCP Server 的直连，而是：
Agent → cMCP Runtime → Cedar 策略引擎（TEE）→ 上游工具
└→ TRACE Claim：策略哈希、审计链、签名与证明信息
策略评估的结果可以是 allow、deny 或 redact。前两个结果容易理解；redact 的意义是在可继续完成的工作流中缩小返回内容或可见数据，而不是只有「全放行」与「全阻断」两种选择。策略包、允许的工具目录和调用入口应一起版本化：只写一条「禁止导出客户数据」的自然语言规则不足以约束真实工具参数，必须让工具目录和 Cedar 规则覆盖到实际的工具名、动作与数据分类。
完成会话后，可使用 CLI 校验生成的收据：
cmcp verify claim.json \ --policy-hash sha256:你的已批准策略包哈希 \ --max-age 86400 \ --trusted-key verifier-public-key.pem
验证环节最容易被忽略。若团队只在网关旁保存 JSON 文件，却不固定可信公钥、策略哈希和最大有效期，收据就退化成另一种日志。将这些值和部署版本、变更单关联，才能回答审计中的关键问题：哪个策略决定了哪次调用，以及这份证据是否仍在可接受的时间窗口内。
TEE 不是统一开关，部署方式决定保证强度
cMCP 文档列出的硬件提供方包括 TPM/vTPM、AMD SEV-SNP 与 Intel TDX；自动探测会按既定顺序选择可用提供方。没有可用硬件提供方时，非开发模式会拒绝启动，而不是悄悄降级到软件模式。这种 fail-closed 行为值得保留：生产配置若要求硬件证明，就不该在基础设施变更后无声地失去它。
不过，团队仍需自行确认云实例、vTPM/机密计算配置、证明链验证和密钥托管是否符合自己的合规要求。README 中列出的 NVIDIA GPU 机密计算属于 v0.2 计划能力；opaque 也是尚未实现的占位提供方。不要把文档中的路线图当作当前可用功能写进部署设计。
适合什么团队，不适合什么场景
当 Agent 可以发起退款、删除资源、访问客户资料、执行生产变更，且组织需要让安全、合规或合作方独立复核决策时，cMCP 的「策略哈希 + 硬件边界 + 可验证收据」模型有明确价值。它也适合将高风险工具与普通检索工具分层：低风险调用走常规 MCP，高风险调用进入受策略与证明约束的入口。
反过来，如果团队还没有稳定的工具目录、负责人和规则评审流程，直接部署 TEE 网关往往只会得到一套更复杂的基础设施。先明确每个工具的动作、数据级别、默认拒绝条件和人工升级路径，再把这些决定编码进策略包，收益更大。cMCP 提供的是让既定治理规则更难被绕过、也更容易被复核的执行层；它不能替代治理规则本身。
失败模式：把“证明”误当成“授权”
这类架构最常见的误用，是看到签名收据后就认为调用天然合规。实际上，TRACE Claim 可以证明某个已加载策略做出了某项决定，却不能证明策略本身覆盖了所有业务风险。例如，规则只按工具名放行 crm.update_contact，但没有约束字段范围，Agent 仍可能在一次被允许的调用中更新不该修改的客户属性。策略设计应同时考虑主体、动作、资源、参数约束、数据分类和人工审批证据，而不是只列工具黑白名单。
第二个失败模式是把开发模式带入生产。CMCP_DEV_MODE=1 的作用是降低试用门槛；它不是硬件证明的替代品。生产环境应显式配置认证、网络监听范围、策略工件来源和可信验证密钥，并在基础设施迁移、策略更新或密钥轮换后重新验证 Claim。特别是策略热更新：当前默认 policy_reload_interval_seconds 为 0，意味着变更策略需要重启 enclave；把这个行为纳入变更流程，比期待网关自动加载目录中的新文件更安全。
第三个失败模式是只收集收据而不消费它。建议将 cmcp verify 放到事件处置、变更审批或定期抽查中：对高风险会话固定抽样，验证 Claim 的策略哈希是否属于批准清单、签名是否来自预期密钥、时间是否新鲜、审计链是否连续；验证失败时把该会话视为不可证明，而不是默认可信。这样，收据才从「调试附件」变成安全控制的一部分。
结语
AI Agent 的安全边界不应只是一份「我们记录了日志」的承诺。cMCP 将策略评估、上游工具调用和可验证证明连接起来，适合需要把运行时决策带出运营者信任边界的工作流。实践顺序应是：本地用 advisory 校准规则，固定策略包哈希和可信验证密钥，再在满足硬件条件的环境启用 enforcing；每次变更都同时审查工具目录、策略包和验证基线。