cMCP: Runtime MCP Confidencial

Atualizações da comunidade e destaques de contribuidores: AgenTrust no LinkedIn.

Aplique a política de ferramentas MCP dentro de um TEE, onde o agente que ela governa não consegue alcançá-la

Início Rápido · Arquitetura · Configuração · CLI · Changelog

Developer Preview - lançado no Confidential Computing Summit, 23 de junho de 2026. Pode ter mudanças significativas antes da v1.0. Consulte STATUS.md para saber exatamente o que é entregue hoje versus o que está no roadmap.

cMCP (Confidential MCP Runtime) é um gateway de código aberto que verifica cada chamada de ferramenta que um agente de IA faz contra regras que você escreve, e pode ser executado em hardware isolado que o agente não consegue adulterar. Agentes de IA usam ferramentas (bancos de dados, CRMs, e-mail, APIs internas) enviando requisições chamadas de chamadas de ferramenta, geralmente via MCP, o Model Context Protocol. O cMCP fica no caminho dessas chamadas, verifica cada uma contra suas regras (escritas na linguagem de política Cedar) e bloqueia as que as regras proíbem. Ele pode ser executado dentro de um TEE (trusted execution environment: hardware que mantém a memória de um programa isolada até mesmo do proprietário da máquina), onde o agente que ele governa não consegue alcançá-lo. Cada sessão termina com um recibo assinado, um TRACE Claim, que qualquer pessoa pode verificar sem confiar em quem executou o gateway. O recibo é respaldado por um relatório de hardware quando o gateway é executado em um TEE, e é apenas assinado (sem prova de hardware) no modo software. Novo nesses termos? Consulte os termos, em linguagem simples.

TL;DR: Aponte seu agente para o cMCP Gateway. Ele verifica cada chamada de ferramenta contra suas regras Cedar, bloqueia ou redige (oculta) o que as regras negam, e fornece um recibo assinado que mostra se alguém o alterou. Execute pip install cmcp-runtime e comece no modo software em qualquer computador; nenhum hardware especial necessário.

Seu agente chama Snowflake, Salesforce, uma dúzia de APIs. O que o impede de vazar os dados de um cliente em uma dessas chamadas? Se um regulador perguntar, você poderia provar que não vazou?

O problema

Um agente chama uma ferramenta. O motor de política diz permitir. A chamada de ferramenta passa.

Nada disso prova que o próprio motor de política não foi comprometido. A governança MCP apenas em software não pode garantir:

A política Cedar em disco é a que foi executada. Um administrador mal-intencionado pode trocar o bundle após a aprovação; a verificação de hash é executada dentro do mesmo SO que o administrador controla.
A decisão de permitir/negar não foi invertida na memória. Uma CVE de cadeia de suprimentos no avaliador é executada no mesmo espaço de endereço que o atacante.
O log de auditoria reflete o que realmente aconteceu. Qualquer parte que detenha a chave de assinatura de software pode reconstruir uma cadeia de auditoria válida após o fato.

O plano de controle que governa as chamadas de ferramenta deve ser executado onde não possa ser alcançado pelo processo que ele governa.

Aplicação de política com atestação de hardware para chamadas de ferramenta MCP. Cada chamada de ferramenta é interceptada, avaliada contra um bundle de política Cedar e aplicada por um motor de política executado dentro de um Trusted Execution Environment (TEE). Antes de atender uma única chamada de ferramenta, o gateway mede seu código instalado, bundle de política e configuração no relatório de atestação de hardware, e reatesta sempre que o bundle é recarregado.

Em uma implantação de hardware, o cMCP Runtime processa os payloads de chamadas de ferramenta dentro do TEE. O que o host e o provedor de conectividade podem ler também depende da política de egresso, e o servidor de ferramentas upstream é um componente separado fora do TEE. O modo software (CMCP_DEV_MODE) não fornece isolamento de hardware. LIMITATIONS.md lista o que o cMCP não impede.

Início Rápido

pip install cmcp-runtime

Crie 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 não é opcional aqui. CMCP_DEV_MODE=1 deliberadamente ignora o requisito de bearer token para que você possa testar as coisas rapidamente, e o bind padrão ainda é 0.0.0.0:8443. Na 0.3.0 essa combinação levantava um gateway não autenticado em todas as interfaces da sua máquina. A partir da 0.4.0 isso é recusado: o modo dev sem token só pode fazer bind em um endereço de loopback, e um bind não-loopback exige CMCP_BEARER_TOKEN. Fixe listen_addr explicitamente e a configuração estará correta em ambos os casos.

Inicie o gateway:

CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml

Faça uma chamada de ferramenta:

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"}}}'

Prefere uma versão guiada? agentrust-io.com/quickstart percorre o mesmo caminho em cerca de dez minutos em um laptop, sem hardware e sem cadastro: instale, escreva uma regra Cedar forbid, veja uma chamada de ferramenta retornar 403 POLICY_DENY antes de chegar a um upstream, e então verifique o recibo assinado.

Consulte docs/quickstart.md para o passo a passo completo: política Cedar, catálogo de ferramentas, primeiro TRACE Claim e verificação (sem necessidade de TEE de hardware).

cmcp v0.4.0