cMCP (Confidential MCP)

cMCP: Runtime Confidencial do MCP

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

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

Prévia para Desenvolvedores - lançado na Cúpula de Computação Confidencial, em 23 de junho de 2026. Pode haver mudanças que quebram compatibilidade antes da v1.0. Consulte STATUS.md para saber exatamente o que está disponível hoje versus o que está no roadmap.

cMCP (Runtime Confidencial do MCP) é a forma segura e confidencial de executar MCP: um gateway de código aberto que aplica a política de chamadas de ferramentas do 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 AgenTrust para isso.

Resumo - Aponte seu agente para o Gateway cMCP. Ele avalia cada chamada de ferramenta contra uma política Cedar dentro de um TEE, bloqueia ou edita 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 vazou?

---

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 de MCP apenas 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 sistema operacional que o administrador controla.
• Que a decisão de permitir/negar não foi alterada na memória. Uma CVE na cadeia de suprimentos no avaliador roda no mesmo espaço de endereço que o atacante.
• Que o log de auditoria reflete o que realmente aconteceu. Qualquer parte que detenha a chave de assinatura do software pode reconstruir uma cadeia de auditoria válida depois do fato.

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

Aplicação de política com atestação de hardware para chamadas de ferramentas do 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 de qualquer código rodar.

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 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 token de portador 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 de desenvolvimento sem token só pode fazer bind em um endereço de loopback, e um bind fora de 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 para o Gateway cMCP em vez de diretamente para os 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 roda 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 editar. 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 rodaram, 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

Provedor	Plataforma	Garantia	Notas
tpm	TPM 2.0 / vTPM (Azure, AWS, GCP Trusted Launch)	Média	Citação TPM local
sev-snp	AMD SEV-SNP (Azure DCasv5, AWS C6a Nitro)	Alta	AMD KDS
tdx	Intel TDX (Azure DCedsv5, GCP C3)	Alta	Intel PCS
gpu-cc (v0.2)	NVIDIA H100/H200/Blackwell (modo CC)	Alta	Serviço de Atestação Remota NVIDIA (NRAS)
opaque (opt-in)	Runtime Confidencial OPAQUE	n/d (ainda não implementado)	Placeholder: excluído da detecção automática; selecioná-lo explicitamente gera um erro de não implementado

Ordem de sondagem da detecção automática de provedores: 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 inicia apenas sob CMCP_DEV_MODE=1 (um fallback apenas por software, sem atestação) e, caso contrário, recusa-se a iniciar.

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

# OPAQUE Managed Runtime (opt-in only; not yet implemented)
# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml

---

Modos de aplicação

Modo	Comportamento	Caso de uso
enforcing	Negativas de política retornam HTTP 403; a chamada não é encaminhada	Produção
advisory	Negativas de política são registradas; a chamada prossegue	Primeira implantação, ajuste de política
silent	A política é avaliada, mas nada é registrado ou bloqueado	Linha de base

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

---

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           # 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

listen_addr: "127.0.0.1:8443"     # tokenless dev mode is loopback-only; set CMCP_BEARER_TOKEN before binding wider
max_response_size_bytes: 2097152    # 2 MB default
policy_reload_interval_seconds: 0   # >0 with a pinned CMCP_POLICY_HASH refuses to start, see docs/spec/policy-hot-reload.md

Variáveis de ambiente:

Variável	Efeito
CMCP_DEV_MODE=1	Usa provedor TEE apenas por software; sem necessidade de hardware
CMCP_BEARER_TOKEN	Exige este token de portador em todas as solicitações recebidas
OPAQUE_ATTESTATION_URL	Habilita atestação do Runtime Gerenciado OPAQUE (opt-in explícito)

---

Referência da CLI

Comando	Flags	Descrição
cmcp start	--config PATH (obrigatório)	Inicia o gateway
cmcp validate-config	--config PATH (obrigatório)	Valida cmcp-config.yaml sem iniciar
cmcp validate-bundle	--bundle-path PATH (obrigatório), --expected-hash sha256:<hex> (obrigatório)	Verifica um hash de pacote Cedar antes da implantação
cmcp verify	CLAIM_FILE (obrigatório); --policy-hash, --catalog-hash, --max-age, --trusted-key, --trusted-tpm-ca, --audit-bundle, --agent-manifest, --agent-manifest-trust-anchor	Verifica uma Reivindicação TRACE assinada (assinatura, esquema, atualidade, cadeia de auditoria, hashes fixados e âncoras de confiança)

---

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.

Campo	Descrição
trace.eat_profile	URI do perfil EAT: tag:agentrust-io.com,2026:trace-v0.2
trace.runtime	Plataforma TEE e medição de hardware registradas na inicialização do enclave
trace.policy.bundle_hash	SHA-256 do pacote Cedar carregado na inicialização; alterar qualquer arquivo de política muda este valor
trace.cnf.jwk	Chave pública Ed25519 vinculada à chave de assinatura do TEE
trace.tool_transcript	Visão por chamada derivada da cadeia de auditoria: hash (vincula-se ao topo da cadeia de auditoria), call_count e entries que preserva privacidade (nome da ferramenta, classe de dados, decisão)
gateway.audit_chain	Raiz e topo do log de auditoria com encadeamento por hash; verificável sem reproduzir entradas individuais
signature	Ed25519 sobre JSON canônico do corpo completo da reivindicação (RFC 8785)

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

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

Norma	Cobertura
OWASP Agentic AI Top 10	MCP10 (vazamento de dados via chamadas de ferramentas), MCP02 (ferramentas não autorizadas), MCP08 (governança comprovável), MCP04 (cadeia de suprimentos)
NIST SP 800-207	Ponto de decisão de política dentro do TEE; sem confiança implícita na identidade da carga de trabalho
EU AI Act Art. 12, 15	Registros de auditoria por decisão (Art. 12); controles de cibersegurança com suporte TEE (Art. 15)
DORA Art. 9	Cadeia de atestação; retenção de logs de auditoria via gateway.audit_chain
RATS/EAT RFC 9711	GatewayClaim é um EAT; o campo eat_profile identifica o perfil TRACE

---

Segurança

Ferramenta	O que verifica
ruff	Lint de estilo e importações em todo PR
bandit	Lint de segurança Python em todo PR
pip-audit	Varredura de vulnerabilidades de dependências em todo PR
mypy	Verificação estática de tipos em todo PR
CodeQL	SAST Python, consultas de segurança estendidas, semanal
OpenSSF Scorecard	Pontuação semanal, upload SARIF

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 resolve.

---

Documentação

Página	Descrição
docs/quickstart.md	Do zero à primeira Reivindicação TRACE em menos de 30 minutos
docs/configuration.md	Referência completa de configuração com todos os campos e padrões
docs/SPEC.md	Especificação do produto: taxonomia de problemas, arquitetura, matriz de cobertura
docs/spec/threat-model.md	Análise STRIDE, modelo de adversário, riscos residuais
docs/spec/cedar-policy.md	Referência da linguagem de políticas Cedar e esquema
docs/testing/benchmarks.md	Benchmarks de latência e throughput por provedor TEE

---

FAQ

O que é cMCP?

cMCP (Runtime Confidencial do MCP) é um gateway de código aberto que aplica a política de chamadas de ferramentas do 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 editar) e registra a chamada em uma cadeia de auditoria selada por hardware.

Como o cMCP é diferente da governança de MCP apenas por software?

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

Preciso de hardware especial para experimentar?

Não. Defina CMCP_DEV_MODE=1 para usar o provedor de TEE somente por software e execute o quickstart completo sem um TEE de hardware. Provedores de hardware (TPM, AMD SEV-SNP, Intel TDX, OPAQUE) são usados em produção.

O que é uma TRACE Claim?

Uma TRACE Claim (uma GatewayClaim) é um artefato assinado e atestado por hardware, produzido por sessão. Ela 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 valida com a biblioteca cmcp_verify sem confiar no operador.

Quais provedores de 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 o OPAQUE Confidential Runtime disponível como opção explícita. A ordem de detecção automática é: VM confidencial do Azure, 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 o cMCP em produção? Adicione sua organização a ADOPTERS.md.

---

Licença

MIT - veja LICENSE.