cMCP: 기밀 MCP 런타임

커뮤니티 업데이트 및 기여자 하이라이트: LinkedIn의 AgenTrust.

관리 대상 에이전트가 접근할 수 없는 TEE 내부에서 MCP 도구 정책을 적용하세요

개발자 프리뷰 - 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(신뢰 실행 환경: 머신 소유자조차도 프로그램의 메모리에 접근할 수 없도록 격리하는 하드웨어) 내부에서 실행될 수 있으며, 이 경우 관리 대상 에이전트는 cMCP에 접근할 수 없습니다. 각 세션은 서명된 영수증인 TRACE Claim으로 종료되며, 게이트웨이를 실행한 주체를 신뢰하지 않고도 누구나 이를 검증할 수 있습니다. 이 영수증은 게이트웨이가 TEE에서 실행될 때 하드웨어 보고서로 뒷받침되며, 소프트웨어 모드에서는 서명만 제공됩니다(하드웨어 증명 없음). 이러한 용어가 생소하신가요? 쉬운 말로 설명한 용어를 참조하세요.

요약: 에이전트를 cMCP 게이트웨이로 연결하세요. 게이트웨이는 모든 도구 호출을 Cedar 규칙에 따라 검사하고, 규칙이 거부하는 호출을 차단하거나 마스킹(내용을 비움)하며, 누군가 변조했는지 보여주는 서명된 영수증을 제공합니다. pip install cmcp-runtime을 실행하고 특별한 하드웨어 없이 모든 컴퓨터에서 소프트웨어 모드로 시작하세요.

에이전트가 Snowflake, Salesforce, 수십 개의 API를 호출합니다. 그 호출 중 하나에서 고객 데이터가 유출되는 것을 무엇이 막아줄까요? 규제 기관이 요청하면 유출되지 않았음을 증명할 수 있을까요?

문제

에이전트가 도구를 호출합니다. 정책 엔진이 허용이라고 판단합니다. 도구 호출이 통과됩니다.

이 중 어느 것도 정책 엔진 자체가 침해되지 않았음을 증명하지 못합니다. 소프트웨어 전용 MCP 거버넌스는 다음을 보장할 수 없습니다:

디스크에 있는 Cedar 정책이 실제로 실행된 정책임을 보장하지 못합니다. 악의적인 관리자는 승인 후 번들을 교체할 수 있으며, 해시 검사는 관리자가 제어하는 동일한 OS 내부에서 실행됩니다.
허용/거부 결정이 메모리에서 뒤집히지 않았음을 보장하지 못합니다. 평가기의 공급망 CVE는 공격자와 동일한 주소 공간에서 실행됩니다.
감사 로그가 실제로 일어난 일을 반영함을 보장하지 못합니다. 소프트웨어 서명 키를 보유한 누구든 사후에 유효한 감사 체인을 재구성할 수 있습니다.

도구 호출을 관리하는 제어 평면은 관리 대상 프로세스가 접근할 수 없는 곳에서 실행되어야 합니다.

MCP 도구 호출에 대한 하드웨어 증명 기반 정책 적용. 모든 도구 호출은 가로채여 Cedar 정책 번들에 대해 평가되며, TEE(Trusted Execution Environment) 내부에서 실행되는 정책 엔진에 의해 적용됩니다. 게이트웨이는 단일 도구 호출을 처리하기 전에 설치된 코드, 정책 번들 및 구성을 하드웨어 증명 보고서에 측정하고, 번들이 다시 로드될 때마다 재증명합니다.

하드웨어 배포에서 cMCP Runtime은 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 토큰 요구 사항을 의도적으로 건너뛰며, 기본 바인딩은 여전히 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는 하드웨어도, 가입도 필요 없이 노트북에서 약 10분 만에 동일한 과정을 안내합니다. 설치하고, 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 정책 엔진에 의해 평가됩니다. 결과는 허용, 거부, 또는 마스킹입니다. 호출과 그 결정은 하드웨어로 봉인된 감사 체인에 추가됩니다.
세션이 끝나면 게이트웨이는 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)

제공자 자동 감지 프로브 순서: azure-cvm -> tpm -> sev-snp -> tdx. detect()가 성공하는 첫 번째 제공자가 선택됩니다. 하드웨어 제공자가 감지되지 않으면 게이트웨이는 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

적용 모드

모드	동작	사용 사례
`enforcing`	정책 거부 시 HTTP 403을 반환하며 호출이 전달되지 않음	프로덕션
`advisory`	정책 거부가 로그에 기록되며 호출은 계속 진행됨	최초 배포, 정책 조정
`silent`	정책이 평가되지만 아무것도 기록되거나 차단되지 않음	기준선 설정

기본값은 enforcing입니다. advisory 모드를 사용하려면 cmcp-config.yaml에서 enforcement_mode: advisory를 설정하십시오.

구성

cmcp-config.yaml 전체 참조:

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

cmcp

인기