cMCP: 機密MCPランタイム

コミュニティの最新情報とコントリビューターのハイライト: LinkedInのAgenTrust。

管理対象のエージェントが到達できないTEE内でMCPツールポリシーを強制する

クイックスタート · アーキテクチャ · 設定 · CLI · 変更履歴

開発者プレビュー - 2026年6月23日のConfidential Computing Summitで発表。v1.0までに破壊的変更が入る可能性があります。現在出荷されているものとロードマップ上のものを正確に知るにはSTATUS.mdを参照してください。

cMCP (Confidential MCP Runtime) は、AIエージェントが行うすべてのツール呼び出しを、あなたが書いたルールに照らして検査し、エージェントが改ざんできない封鎖されたハードウェア上で実行できるオープンソースのゲートウェイです。 AIエージェントは、通常MCP (Model Context Protocol) を介して送信されるツール呼び出しと呼ばれるリクエストを送ることで、ツール (データベース、CRM、メール、内部API) を利用します。cMCPはそれらの呼び出しの経路上に位置し、各呼び出しをあなたのルール (Cedarポリシー言語で記述) に照らして検査し、ルールが禁止するものをブロックします。cMCPはTEE (trusted execution environment: マシンの所有者からさえもプログラムのメモリを封鎖するハードウェア) 内で実行でき、そこで管理対象のエージェントはcMCPに到達できません。各セッションは署名済みのレシートであるTRACE Claimで終わり、これはゲートウェイを実行した者を信頼することなく誰でも検証できます。レシートは、ゲートウェイがTEE内で実行される場合はハードウェアレポートに裏付けられ、ソフトウェアモードでは署名のみ (ハードウェア証明なし) となります。これらの用語が初めての方は、平易な英語による用語解説を参照してください。

TL;DR: エージェントをcMCP Gatewayに向けてください。すべてのツール呼び出しをあなたのCedarルールに照らして検査し、ルールが拒否するものをブロックまたは秘匿 (空白化) し、誰かが改ざんしたかどうかを示す署名済みレシートを提供します。pip install cmcp-runtimeを実行し、特別なハードウェアを必要とせず、任意のコンピュータ上でソフトウェアモードで開始できます。

あなたのエージェントはSnowflake、Salesforce、十数のAPIを呼び出します。それらの呼び出しの1つで顧客のデータが漏洩するのを何が防ぐのでしょうか? 規制当局から問われた場合、漏洩しなかったことを証明できるでしょうか?

問題

エージェントがツールを呼び出します。ポリシーエンジンが許可を出します。ツール呼び出しが通過します。

そのいずれも、ポリシーエンジン自体が侵害されていないことを証明しません。ソフトウェアのみのMCPガバナンスでは以下を保証できません:

ディスク上のCedarポリシーが実行されたものであること。悪意のある管理者は承認後にバンドルを差し替えられます。ハッシュチェックは管理者が制御する同じOS内で実行されます。
許可/拒否の決定がメモリ内で反転されていないこと。評価器のサプライチェーンCVEは攻撃者と同じアドレス空間で実行されます。
監査ログが実際に起きたことを反映していること。ソフトウェア署名鍵を保持する者は誰でも、事後に有効な監査チェーンを再構築できます。

ツール呼び出しを統治するコントロールプレーンは、それが統治するプロセスから到達できない場所で実行されなければなりません。

MCPツール呼び出しに対するハードウェア認証されたポリシー強制。すべてのツール呼び出しは傍受され、Cedarポリシーバンドルに照らして評価され、Trusted Execution Environment (TEE) 内で実行されるポリシーエンジンによって強制されます。単一のツール呼び出しを処理する前に、ゲートウェイはインストールされたコード、ポリシーバンドル、および設定をハードウェア認証レポートに測定し、バンドルが再ロードされるたびに再認証します。

ハードウェアデプロイメントでは、cMCP RuntimeはTEE内でツール呼び出しペイロードを処理します。ホストと接続プロバイダが何を読み取れるかはegressポリシーにも依存し、上流のツールサーバーはTEE外の別コンポーネントです。ソフトウェアモード (CMCP_DEV_MODE) はハードウェア分離を提供しません。cMCPが防がないものについてはLIMITATIONS.mdに記載されています。

クイックスタート

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は迅速に試せるようにベアラトークン要件を意図的にスキップし、デフォルトのバインドは依然として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は、ハードウェアもサインアップも不要で、ノートPC上で約10分で同じ道筋をたどります: インストールし、1つのCedar forbidルールを書き、ツール呼び出しが上流に到達する前に403 POLICY_DENYを返すのを確認し、署名済みレシートを検証します。

完全なウォークスルーについてはdocs/quickstart.mdを参照してください: Cedarポリシー、ツールカタログ、最初のTRACE Claim、および検証 (ハードウェアTEEは不要)。

仕組み

エージェントは、MCPサーバーに直接ではなく、すべてのツール呼び出しをcMCP Gatewayに送信します。
起動時、トラフィックを処理する前に、ゲートウェイはインストールされたコード、Cedarポリシーバンドル、および設定を測定します。SEV-SNP、TDX、Azure CVMではダイジェストがreport_dataにバインドされ、TPM層では認定されたNVインデックスに拡張されます。ポリシーの再ロードは新たな認証をトリガーします。
受信する各ツール呼び出しは、TEE内で実行されるCedarポリシーエンジンによって評価されます。結果はallow、deny、またはredactです。呼び出しとその決定は、ハードウェアで封鎖された監査チェーンに追加されます。
セッションの終了時に、ゲートウェイは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	n/a (未実装)	プレースホルダ: 自動検出から除外; 明示的に選択すると未実装エラーが発生

プロバイダの自動検出プローブ順序: 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です。advisoryモードを使用するには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)

cmcp v0.4.0