Enforce MCP tool policies inside hardware-attested TEEs

cMCP: Confidential MCP Runtime

Community updates and contributor highlights: AgenTrust on LinkedIn.

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

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 an open-source gateway that checks every tool call an AI agent makes against rules you write, and can run on sealed-off hardware the agent cannot tamper with. AI agents use tools (databases, CRMs, email, internal APIs) by sending requests called tool calls, usually over MCP, the Model Context Protocol. cMCP sits in the path of those calls, checks each one against your rules (written in the Cedar policy language), and blocks the ones the rules forbid. It can run inside a TEE (trusted execution environment: hardware that keeps a program's memory sealed off even from the machine's owner), where the agent it governs cannot reach it. Each session ends with a signed receipt, a TRACE Claim, that anyone can check without trusting whoever ran the gateway. The receipt is backed by a hardware report when the gateway runs in a TEE, and is signed only (no hardware proof) in software mode. New to these terms? See the terms, in plain English.

TL;DR: Point your agent at the cMCP Gateway. It checks every tool call against your Cedar rules, blocks or redacts (blanks out) what the rules deny, and gives you a signed receipt that shows if anyone altered it. Run pip install cmcp-runtime and start in software mode on any computer; no special 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?

The problem

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). Before it serves a single tool call, the gateway measures its installed code, policy bundle and config into the hardware attestation report, and re-attests whenever the bundle reloads.

In a hardware deployment, the cMCP Runtime processes tool-call payloads inside the TEE. What the host and connectivity provider can read also depends on the egress policy, and the upstream tool server is a separate component outside the TEE. Software mode (CMCP_DEV_MODE) provides no hardware isolation. LIMITATIONS.md lists what cMCP does not prevent.

Quick Start

pip install cmcp-runtime

Create 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 is not optional here. CMCP_DEV_MODE=1 deliberately skips the bearer token requirement so you can try things quickly, and the default bind is still 0.0.0.0:8443. On 0.3.0 that combination stood up an unauthenticated gateway on every interface on your machine. From 0.4.0 it is refused: tokenless dev mode may only bind a loopback address, and a non-loopback bind requires CMCP_BEARER_TOKEN. Pin listen_addr explicitly and the config is correct on both.

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

Prefer a guided version? agentrust-io.com/quickstart walks the same path in about ten minutes on a laptop, with no hardware and no signup: install, write one Cedar forbid rule, watch a tool call return 403 POLICY_DENY before it reaches an upstream, then verify the signed receipt.

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

How it works

1. The agent sends every tool call to the cMCP Gateway instead of directly to MCP servers.
2. At startup, before it serves traffic, the gateway measures its installed code, Cedar policy bundle and config. On SEV-SNP, TDX and Azure CVM the digest is bound into report_data; on the TPM tier it is extended into a certified NV index. A policy reload triggers a fresh attestation.
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)

Hardware providers

Provider auto-detect probe order: azure-cvm -> tpm -> sev-snp -> tdx. The first provider whose detect() succeeds is selected. 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

Enforcement modes

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

Configuration

cmcp-config.yaml full reference:

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

Environment variables:

CLI reference

TRACE Claims

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.

(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.

Standards alignment

Security

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.

Documentation

FAQ

What is cMCP?

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 its code and Cedar bundle into the hardware attestation report before it serves a single call, 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) are used in production.

What is a TRACE Claim?

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. 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.