cMCP: Runtime MCP Confidenziale

Applica le policy degli strumenti MCP all'interno di un TEE, dove l'agente che governa non può raggiungerlo

Avvio rapido · Architettura · Configurazione · CLI · Changelog

Anteprima per sviluppatori - lanciata al Confidential Computing Summit, 23 giugno 2026. Potrebbero esserci modifiche sostanziali prima della v1.0. Consulta STATUS.md per sapere esattamente cosa è disponibile oggi rispetto alla roadmap.

cMCP (Runtime MCP Confidenziale) è il modo sicuro e confidenziale di eseguire MCP: un gateway open-source che applica le policy delle chiamate agli strumenti MCP all'interno di un Trusted Execution Environment (TEE) hardware. Ogni chiamata a uno strumento viene intercettata, valutata rispetto a un bundle di policy Cedar e applicata dove il processo che governa non può raggiungerla. Ogni sessione produce una TRACE Claim firmata che un verificatore controlla senza fidarsi dell'operatore, attestata a livello hardware quando il gateway gira in un TEE e firmata soltanto in modalità software. Se stai cercando una versione sicura di MCP, questo è il runtime AgenTrust per essa.

TL;DR - Punta il tuo agente al Gateway cMCP. Valuta ogni chiamata a uno strumento rispetto a una policy Cedar all'interno di un TEE, blocca o oscura ciò che la policy nega ed emette una TRACE Claim a prova di manomissione come prova. Esegui pip install cmcp-runtime e avvia in modalità software senza richiedere hardware.

Il tuo agente chiama Snowflake, Salesforce, una dozzina di API. Cosa gli impedisce di far trapelare i dati di un cliente in una di queste chiamate? Se un regolatore lo chiedesse, potresti dimostrare che non è successo?

Il problema

Un agente chiama uno strumento. Il motore delle policy dice consenti. La chiamata allo strumento passa.

Nessuno di questi passaggi dimostra che il motore delle policy stesso non sia stato compromesso. La governance MCP solo software non può garantire:

• Che la policy Cedar su disco sia quella effettivamente eseguita. Un amministratore malintenzionato può sostituire il bundle dopo l'approvazione; il controllo dell'hash viene eseguito nello stesso sistema operativo controllato dall'amministratore.
• Che la decisione consenti/nega non sia stata alterata in memoria. Una CVE nella supply chain dell'evaluator gira nello stesso spazio di indirizzi dell'attaccante.
• Che il log di audit rifletta ciò che è realmente accaduto. Qualsiasi soggetto in possesso della chiave di firma software può ricostruire una catena di audit valida a posteriori.

Il piano di controllo che governa le chiamate agli strumenti deve girare dove non può essere raggiunto dal processo che governa.

Applicazione delle policy attestata a livello hardware per le chiamate agli strumenti MCP. Ogni chiamata a uno strumento viene intercettata, valutata rispetto a un bundle di policy Cedar e applicata da un motore di policy che gira all'interno di un Trusted Execution Environment (TEE). L'hash del bundle di policy viene misurato nel report di attestazione hardware prima che venga eseguito qualsiasi codice.

A differenza delle soluzioni di connettività basate su tunnel, il Runtime cMCP elabora i payload delle chiamate agli strumenti all'interno del TEE. Il provider di connettività vede testo cifrato, non testo in chiaro. L'unica cosa che lascia l'enclave è la TRACE claim firmata.

Avvio rapido

pip install cmcp-runtime

Crea cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory facilita la messa a punto iniziale; il default è `enforcing`
listen_addr: "127.0.0.1:8443"  # fissa il loopback: la modalità dev gira senza bearer token
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

listen_addr qui non è facoltativo. CMCP_DEV_MODE=1 salta deliberatamente il requisito del bearer token così puoi provare rapidamente le cose, e il bind predefinito è comunque 0.0.0.0:8443. Sulla 0.3.0 quella combinazione metteva in piedi un gateway non autenticato su ogni interfaccia della tua macchina. Dalla 0.4.0 viene rifiutata: la modalità dev senza token può fare bind solo su un indirizzo loopback, e un bind non-loopback richiede CMCP_BEARER_TOKEN. Fissa listen_addr esplicitamente e la configurazione è corretta in entrambi i casi.

Avvia il gateway:

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

Effettua una chiamata a uno strumento:

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

Preferisci una versione guidata? agentrust-io.com/quickstart percorre lo stesso percorso in circa dieci minuti su un laptop, senza hardware e senza registrazione: installa, scrivi una regola Cedar forbid, osserva una chiamata a uno strumento restituire 403 POLICY_DENY prima che raggiunga un upstream, poi verifica la ricevuta firmata.

Consulta docs/quickstart.md per la procedura completa: policy Cedar, catalogo degli strumenti, prima TRACE Claim e verifica (nessun TEE hardware richiesto).

Come funziona

1. L'agente invia ogni chiamata a uno strumento al Gateway cMCP invece che direttamente ai server MCP.
2. All'avvio il gateway misura l'hash del bundle di policy Cedar nel report di attestazione hardware. Nessun codice viene eseguito prima di questa misurazione.
3. Ogni chiamata in arrivo viene valutata dal motore di policy Cedar che gira all'interno del TEE. Il risultato è consenti, nega o oscura. La chiamata e la sua decisione vengono aggiunte alla catena di audit sigillata a livello hardware.
4. Al termine della sessione il gateway produce una TRACE Claim: un artefatto firmato e attestato a livello hardware che registra quali strumenti sono stati eseguiti, quale policy ha deciso ogni chiamata e l'intera catena di audit. Un verificatore la controlla senza fidarsi dell'operatore.

Agent -> cMCP Runtime -> Motore di policy Cedar (TEE) -> Strumento
                     |
               GatewayClaim (Profilo TRACE)
               +-- trace.eat_profile
               +-- trace.runtime.platform + measurement
               +-- trace.policy.bundle_hash
               +-- trace.cnf.jwk  (chiave di conferma Ed25519)
               +-- gateway.audit_chain (root/tip/lunghezza)
               +-- signature (Ed25519 su JSON canonico)

Provider hardware

Ordine di rilevamento automatico del provider: azure-cvm -> tpm -> sev-snp -> tdx. Viene selezionato il primo provider il cui detect() ha successo. opaque è un segnaposto non ancora implementato: è escluso dall'auto-rilevamento e selezionarlo esplicitamente solleva ATTESTATION_PROVIDER_NOT_IMPLEMENTED invece di ripiegare silenziosamente. Se non viene rilevato alcun provider hardware, il gateway si avvia solo con CMCP_DEV_MODE=1 (un fallback solo software non attestato) e altrimenti rifiuta di avviarsi.

from cmcp_runtime.config import TEEProvider

# Auto-rilevamento (default)
# attestation.provider: auto  ->  azure-cvm -> tpm -> sev-snp -> tdx
# (solo software viene usato solo con CMCP_DEV_MODE=1)

# Selezione hardware esplicita
# attestation.provider: sev-snp

# OPAQUE Managed Runtime (solo opt-in; non ancora implementato)
# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml

Modalità di applicazione

Il default è enforcing. Imposta enforcement_mode: advisory in cmcp-config.yaml per usare la modalità advisory.

Configurazione

Riferimento completo di cmcp-config.yaml:

attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | opaque | software-only
  enforcement_mode: enforcing       # enforcing | advisory | silent
  validity_seconds: 86400           # finestra di freschezza dell'attestazione (default: 24 ore)
  staleness_policy: fail_closed     # fail_closed | warn_only
  expected_measurement: ~           # fissa uno specifico PCR/measurement (facoltativo)

policy_bundle_path: policies/       # directory contenente file .cedar e manifest.json
catalog_path: catalog.json          # catalogo degli strumenti approvati

listen_addr: "127.0.0.1:8443"     # la modalità dev senza token è solo-loopback; imposta CMCP_BEARER_TOKEN prima di fare bind su una rete più ampia
max_response_size_bytes: 2097152    # default 2 MB
policy_reload_interval_seconds: 0   # >0 con CMCP_POLICY_HASH fissato rifiuta l'avvio, vedi docs/spec/policy-hot-reload.md

Variabili d'ambiente:

Riferimento CLI

TRACE Claims

Una GatewayClaim è l'unità di prova consegnata a un revisore, a un regolatore o a un verificatore a valle. Viene prodotta per sessione (o per chiamata, configurabile) e firmata con una chiave che non lascia mai il TEE.

(Questa tabella è un riepilogo dei campi più utilizzati.)

La verifica con la libreria cmcp_verify non richiede di fidarsi dell'operatore. Il verificatore controlla la firma rispetto alla chiave legata al TEE, l'hash del bundle di policy rispetto al valore approvato e la catena di audit per la coerenza interna.

Lo schema normativo è schemas/trace-claim.schema.json e docs/quickstart.md mostra un esempio completo. Consulta docs/spec/verification-library.md e la specifica TRACE per il protocollo di verifica completo.

Allineamento agli standard

Sicurezza

Consulta SECURITY.md per la segnalazione delle vulnerabilità e gli SLA di risposta. Consulta LIMITATIONS.md per i confini di ambito espliciti, inclusi i rischi residui per la cattura dei payload APM, l'iniezione di configurazione runtime e la supply chain P4.1 (typosquat) che la Fase 1 non chiude.

Documentazione

FAQ

Cos'è cMCP?

cMCP (Runtime MCP Confidenziale) è un gateway open-source che applica le policy delle chiamate agli strumenti MCP all'interno di un Trusted Execution Environment hardware. Intercetta ogni chiamata a uno strumento, la valuta rispetto a un bundle di policy Cedar, applica la decisione (consenti, nega o oscura) e registra la chiamata in una catena di audit sigillata a livello hardware.

In cosa cMCP è diverso dalla governance MCP solo software?

La governance solo software esegue il motore delle policy nello stesso sistema operativo che un operatore o una CVE della supply chain può raggiungere, quindi non può dimostrare che la policy eseguita fosse quella approvata o che la decisione non sia stata alterata in memoria. cMCP esegue il motore delle policy all'interno di un TEE e misura l'hash del bundle Cedar nel report di attestazione hardware prima che venga eseguito qualsiasi codice, così il piano di controllo non può essere raggiunto dal processo che governa.

Mi serve hardware speciale per provarlo?

No. Imposta CMCP_DEV_MODE=1 per usare il provider TEE solo software ed eseguire l'intero avvio rapido senza un TEE hardware. I provider hardware (TPM, AMD SEV-SNP, Intel TDX, OPAQUE) vengono usati in produzione.

Cos'è una TRACE Claim?

Una TRACE Claim (una GatewayClaim) è un artefatto firmato e attestato a livello hardware prodotto per sessione. Registra quali strumenti sono stati eseguiti, quale policy ha deciso ogni chiamata, l'hash del bundle Cedar e la catena di audit, ed è firmata con una chiave Ed25519 che non lascia mai il TEE. Un verificatore la controlla con la libreria cmcp_verify senza fidarsi dell'operatore.

Quali provider TEE sono supportati?

TPM 2.0 / vTPM, AMD SEV-SNP e Intel TDX, con il confidential computing GPU NVIDIA previsto per la v0.2 e OPAQUE Confidential Runtime disponibile come opt-in esplicito. L'ordine di auto-rilevamento è Azure confidential VM, poi TPM 2.0 / vTPM, poi AMD SEV-SNP, poi Intel TDX; il provider solo software viene usato solo con CMCP_DEV_MODE=1.

Sotto quale licenza è cMCP?

MIT.

Contribuire

CONTRIBUTING.md · GOVERNANCE.md · Discussioni

Unisciti alla community su Discord.

Usi cMCP in produzione? Aggiungi la tua organizzazione a ADOPTERS.md.

Licenza

MIT - vedi LICENSE.