cMCP: Runtime MCP riservato

Aggiornamenti della community e contributi in evidenza: AgenTrust su LinkedIn.

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

Avvio rapido · Architettura · Configurazione · CLI · Changelog

Developer Preview - presentato al Confidential Computing Summit, 23 giugno 2026. Potrebbero esserci modifiche incompatibili prima della v1.0. Consulta STATUS.md per sapere esattamente cosa è disponibile oggi rispetto a ciò che è in roadmap.

cMCP (Confidential MCP Runtime) è un gateway open-source che verifica ogni chiamata a uno strumento effettuata da un agente AI rispetto alle regole che scrivi, e può essere eseguito su hardware isolato che l'agente non può manomettere. Gli agenti AI utilizzano strumenti (database, CRM, email, API interne) inviando richieste chiamate tool call, solitamente tramite MCP, il Model Context Protocol. cMCP si interpone nel percorso di queste chiamate, verifica ciascuna rispetto alle tue regole (scritte nel linguaggio di policy Cedar) e blocca quelle che le regole vietano. Può essere eseguito all'interno di un TEE (trusted execution environment: hardware che mantiene la memoria di un programma isolata persino dal proprietario della macchina), dove l'agente che governa non può raggiungerlo. Ogni sessione termina con una ricevuta firmata, un TRACE Claim, che chiunque può verificare senza doversi fidare di chi ha eseguito il gateway. La ricevuta è supportata da un report hardware quando il gateway viene eseguito in un TEE, ed è solo firmata (senza prova hardware) in modalità software. Non hai familiarità con questi termini? Consulta i termini, in parole semplici.

TL;DR: Punta il tuo agente verso il cMCP Gateway. Verifica ogni chiamata a uno strumento rispetto alle tue regole Cedar, blocca o oscura (sostituisce) ciò che le regole negano, e ti fornisce una ricevuta firmata che mostra se qualcuno l'ha alterata. Esegui pip install cmcp-runtime e inizia in modalità software su qualsiasi computer; nessun hardware speciale richiesto.

Il tuo agente chiama Snowflake, Salesforce, una dozzina di API. Cosa gli impedisce di divulgare i dati di un cliente durante una di queste chiamate? Se un'autorità di regolamentazione lo chiedesse, potresti dimostrare che non è accaduto?

---

Il problema

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

Niente di tutto ciò dimostra che il motore di policy stesso non sia stato compromesso. La governance MCP solo software non può garantire:

• Che la policy Cedar su disco sia quella che è stata eseguita. Un amministratore malevolo può sostituire il bundle dopo l'approvazione; il controllo dell'hash viene eseguito all'interno dello stesso sistema operativo controllato dall'amministratore.
• Che la decisione di consenso/rifiuto non sia stata invertita in memoria. Una CVE della supply chain nel valutatore viene eseguita nello stesso spazio di indirizzi dell'attaccante.
• Che il registro di audit rifletta ciò che è realmente accaduto. Qualsiasi parte in possesso della chiave di firma software può ricostruire a posteriori una catena di audit valida.

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

Applicazione delle policy con attestazione 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 in esecuzione all'interno di un Trusted Execution Environment (TEE). Prima di servire una singola chiamata a uno strumento, il gateway misura il proprio codice installato, il bundle di policy e la configurazione nel report di attestazione hardware, e riattesta ogni volta che il bundle viene ricaricato.

In un deployment hardware, il cMCP Runtime elabora i payload delle chiamate agli strumenti all'interno del TEE. Ciò che l'host e il provider di connettività possono leggere dipende anche dalla policy di egress, e il server degli strumenti upstream è un componente separato al di fuori del TEE. La modalità software (CMCP_DEV_MODE) non fornisce alcun isolamento hardware. LIMITATIONS.md elenca ciò che cMCP non impedisce.

---

Avvio rapido

pip install cmcp-runtime

Crea 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 non è opzionale qui. CMCP_DEV_MODE=1 salta deliberatamente il requisito del bearer token per permetterti di provare rapidamente, e il bind predefinito è comunque 0.0.0.0:8443. Nella 0.3.0 quella combinazione attivava un gateway non autenticato su ogni interfaccia della tua macchina. Dalla 0.4.0 viene rifiutata: la modalità dev senza token può effettuare il bind solo su un indirizzo di loopback, e un bind non-loopback richiede CMCP_BEARER_TOKEN. Fissa esplicitamente listen_addr e la configurazione sarà 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, primo TRACE Claim e verifica (nessun TEE hardware richiesto).

---

Come funziona