cMCP：机密 MCP 运行时

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

在 TEE 内部强制执行 MCP 工具策略，使其所管理的代理无法触及

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

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

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

你的代理会调用 Snowflake、Salesforce 以及十几个 API。是什么阻止它在其中某次调用中泄露客户数据？如果监管机构问起，你能证明它没有泄露吗？

问题所在

代理调用一个工具。策略引擎判定为允许。工具调用通过。

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

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

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

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

在硬件部署中，cMCP 运行时在 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 起，这种情况会被拒绝：无令牌的开发模式只能绑定回环地址，非回环绑定需要 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）。

工作原理

代理将每一次工具调用发送到 cMCP 网关，而不是直接发送到 MCP 服务器。
启动时，在服务流量之前，网关会度量其已安装的代码、Cedar 策略包和配置。在 SEV-SNP、TDX 和 Azure CVM 上，摘要会被绑定到 report_data；在 TPM 层级上，它会被扩展到经过认证的 NV 索引中。策略重新加载会触发一次新的证明。
每个传入的工具调用都由运行在 TEE 内的 Cedar 策略引擎进行评估。结果为允许、拒绝或脱敏。该调用及其决定会被追加到硬件密封的审计链中。
会话结束时，网关会生成一份 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 引用
`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)
`opaque` (需显式选择)	OPAQUE Confidential Runtime	不适用 (尚未实现)	占位符：不参与自动检测；显式选择会抛出未实现错误

提供商自动检测探测顺序：azure-cvm -> tpm -> sev-snp -> tdx。第一个 detect() 成功的提供商会入选。opaque 是一个尚未实现的占位符：它不参与自动检测，显式选择它会抛出 ATTESTATION_PROVIDER_NOT_IMPLEMENTED，而不是静默回退。如果未检测到任何硬件提供商，网关仅在 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

# OPAQUE Managed Runtime (opt-in only; not yet implemented)
# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml

执行模式

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

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

配置

cmcp-config.yaml 完整参考：

attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | opaque | 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
`OPAQUE_ATTESTATION_URL`	启用 OPAQUE Managed Runtime 证明（需显式选择）

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（签名、模式、新鲜度、审计链、固定哈希和信任锚）

TRACE Claims

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

cmcp v0.4.0