cMCP: Runtime MCP Confidencial

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

Pré-visualização para Desenvolvedores - lançado na Confidential Computing Summit, 23 de junho de 2026. Pode haver mudanças disruptivas antes da v1.0. Consulte STATUS.md para saber exatamente o que está disponível hoje versus o que está no roadmap.

cMCP (Runtime MCP Confidencial) é a forma segura e confidencial de executar MCP: um gateway de código aberto que aplica a política de chamadas de ferramentas MCP dentro de um Ambiente de Execução Confiável (TEE) de hardware. Cada chamada de ferramenta é interceptada, avaliada contra um pacote de políticas Cedar e aplicada onde o processo que ela governa não consegue alcançá-la. Cada sessão produz uma Reivindicação TRACE assinada que um verificador confere sem confiar no operador, com atestação de hardware quando o gateway roda em um TEE e apenas assinada no modo de software. Se você procura uma versão segura do MCP, este é o runtime da AgenTrust para isso.

TL;DR - Aponte seu agente para o Gateway cMCP. Ele avalia cada chamada de ferramenta contra uma política Cedar dentro de um TEE, bloqueia ou redige o que a política nega e emite uma Reivindicação TRACE à prova de adulteração como prova. Execute pip install cmcp-runtime e comece no modo de software sem necessidade de hardware.

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

O problema

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

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

• Que a política Cedar no disco é a que foi executada. Um administrador mal-intencionado pode trocar o pacote após a aprovação; a verificação de hash roda dentro do mesmo SO que o administrador controla.
• Que a decisão de permitir/negar não foi alterada em memória. Uma CVE na cadeia de suprimentos no avaliador roda no mesmo espaço de endereçamento que o atacante.
• Que 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 posteriormente.

O plano de controle que governa as chamadas de ferramentas deve rodar onde não pode ser alcançado pelo processo que governa.

Aplicação de política com atestação de hardware para chamadas de ferramentas MCP. Cada chamada de ferramenta é interceptada, avaliada contra um pacote de políticas Cedar e aplicada por um mecanismo de política rodando dentro de um Ambiente de Execução Confiável (TEE). O hash do pacote de políticas é medido no relatório de atestação de hardware antes que qualquer código seja executado.

Diferente de soluções de conectividade baseadas em túnel, o Runtime cMCP processa os payloads das chamadas de ferramentas dentro do TEE. O provedor de conectividade vê texto cifrado, não texto puro. A única coisa que sai do enclave é a reivindicação TRACE assinada.

Início Rápido

pip install cmcp-runtime

Crie cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory facilita o ajuste inicial; o padrão é `enforcing`
listen_addr: "127.0.0.1:8443"  # fixe loopback: o modo dev roda sem token bearer
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

listen_addr não é opcional aqui. CMCP_DEV_MODE=1 deliberadamente ignora o requisito de token bearer para que você possa testar rapidamente, e o bind padrão ainda é 0.0.0.0:8443. Na versão 0.3.0 essa combinação criava 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 endereço 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, em seguida, verifique o recibo assinado.

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

Como funciona

1. O agente envia cada chamada de ferramenta ao Gateway cMCP em vez de diretamente aos servidores MCP.
2. Na inicialização, o gateway mede o hash do pacote de políticas Cedar no relatório de atestação de hardware. Nenhum código é executado antes dessa medição.
3. Cada chamada de ferramenta recebida é avaliada pelo mecanismo de políticas Cedar rodando dentro do TEE. O resultado é permitir, negar ou redigir. A chamada e sua decisão são anexadas à cadeia de auditoria selada por hardware.
4. Ao final da sessão, o gateway produz uma Reivindicação TRACE: um artefato assinado e atestado por hardware que registra quais ferramentas foram executadas, qual política decidiu cada chamada e a cadeia de auditoria completa. Um verificador confere isso sem confiar no operador.

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)

Provedores de hardware

Ordem de sondagem da detecção automática de provedor: azure-cvm -> tpm -> sev-snp -> tdx. O primeiro provedor cujo detect() for bem-sucedido é selecionado. opaque é um placeholder ainda não implementado: é excluído da detecção automática, e selecioná-lo explicitamente gera ATTESTATION_PROVIDER_NOT_IMPLEMENTED em vez de falhar silenciosamente. Se nenhum provedor de hardware for detectado, o gateway só inicia sob CMCP_DEV_MODE=1 (um fallback somente por software sem atestação) e, caso contrário, recusa-se a iniciar.

from cmcp_runtime.config import TEEProvider

# Detecção automática (padrão)
# attestation.provider: auto  ->  azure-cvm -> tpm -> sev-snp -> tdx
# (somente por software é usado apenas sob CMCP_DEV_MODE=1)

# Seleção explícita de hardware
# attestation.provider: sev-snp

# OPAQUE Managed Runtime (somente opt-in; ainda não implementado)
# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml

Modos de aplicação

O padrão é enforcing. Defina enforcement_mode: advisory em cmcp-config.yaml para usar o modo advisory.

Configuração

Referência completa de cmcp-config.yaml:

attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | opaque | software-only
  enforcement_mode: enforcing       # enforcing | advisory | silent
  validity_seconds: 86400           # janela de frescor da atestação (padrão: 24 horas)
  staleness_policy: fail_closed     # fail_closed | warn_only
  expected_measurement: ~           # fixe um PCR/measurement específico (opcional)

policy_bundle_path: policies/       # diretório contendo arquivos .cedar e manifest.json
catalog_path: catalog.json          # catálogo de ferramentas aprovadas

listen_addr: "127.0.0.1:8443"     # o modo dev sem token é somente loopback; defina CMCP_BEARER_TOKEN antes de fazer bind em um escopo maior
max_response_size_bytes: 2097152    # padrão de 2 MB
policy_reload_interval_seconds: 0   # >0 com CMCP_POLICY_HASH fixado recusa iniciar, consulte docs/spec/policy-hot-reload.md

Variáveis de ambiente:

Referência da CLI

Reivindicações TRACE

Uma GatewayClaim é a unidade de prova entregue a um auditor, regulador ou verificador downstream. É produzida por sessão (ou por chamada, configurável) e assinada com uma chave que nunca sai do TEE.

(Esta tabela é um resumo dos campos mais utilizados.)

A verificação com a biblioteca cmcp_verify não exige confiar no operador. O verificador confere a assinatura contra a chave vinculada ao TEE, o hash do pacote de políticas contra o valor aprovado e a cadeia de auditoria quanto à consistência interna.

O esquema normativo é schemas/trace-claim.schema.json, e docs/quickstart.md mostra um exemplo completo. Consulte docs/spec/verification-library.md e a especificação TRACE para o protocolo completo de verificação.

Alinhamento com normas

Segurança

Consulte SECURITY.md para relato de vulnerabilidades e SLAs de resposta. Consulte LIMITATIONS.md para limites explícitos de escopo, incluindo riscos residuais de captura de payload APM, injeção de configuração em runtime e cadeia de suprimentos P4.1 (typosquat) que a Fase 1 não elimina.

Documentação

FAQ

O que é cMCP?

cMCP (Runtime MCP Confidencial) é um gateway de código aberto que aplica a política de chamadas de ferramentas MCP dentro de um Ambiente de Execução Confiável de hardware. Ele intercepta cada chamada de ferramenta, avalia contra um pacote de políticas Cedar, aplica a decisão (permitir, negar ou redigir) e registra a chamada em uma cadeia de auditoria selada por hardware.

Como o cMCP difere da governança MCP somente por software?

A governança somente por software roda o mecanismo de política no mesmo SO que um operador ou uma CVE na cadeia de suprimentos pode alcançar, portanto não pode provar que a política executada era a aprovada ou que a decisão não foi alterada em memória. O cMCP roda o mecanismo de política dentro de um TEE e mede o hash do pacote Cedar no relatório de atestação de hardware antes que qualquer código seja executado, de modo que o plano de controle não pode ser alcançado pelo processo que governa.

Preciso de hardware especial para testar?

Não. Defina CMCP_DEV_MODE=1 para usar o provedor TEE somente por software e execute o início rápido completo sem um TEE de hardware. Os provedores de hardware (TPM, AMD SEV-SNP, Intel TDX, OPAQUE) são usados em produção.

O que é uma Reivindicação TRACE?

Uma Reivindicação TRACE (uma GatewayClaim) é um artefato assinado e atestado por hardware produzido por sessão. Registra quais ferramentas foram executadas, qual política decidiu cada chamada, o hash do pacote Cedar e a cadeia de auditoria, e é assinada com uma chave Ed25519 que nunca sai do TEE. Um verificador a confere com a biblioteca cmcp_verify sem confiar no operador.

Quais provedores TEE são suportados?

TPM 2.0 / vTPM, AMD SEV-SNP e Intel TDX, com computação confidencial em GPU NVIDIA planejada para a v0.2 e OPAQUE Confidential Runtime disponível como opt-in explícito. A ordem de detecção automática é Azure confidential VM, depois TPM 2.0 / vTPM, depois AMD SEV-SNP, depois Intel TDX; o provedor somente por software é usado apenas sob CMCP_DEV_MODE=1.

Sob qual licença o cMCP está?

MIT.

Contribuindo

CONTRIBUTING.md · GOVERNANCE.md · Discussões

Junte-se à comunidade no Discord.

Usando cMCP em produção? Adicione sua organização ao ADOPTERS.md.

Licença

MIT - consulte LICENSE.