cMCP: Конфиденциальная среда выполнения MCP

Принудительное применение политики инструментов MCP внутри TEE, куда управляемый агент не может добраться

Быстрый старт · Архитектура · Конфигурация · CLI · Журнал изменений

Предварительная версия для разработчиков — запущена на саммите Confidential Computing Summit, 23 июня 2026 года. До версии v1.0 возможны критические изменения. См. STATUS.md, чтобы узнать, что именно доступно сегодня, а что находится в дорожной карте.

cMCP (Confidential MCP Runtime) — это безопасный и конфиденциальный способ запуска MCP: шлюз с открытым исходным кодом, который обеспечивает принудительное применение политики вызовов инструментов MCP внутри аппаратной Trusted Execution Environment (TEE). Каждый вызов инструмента перехватывается, оценивается на соответствие пакету политик Cedar и применяется там, куда управляемый процесс не может добраться. Каждая сессия создаёт подписанное TRACE Claim, которое проверяющий может проверить, не доверяя оператору; при работе шлюза в TEE оно подтверждается аппаратно, а в программном режиме — только подписью. Если вы ищете безопасную версию MCP, это среда выполнения AgenTrust для неё.

Кратко — направьте своего агента на cMCP Gateway. Он оценивает каждый вызов инструмента на соответствие политике Cedar внутри TEE, блокирует или редактирует то, что политика запрещает, и выдаёт защищённое от подделки TRACE Claim в качестве доказательства. Выполните pip install cmcp-runtime и запустите в программном режиме без какого-либо аппаратного обеспечения.

Ваш агент вызывает Snowflake, Salesforce, десятки API. Что мешает ему утечь данные клиента в одном из этих вызовов? Если регулятор спросит, сможете ли вы доказать, что этого не произошло?

Проблема

Агент вызывает инструмент. Механизм политик говорит «разрешить». Вызов инструмента проходит.

Ничто из этого не доказывает, что сам механизм политик не был скомпрометирован. Только программное управление MCP не может гарантировать:

• Что политика Cedar на диске — это именно та, что выполнялась. Недобросовестный администратор может подменить пакет после утверждения; проверка хеша выполняется в той же ОС, которой управляет администратор.
• Что решение «разрешить/запретить» не было изменено в памяти. Уязвимость в цепочке поставок в оценщике работает в том же адресном пространстве, что и атакующий.
• Что журнал аудита отражает то, что произошло на самом деле. Любая сторона, владеющая ключом подписи ПО, может восстановить корректную цепочку аудита задним числом.

Плоскость управления, которая управляет вызовами инструментов, должна работать там, куда управляемый ею процесс не может добраться.

Принудительное применение политик с аппаратным подтверждением для вызовов инструментов MCP. Каждый вызов инструмента перехватывается, оценивается на соответствие пакету политик Cedar и применяется механизмом политик, работающим внутри Trusted Execution Environment (TEE). Хеш пакета политик измеряется в отчёте об аппаратном подтверждении до запуска любого кода.

В отличие от решений на основе туннельного подключения, cMCP Runtime обрабатывает полезные данные вызовов инструментов внутри TEE. Поставщик подключения видит шифротекст, а не открытый текст. Единственное, что покидает анклав, — это подписанное TRACE claim.

Быстрый старт

pip install cmcp-runtime

Создайте cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory упрощает первоначальную настройку; по умолчанию — `enforcing`
listen_addr: "127.0.0.1:8443"  # привязка к loopback: dev-режим работает без bearer-токена
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 это отклоняется: безтокенный dev-режим может привязываться только к loopback-адресу, а привязка не к loopback требует 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 проведёт вас по тому же пути примерно за десять минут на ноутбуке, без аппаратного обеспечения и без регистрации: установите, напишите одно правило Cedar forbid, наблюдайте, как вызов инструмента возвращает 403 POLICY_DENY до того, как достигнет вышестоящего сервера, а затем проверьте подписанную квитанцию.

Полное пошаговое руководство см. в docs/quickstart.md: политика Cedar, каталог инструментов, первое TRACE Claim и проверка (аппаратный TEE не требуется).

Как это работает

1. Агент отправляет каждый вызов инструмента на cMCP Gateway вместо прямого обращения к серверам MCP.
2. При запуске шлюз измеряет хеш пакета политик Cedar в отчёт об аппаратном подтверждении. Никакой код не выполняется до этого измерения.
3. Каждый входящий вызов инструмента оценивается механизмом политик Cedar, работающим внутри TEE. Результат: разрешить, запретить или отредактировать. Вызов и его решение добавляются в аппаратно-опечатанную цепочку аудита.
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)

Аппаратные провайдеры

Порядок автодетекта провайдеров: azure-cvm -> tpm -> sev-snp -> tdx. Выбирается первый провайдер, чей detect() завершился успешно. opaque — это ещё не реализованная заглушка: он исключён из автодетекта, а явный выбор вызывает ATTESTATION_PROVIDER_NOT_IMPLEMENTED, а не молчаливый переход к другому варианту. Если аппаратный провайдер не обнаружен, шлюз запускается только при CMCP_DEV_MODE=1 (неподтверждённый программный запасной вариант), в противном случае он отказывается запускаться.

from cmcp_runtime.config import TEEProvider

# Автодетект (по умолчанию)
# attestation.provider: auto  ->  azure-cvm -> tpm -> sev-snp -> tdx
# (только программный режим используется только при CMCP_DEV_MODE=1)

# Явный выбор аппаратного обеспечения
# attestation.provider: sev-snp

# OPAQUE Managed Runtime (только по запросу; ещё не реализовано)
# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml

Режимы принудительного применения

По умолчанию — enforcing. Установите enforcement_mode: advisory в cmcp-config.yaml, чтобы использовать режим advisory.

Конфигурация

Полный справочник cmcp-config.yaml:

attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | opaque | software-only
  enforcement_mode: enforcing       # enforcing | advisory | silent
  validity_seconds: 86400           # окно свежести подтверждения (по умолчанию: 24 часа)
  staleness_policy: fail_closed     # fail_closed | warn_only
  expected_measurement: ~           # закрепить конкретный PCR/измерение (необязательно)

policy_bundle_path: policies/       # каталог, содержащий файлы .cedar и manifest.json
catalog_path: catalog.json          # каталог одобренных инструментов

listen_addr: "127.0.0.1:8443"     # безтокенный dev-режим работает только с loopback; установите CMCP_BEARER_TOKEN перед привязкой к более широкому адресу
max_response_size_bytes: 2097152    # по умолчанию 2 МБ
policy_reload_interval_seconds: 0   # значение >0 с закреплённым CMCP_POLICY_HASH отказывается запускаться, см. docs/spec/policy-hot-reload.md

Переменные окружения:

Справочник CLI

TRACE Claims

GatewayClaim — это единица доказательства, передаваемая аудитору, регулятору или нижестоящему проверяющему. Она создаётся для каждой сессии (или для каждого вызова — настраивается) и подписывается ключом, который никогда не покидает TEE.

(Эта таблица — сводка наиболее часто используемых полей.)

Проверка с помощью библиотеки cmcp_verify не требует доверия к оператору. Проверяющий сверяет подпись с ключом, привязанным к TEE, хеш пакета политик — с утверждённым значением, а цепочку аудита — на внутреннюю согласованность.

Нормативная схема — schemas/trace-claim.schema.json, а в docs/quickstart.md показан полный пример. Полный протокол проверки см. в docs/spec/verification-library.md и в спецификации TRACE.

Соответствие стандартам

Безопасность

См. SECURITY.md о сообщении об уязвимостях и SLA реагирования. См. LIMITATIONS.md о явных границах области применения, включая остаточные риски захвата полезной нагрузки APM, инъекции конфигурации во время выполнения и риска цепочки поставок P4.1 (typosquat), которые Фаза 1 не закрывает.

Документация

FAQ

Что такое cMCP?

cMCP (Confidential MCP Runtime) — это шлюз с открытым исходным кодом, который обеспечивает принудительное применение политики вызовов инструментов MCP внутри аппаратной Trusted Execution Environment. Он перехватывает каждый вызов инструмента, оценивает его на соответствие пакету политик Cedar, применяет решение (разрешить, запретить или отредактировать) и записывает вызов в аппаратно-опечатанную цепочку аудита.

Чем cMCP отличается от только программного управления MCP?

Только программное управление запускает механизм политик в той же ОС, до которой может добраться оператор или уязвимость в цепочке поставок, поэтому оно не может доказать, что выполнялась именно утверждённая политика или что решение не было изменено в памяти. cMCP запускает механизм политик внутри TEE и измеряет хеш пакета Cedar в отчёте об аппаратном подтверждении до запуска любого кода, поэтому плоскость управления недостижима для управляемого ею процесса.

Нужно ли мне специальное аппаратное обеспечение, чтобы попробовать?

Нет. Установите CMCP_DEV_MODE=1, чтобы использовать только программный TEE-провайдер и пройти полный быстрый старт без аппаратного TEE. Аппаратные провайдеры (TPM, AMD SEV-SNP, Intel TDX, OPAQUE) используются в производстве.

Что такое TRACE Claim?

TRACE Claim (или GatewayClaim) — это подписанный, аппаратно подтверждённый артефакт, создаваемый для каждой сессии. Он фиксирует, какие инструменты выполнялись, какая политика решала по каждому вызову, хеш пакета Cedar и цепочку аудита, и подписывается ключом Ed25519, который никогда не покидает TEE. Проверяющий проверяет его с помощью библиотеки cmcp_verify, не доверяя оператору.

Какие TEE-провайдеры поддерживаются?

TPM 2.0 / vTPM, AMD SEV-SNP и Intel TDX, с конфиденциальными вычислениями на GPU NVIDIA, запланированными на v0.2, и OPAQUE Confidential Runtime, доступным по явному согласию. Порядок автодетекта: конфиденциальная виртуальная машина Azure, затем TPM 2.0 / vTPM, затем AMD SEV-SNP, затем Intel TDX; только программный провайдер используется только при CMCP_DEV_MODE=1.

Под какой лицензией распространяется cMCP?

MIT.

Участие в разработке

CONTRIBUTING.md · GOVERNANCE.md · Обсуждения

Присоединяйтесь к сообществу на Discord.

Используете cMCP в производстве? Добавьте свою организацию в ADOPTERS.md.

Лицензия

MIT — см. LICENSE.