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

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