cMCP：机密 MCP 运行时

社区动态与贡献者亮点：AgenTrust on LinkedIn。

在 TEE 内强制执行 MCP 工具策略，使其所管控的智能体无法触及

快速开始 · 架构 · 配置 · CLI · 更新日志

开发者预览版 - 于 2026 年 6 月 23 日在机密计算峰会上发布。在 v1.0 之前可能会有破坏性变更。请参阅 STATUS.md 了解当前已交付的内容与路线图上的内容。

cMCP（机密 MCP 运行时）是一个开源网关，它会根据你编写的规则检查 AI 智能体发起的每一次工具调用，并且可以运行在智能体无法篡改的封闭硬件上。 AI 智能体通过发送称为工具调用的请求来使用工具（数据库、CRM、电子邮件、内部 API），通常经由 MCP（模型上下文协议）进行。cMCP 位于这些调用的路径上，根据你的规则（使用 Cedar 策略语言编写）检查每一次调用，并阻止规则禁止的调用。它可以运行在 TEE（可信执行环境：即使对机器所有者也能将程序内存封闭隔离的硬件）内，其所管控的智能体无法触及。每个会话结束时都会生成一份签名收据，即 TRACE Claim，任何人都可以在不信任网关运行者的情况下进行验证。当网关在 TEE 中运行时，该收据由硬件报告背书；在软件模式下则仅签名（无硬件证明）。不熟悉这些术语？请参阅通俗易懂的术语说明。

简而言之： 将你的智能体指向 cMCP Gateway。它会根据你的 Cedar 规则检查每一次工具调用，阻止或脱敏（涂黑）规则拒绝的内容，并为你提供一份签名收据，显示是否有人篡改过它。运行 pip install cmcp-runtime，即可在任何计算机上以软件模式启动；无需特殊硬件。

你的智能体调用 Snowflake、Salesforce、十几个 API。是什么阻止它在这些调用中泄露客户数据？如果监管机构问起，你能证明它没有泄露吗？

---

问题所在

智能体调用一个工具。策略引擎说允许。工具调用通过。

这一切都无法证明策略引擎本身没有被攻破。仅靠软件的 MCP 治理无法保证：

• 磁盘上的 Cedar 策略就是实际运行的那一份。恶意管理员可以在审批后替换策略包；哈希校验运行在管理员控制的同一操作系统内。
• 允许/拒绝决策没有在内存中被翻转。评估器中的供应链 CVE 与攻击者运行在同一地址空间。
• 审计日志反映了实际发生的情况。任何持有软件签名密钥的一方都可以事后重建一条有效的审计链。

管控工具调用的控制平面必须运行在其所管控的进程无法触及的地方。

面向 MCP 工具调用的硬件证明策略执行。每一次工具调用都会被拦截，依据 Cedar 策略包进行评估，并由运行在可信执行环境（TEE）内的策略引擎强制执行。在提供任何一次工具调用服务之前，网关会将其已安装的代码、策略包和配置度量到硬件证明报告中，并在策略包重新加载时重新进行证明。

在硬件部署中，cMCP Runtime 在 TEE 内处理工具调用负载。主机和连接提供商能够读取的内容还取决于出口策略，而上游工具服务器是位于 TEE 之外的独立组件。软件模式（CMCP_DEV_MODE）不提供硬件隔离。LIMITATIONS.md 列出了 cMCP 无法防范的内容。

---

快速开始

pip install cmcp-runtime

创建 cmcp-config.yaml：

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory eases first-run tuning; the default is `enforcing`
listen_addr: "127.0.0.1:8443"  # pin loopback: dev mode runs without a bearer token
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

listen_addr 在这里不是可选项。CMCP_DEV_MODE=1 会刻意跳过 bearer token 要求，以便你快速试用，而默认绑定仍然是 0.0.0.0:8443。在 0.3.0 上，这种组合会在你机器的每个网络接口上启动一个未认证的网关。从 0.4.0 起，这种配置会被拒绝：无 token 的开发模式只能绑定回环地址，而非回环绑定需要 CMCP_BEARER_TOKEN。显式固定 listen_addr，配置在两者上都是正确的。

启动网关：

CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml

发起工具调用：

curl -X POST http://localhost:8443/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"salesforce.contacts","arguments":{"query":"Acme Corp"},"_cmcp":{"session_id":"s1","workflow_id":"demo-agent"}}}'

想要引导式版本？agentrust-io.com/quickstart 在笔记本电脑上大约十分钟就能走完同样的流程，无需硬件，也无需注册：安装、编写一条 Cedar forbid 规则、观察一次工具调用在到达上游之前返回 403 POLICY_DENY，然后验证签名回执。

完整演练请参见 docs/quickstart.md：Cedar 策略、工具目录、首个 TRACE Claim 以及验证（无需硬件 TEE）。

---

工作原理

1. 智能体将每次工具调用发送到 cMCP Gateway，而不是直接发送到 MCP 服务器。
2. 在启动时、开始处理流量之前，网关会度量其已安装的代码、Cedar 策略包和配置。在 SEV-SNP、TDX 和 Azure CVM 上，摘要会被绑定到 report_data 中；在 TPM 层级上，它会被扩展到经过认证的 NV 索引中。策略重新加载会触发一次新的证明。
3. 每个传入的工具调用都由运行在 TEE 内的 Cedar 策略引擎进行评估。结果为允许、拒绝或脱敏。该调用及其决策会被追加到硬件密封的审计链中。
4. 在会话结束时，网关会生成一个 TRACE Claim：一个经过签名、由硬件证明的工件，记录哪些工具运行过、每次调用由哪条策略决定，以及完整的审计链。验证者无需信任运营方即可检查这一点。

Agent -> cMCP Runtime -> Cedar Policy Engine (TEE) -> Tool
                     |
               GatewayClaim (TRACE Profile)
               +-- trace.eat_profile
               +-- trace.runtime.platform + measurement
               +-- trace.policy.bundle_hash
               +-- trace.cnf.jwk  (Ed25519 confirmation key)
               +-- gateway.audit_chain (root/tip/length)
               +-- signature (Ed25519 over canonical JSON)

硬件提供程序

提供程序	平台	保证级别	说明
tpm	TPM 2.0 / vTPM（Azure、AWS、GCP Trusted Launch）	中	本地 TPM quote
sev-snp	AMD SEV-SNP（Azure DCasv5、AWS C6a Nitro）	高	AMD KDS
tdx	Intel TDX（Azure DCedsv5、GCP C3）	高	Intel PCS
gpu-cc (v0.2)	NVIDIA H100/H200/Blackwell（CC 模式）	高	NVIDIA Remote Attestation Service (NRAS)

提供程序自动检测探测顺序：azure-cvm -> tpm -> sev-snp -> tdx。将选择第一个 detect() 成功的提供程序。如果未检测到任何硬件提供程序，网关仅在 CMCP_DEV_MODE=1（一种非认证的纯软件回退模式）下启动，否则拒绝启动。

from cmcp_runtime.config import TEEProvider

# Auto-detect (default)
# attestation.provider: auto  ->  azure-cvm -> tpm -> sev-snp -> tdx
# (software-only is used only under CMCP_DEV_MODE=1)

# Explicit hardware selection
# attestation.provider: sev-snp

执行模式

模式	行为	使用场景
enforcing	策略拒绝时返回 HTTP 403；调用不会被转发	生产环境
advisory	策略拒绝会被记录；调用继续执行	首次部署、策略调优
silent	策略会被评估，但不记录也不阻止任何内容	基线建立

默认值为 enforcing。在 cmcp-config.yaml 中设置 enforcement_mode: advisory 以使用 advisory 模式。

---

配置

cmcp-config.yaml 完整参考：

attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | software-only
  enforcement_mode: enforcing       # enforcing | advisory | silent
  validity_seconds: 86400           # attestation freshness window (default: 24 hours)
  staleness_policy: fail_closed     # fail_closed | warn_only
  expected_measurement: ~           # pin a specific PCR/measurement (optional)

policy_bundle_path: policies/       # directory containing .cedar files and manifest.json
catalog_path: catalog.json          # approved tool catalog

listen_addr: "127.0.0.1:8443"     # tokenless dev mode is loopback-only; set CMCP_BEARER_TOKEN before binding wider
max_response_size_bytes: 2097152    # 2 MB default
policy_reload_interval_seconds: 0   # >0 with a pinned CMCP_POLICY_HASH refuses to start, see docs/spec/policy-hot-reload.md

环境变量：

变量	作用
CMCP_DEV_MODE=1	使用仅软件的 TEE 提供程序；无需硬件
CMCP_BEARER_TOKEN	要求所有入站请求携带此 bearer token

---

CLI 参考

命令	标志	描述
cmcp start	--config PATH（必需）	启动网关
cmcp validate-config	--config PATH（必需）	在不启动的情况下验证 cmcp-config.yaml
cmcp validate-bundle	--bundle-path PATH（必需）、--expected-hash sha256:<hex>（必需）	在部署前验证 Cedar 包哈希
cmcp verify	CLAIM_FILE（必需）；--policy-hash、--catalog-hash、--max-age、--trusted-key、--trusted-tpm-ca、--audit-bundle、--agent-manifest、--agent-manifest-trust-anchor	验证已签名的 TRACE Claim（签名、schema、新鲜度、审计链、固定哈希和信任锚）

---

TRACE Claims

GatewayClaim 是交付给审计员、监管机构或下游验证者的证明单元。它按会话（或按调用，可配置）生成，并使用永不离开 TEE 的密钥签名。