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

Обновления сообщества и новости участников: AgenTrust в LinkedIn.

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

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

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

cMCP (Confidential MCP Runtime) — это открытый шлюз, который проверяет каждый вызов инструмента, совершаемый ИИ-агентом, на соответствие написанным вами правилам и может работать на изолированном оборудовании, которое агент не может изменить. ИИ-агенты используют инструменты (базы данных, CRM, электронную почту, внутренние API), отправляя запросы, называемые вызовами инструментов, обычно через MCP — Model Context Protocol. cMCP находится на пути этих вызовов, проверяет каждый из них на соответствие вашим правилам (написанным на языке политик Cedar) и блокирует те, которые правила запрещают. Он может работать внутри TEE (trusted execution environment — доверенная среда выполнения: аппаратное обеспечение, которое держит память программы изолированной даже от владельца машины), где управляемый им агент не может до него добраться. Каждая сессия завершается подписанной квитанцией — TRACE Claim, — которую любой может проверить, не доверяя тому, кто запускал шлюз. Квитанция подтверждается аппаратным отчётом, когда шлюз работает в TEE, и только подписывается (без аппаратного подтверждения) в программном режиме. Впервые сталкиваетесь с этими терминами? См. термины простым языком.

Кратко: Направьте своего агента на cMCP Gateway. Он проверяет каждый вызов инструмента на соответствие вашим правилам Cedar, блокирует или редактирует (вымарывает) то, что правила запрещают, и выдаёт вам подписанную квитанцию, показывающую, изменял ли её кто-либо. Выполните pip install cmcp-runtime и запустите в программном режиме на любом компьютере; специальное оборудование не требуется.

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

Проблема

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

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

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

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

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

При аппаратном развёртывании 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 это запрещено: режим разработки без токена может привязываться только к 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 не требуется).

cmcp v0.4.0