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 incompatíveis antes da v1.0. Consulte STATUS.md para saber exatamente o que já está disponível hoje versus o que está no roteiro.

cMCP (Confidential MCP Runtime) é um gateway de código aberto que verifica cada chamada de ferramenta feita por um agente de IA 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 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ê conseguiria provar que não vazou?

---

O problema

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

Nada disso prova que o próprio motor de políticas não foi comprometido. A governança de 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 pacote 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çamento 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íticas com atestação de hardware para chamadas de ferramentas MCP. Cada chamada de ferramenta é interceptada, avaliada em relação a um pacote de políticas Cedar e aplicada por um motor de políticas em execução dentro de um Trusted Execution Environment (TEE). Antes de atender a uma única chamada de ferramenta, o gateway mede o seu código instalado, o pacote de políticas e a configuração no relatório de atestação de hardware, e reatesta sempre que o pacote é recarregado.

Numa implementação de hardware, o cMCP Runtime processa os payloads das chamadas de ferramentas dentro do TEE. O que o host e o fornecedor de conectividade conseguem ler também depende da política de egress, e o servidor de ferramentas a montante é um componente separado fora do TEE. O modo software (CMCP_DEV_MODE) não proporciona isolamento de hardware. O 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 ignora deliberadamente o requisito de bearer token para que você possa testar as coisas rapidamente, e o bind padrão continua sendo 0.0.0.0:8443. Na 0.3.0, essa combinação criava um gateway sem autenticação 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 não-loopback exige CMCP_BEARER_TOKEN. Fixe listen_addr explicitamente e a configuração estará correta em ambas.

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 num laptop, sem hardware e sem registo: instale, escreva uma regra Cedar forbid, observe uma chamada de ferramenta a devolver 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, primeiro TRACE Claim e verificação (não é necessário TEE de hardware).

---

Como funciona