cMCP：机密 MCP 运行时

在 Agent 无法触及的 TEE 内执行 MCP 工具策略

开发者预览版 —— 于 2026 年 6 月 23 日的 Confidential Computing Summit 发布。在 v1.0 之前可能存在破坏性变更。请参阅 STATUS.md，了解当前已交付内容与路线图内容的准确区别。

**cMCP（Confidential MCP Runtime）是一种安全、机密的 MCP 运行方式：这是一个开源网关，可在硬件可信执行环境（TEE）内执行 MCP 工具调用策略。**每一次工具调用都会被拦截，并根据 Cedar 策略包进行评估；策略在受其治理的进程无法触及的位置执行。每个会话都会生成一份签名 TRACE Claim，验证方无需信任运营方即可进行校验：当网关运行于 TEE 时，该凭证由硬件证明；在软件模式下则仅进行签名。如果你在寻找 MCP 的安全版本，这就是为此提供的 AgenTrust 运行时。

简而言之 —— 将 Agent 指向 cMCP Gateway。它会在 TEE 内依据 Cedar 策略评估每一次工具调用，拦截或脱敏策略拒绝的内容，并输出一份防篡改 TRACE Claim 作为证明。运行 pip install cmcp-runtime，无需硬件即可在软件模式下启动。

你的 Agent 会调用 Snowflake、Salesforce 以及十余个 API。有什么能阻止它在其中一次调用中泄露客户数据？如果监管机构提出要求，你能否证明它没有泄露？

---

一个 Agent 调用工具。策略引擎判定允许。工具调用随即通过。

但这些都无法证明策略引擎本身未被攻破。仅靠软件的 MCP 治理无法保证：

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

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

针对 MCP 工具调用的硬件证明策略执行。每一次工具调用均会被拦截，由运行于可信执行环境（TEE）中的策略引擎根据 Cedar 策略包进行评估和执行。在任何代码运行之前，策略包哈希会被写入硬件证明报告。

不同于基于隧道的连接解决方案，cMCP Runtime 会在 TEE 内处理工具调用负载。连接提供方看到的是密文，而非明文。离开 enclave 的唯一内容是签名 TRACE Claim。

---

创建 cmcp-config.yaml：

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory eases first-run tuning; the default is `enforcing`
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

启动网关：

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"}}}'

完整演练请参阅 docs/quickstart.md：包括 Cedar 策略、工具目录、第一份 TRACE Claim 及验证流程（无需硬件 TEE）。

---

1. Agent 将每一次工具调用发送至 cMCP Gateway，而不是直接发送至 MCP 服务器。
2. 启动时，网关会将 Cedar 策略包哈希写入硬件证明报告。在这项测量完成前，不会运行任何代码。
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）
opaque (opt-in)	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: "0.0.0.0:8443"
max_response_size_bytes: 2097152    # 2 MB default
policy_reload_interval_seconds: 0   # 0 = disabled; restart required to update policy

环境变量：

变量	作用
CMCP_DEV_MODE=1	使用纯软件 TEE 提供方；无需硬件
CMCP_BEARER_TOKEN	要求所有入站请求携带此 Bearer token
OPAQUE_ATTESTATION_URL	启用 OPAQUE Managed Runtime 证明功能（需显式选择）

---

命令	参数	说明
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、--audit-bundle、--agent-manifest、--agent-manifest-trust-anchor	验证已签名 TRACE Claim（签名、Schema、新鲜度、审计链及固定哈希）

---

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

字段	说明
trace.eat_profile	EAT 配置文件 URI：tag:agentrust-io.com,2026:trace-v0.2
trace.runtime	enclave 启动时记录的 TEE 平台和硬件测量值
trace.policy.bundle_hash	启动时加载的 Cedar 策略包 SHA-256；变更任一策略文件都会改变此值
trace.cnf.jwk	与 TEE 签名密钥绑定的 Ed25519 公钥
trace.tool_transcript	基于审计链生成的逐调用视图：hash（绑定审计链末端）、call_count 和保护隐私的 entries（工具名称、数据类别、决策）
gateway.audit_chain	哈希链式审计日志的根和末端；无需重放单项日志即可验证
signature	对完整 Claim 主体的规范 JSON（RFC 8785）进行 Ed25519 签名

（此表概述了最常用的字段。）

使用 cmcp_verify 库进行验证时，无需信任运营方。验证方会根据绑定至 TEE 的密钥检查签名、将策略包哈希与已批准的值进行比对，并检查审计链的内部一致性。

规范 Schema 位于 schemas/trace-claim.schema.json，docs/quickstart.md 提供了完整示例。完整验证协议请参阅 docs/spec/verification-library.md 和 TRACE 规范。

---

标准	覆盖内容
OWASP Agentic AI Top 10	MCP10（通过工具调用造成的数据泄露）、MCP02（未经批准的工具）、MCP08（可证明的治理）、MCP04（供应链）
NIST SP 800-207	TEE 内的策略决策点；不隐式信任工作负载身份
EU AI Act Art. 12, 15	逐项决策审计记录（第 12 条）；由 TEE 支持的网络安全控制（第 15 条）
DORA Art. 9	证明链；通过 gateway.audit_chain 保留审计日志
RATS/EAT RFC 9711	GatewayClaim 是一种 EAT；eat_profile 字段用于标识 TRACE 配置文件

---

工具	检查内容
ruff	每个 PR 的代码风格和导入 lint 检查
bandit	每个 PR 的 Python 安全 lint 检查
pip-audit	每个 PR 的依赖项漏洞扫描
mypy	每个 PR 的静态类型检查
CodeQL	Python SAST、安全扩展查询，每周执行
OpenSSF Scorecard	每周评分并上传 SARIF

漏洞报告和响应 SLA 请参阅 SECURITY.md。明确的范围边界请参阅 LIMITATIONS.md，其中包括第一阶段未能消除的 APM 负载捕获、运行时配置注入和 P4.1 供应链（typosquat）残余风险。

---

---

cMCP（Confidential MCP Runtime）是一个开源网关，可在硬件可信执行环境内执行 MCP 工具调用策略。它会拦截每一次工具调用，根据 Cedar 策略包进行评估，执行相应决策（允许、拒绝或脱敏），并将调用记录在硬件密封的审计链中。

cMCP 与纯软件 MCP 治理有何不同？

纯软件治理会将策略引擎运行在运营方或供应链 CVE 均可触及的同一操作系统内，因此它无法证明实际运行的策略是已批准版本，也无法证明内存中的决策未被篡改。cMCP 则将策略引擎运行在 TEE 内，并在任何代码运行前将 Cedar 策略包哈希写入硬件证明报告，因此控制平面无法被

cMCP: Confidential MCP Runtime

Enforce MCP tool policy inside a TEE, where the agent it governs cannot reach it

**Quick Start · Architecture · Configuration · CLI · Changelog **

Developer Preview - launched at the Confidential Computing Summit, June 23 2026. May have breaking changes before v1.0. See STATUS.md for exactly what ships today versus what is on the roadmap.

cMCP (Confidential MCP Runtime) is the secure, confidential way to run MCP: an open-source gateway that enforces MCP tool-call policy inside a hardware Trusted Execution Environment (TEE). Every tool call is intercepted, evaluated against a Cedar policy bundle, and enforced where the process it governs cannot reach it. Each session produces a signed TRACE Claim that a verifier checks without trusting the operator, hardware-attested when the gateway runs in a TEE and signed-only in software mode. If you are looking for a secure version of MCP, this is the AgenTrust runtime for it.

TL;DR - Point your agent at the cMCP Gateway. It evaluates every tool call against a Cedar policy inside a TEE, blocks or redacts what the policy denies, and emits a tamper-evident TRACE Claim as proof. Run pip install cmcp-runtime and start in software mode with no hardware required.

Your agent calls Snowflake, Salesforce, a dozen APIs. What stops it from leaking a customer's data on one of those calls? If a regulator asks, could you prove it didn't?

---

An agent calls a tool. The policy engine says allow. The tool call goes through.

None of that proves the policy engine itself was not compromised. Software-only MCP governance cannot guarantee:

• The Cedar policy on disk is the one that ran. A rogue admin can swap the bundle after approval; the hash check runs inside the same OS the admin controls.
• The allow/deny decision was not flipped in memory. A supply chain CVE in the evaluator runs in the same address space as the attacker.
• The audit log reflects what actually happened. Any party holding the software signing key can reconstruct a valid audit chain after the fact.

The control plane that governs tool calls must run where it cannot be reached by the process it governs.

Hardware-attested policy enforcement for MCP tool calls. Every tool call is intercepted, evaluated against a Cedar policy bundle, and enforced by a policy engine running inside a Trusted Execution Environment (TEE). The policy bundle hash is measured into the hardware attestation report before any code runs.

Unlike tunnel-based connectivity solutions, the cMCP Runtime processes tool-call payloads inside the TEE. The connectivity provider sees ciphertext, not plaintext. The only thing that leaves the enclave is the signed TRACE claim.

---

Create cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory eases first-run tuning; the default is `enforcing`
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

Start the gateway:

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

Make a tool call:

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"}}}'

See docs/quickstart.md for the full walkthrough: Cedar policy, tool catalog, first TRACE Claim, and verification (no hardware TEE required).

---

1. The agent sends every tool call to the cMCP Gateway instead of directly to MCP servers.
2. At startup the gateway measures the Cedar policy bundle hash into the hardware attestation report. No code runs before this measurement.
3. Each incoming tool call is evaluated by the Cedar policy engine running inside the TEE. The result is allow, deny, or redact. The call and its decision are appended to the hardware-sealed audit chain.
4. At the end of the session the gateway produces a TRACE Claim: a signed, hardware-attested artifact that records which tools ran, which policy decided each call, and the full audit chain. A verifier checks this without trusting the operator.

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)

---

Provider	Platform	Assurance	Notes
tpm	TPM 2.0 / vTPM (Azure, AWS, GCP Trusted Launch)	Medium	Local TPM quote
sev-snp	AMD SEV-SNP (Azure DCasv5, AWS C6a Nitro)	High	AMD KDS
tdx	Intel TDX (Azure DCedsv5, GCP C3)	High	Intel PCS
gpu-cc (v0.2)	NVIDIA H100/H200/Blackwell (CC mode)	High	NVIDIA Remote Attestation Service (NRAS)
opaque (opt-in)	OPAQUE Confidential Runtime	n/a (not yet implemented)	Placeholder: excluded from auto-detect; selecting it explicitly raises a not-implemented error

Provider auto-detect probe order: azure-cvm -> tpm -> sev-snp -> tdx. The first provider whose detect() succeeds is selected. opaque is a not-yet-implemented placeholder: it is excluded from auto-detect, and selecting it explicitly raises ATTESTATION_PROVIDER_NOT_IMPLEMENTED rather than falling through silently. If no hardware provider is detected, the gateway starts only under CMCP_DEV_MODE=1 (a non-attested software-only fallback) and otherwise refuses to start.

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

---

Mode	Behavior	Use case
enforcing	Policy denies return HTTP 403; call is not forwarded	Production
advisory	Policy denies are logged; call proceeds	First deployment, policy tuning
silent	Policy is evaluated but nothing is logged or blocked	Baselining

Default is enforcing. Set enforcement_mode: advisory in cmcp-config.yaml to use advisory mode.

---

cmcp-config.yaml full reference:

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: "0.0.0.0:8443"
max_response_size_bytes: 2097152    # 2 MB default
policy_reload_interval_seconds: 0   # 0 = disabled; restart required to update policy

Environment variables:

Variable	Effect
CMCP_DEV_MODE=1	Use software-only TEE provider; no hardware required
CMCP_BEARER_TOKEN	Require this bearer token on all inbound requests
OPAQUE_ATTESTATION_URL	Enable OPAQUE Managed Runtime attestation (explicit opt-in)

---

Command	Flags	Description
cmcp start	--config PATH (required)	Start the gateway
cmcp validate-config	--config PATH (required)	Validate cmcp-config.yaml without starting
cmcp validate-bundle	--bundle-path PATH (required), --expected-hash sha256:<hex> (required)	Verify a Cedar bundle hash before deployment
cmcp verify	CLAIM_FILE (required); --policy-hash, --catalog-hash, --max-age, --trusted-key, --audit-bundle, --agent-manifest, --agent-manifest-trust-anchor	Verify a signed TRACE Claim (signature, schema, freshness, audit chain, and pinned hashes)

---

A GatewayClaim is the unit of proof handed to an auditor, regulator, or downstream verifier. It is produced per session (or per call, configurable) and signed with a key that never leaves the TEE.

Field	Description
trace.eat_profile	EAT profile URI: tag:agentrust-io.com,2026:trace-v0.2
trace.runtime	TEE platform and hardware measurement recorded at enclave boot
trace.policy.bundle_hash	SHA-256 of the Cedar bundle loaded at startup; changing any policy file changes this value
trace.cnf.jwk	Ed25519 public key bound to the TEE signing key
trace.tool_transcript	Audit-chain-derived per-call view: hash (binds to the audit chain tip), call_count, and privacy-preserving entries (tool name, data class, decision)
gateway.audit_chain	Hash-chained audit log root and tip; verifiable without replaying individual entries
signature	Ed25519 over canonical JSON of the full claim body (RFC 8785)

(This table is a summary of the most-used fields.)

Verification with the cmcp_verify library does not require trusting the operator. The verifier checks the signature against the TEE-bound key, the policy bundle hash against the approved value, and the audit chain for internal consistency.

The normative schema is schemas/trace-claim.schema.json, and docs/quickstart.md shows a complete example. See docs/spec/verification-library.md and the TRACE specification for the full verification protocol.

---

Standard	Coverage
OWASP Agentic AI Top 10	MCP10 (data leakage via tool calls), MCP02 (unsanctioned tools), MCP08 (provable governance), MCP04 (supply chain)
NIST SP 800-207	Policy decision point inside TEE; no implicit trust in workload identity
EU AI Act Art. 12, 15	Per-decision audit records (Art. 12); TEE-backed cybersecurity controls (Art. 15)
DORA Art. 9	Attestation chain; audit log retention via gateway.audit_chain
RATS/EAT RFC 9711	GatewayClaim is an EAT; eat_profile field identifies the TRACE profile

---

Tool	What it checks
ruff	Style and import linting on every PR
bandit	Python security linting on every PR
pip-audit	Dependency vulnerability scan on every PR
mypy	Static type checking on every PR
CodeQL	Python SAST, security-extended queries, weekly
OpenSSF Scorecard	Weekly scoring, SARIF upload

See SECURITY.md for vulnerability reporting and response SLAs. See LIMITATIONS.md for explicit scope boundaries, including residual risks for APM payload capture, runtime config injection, and P4.1 supply chain (typosquat) that Phase 1 does not close.

---

---

cMCP (Confidential MCP Runtime) is an open-source gateway that enforces MCP tool-call policy inside a hardware Trusted Execution Environment. It intercepts each tool call, evaluates it against a Cedar policy bundle, enforces the decision (allow, deny, or redact), and records the call in a hardware-sealed audit chain.

How is cMCP different from software-only MCP governance?

Software-only governance runs the policy engine in the same OS an operator or a supply-chain CVE can reach, so it cannot prove the policy that ran was the approved one or that the decision was not flipped in memory. cMCP runs the policy engine inside a TEE and measures the Cedar bundle hash into the hardware attestation report before any code runs, so the control plane cannot be reached by the process it governs.

Do I need special hardware to try it?

No. Set CMCP_DEV_MODE=1 to use the software-only TEE provider and run the full quickstart without a hardware TEE. Hardware providers (TPM, AMD SEV-SNP, Intel TDX, OPAQUE) are used in production.

A TRACE Claim (a GatewayClaim) is a signed, hardware-attested artifact produced per session. It records which tools ran, which policy decided each call, the Cedar bundle hash, and the audit chain, and it is signed with an Ed25519 key that never leaves the TEE. A verifier checks it with the cmcp_verify library without trusting the operator.

Which TEE providers are supported?

TPM 2.0 / vTPM, AMD SEV-SNP, and Intel TDX, with NVIDIA GPU confidential computing planned for v0.2 and OPAQUE Confidential Runtime available as explicit opt-in. Auto-detection order is Azure confidential VM, then TPM 2.0 / vTPM, then AMD SEV-SNP, then Intel TDX; the software-only provider is used only under CMCP_DEV_MODE=1.

What license is cMCP under?

MIT.

---

CONTRIBUTING.md · GOVERNANCE.md · Discussions

Join the community on Discord.

Using cMCP in production? Add your organization to ADOPTERS.md.

---

MIT - see LICENSE.