cMCP : Runtime MCP confidentiel

Mises à jour de la communauté et actualités des contributeurs : AgenTrust sur LinkedIn.

Appliquez la politique des outils MCP à l'intérieur d'un TEE, là où l'agent qu'il gouverne ne peut pas l'atteindre

Démarrage rapide · Architecture · Configuration · CLI · Journal des modifications

Aperçu développeur - lancé lors du Confidential Computing Summit, le 23 juin 2026. Des changements majeurs sont possibles avant la v1.0. Consultez STATUS.md pour savoir précisément ce qui est livré aujourd'hui par rapport à ce qui figure sur la feuille de route.

cMCP (Confidential MCP Runtime) est une passerelle open source qui vérifie chaque appel d'outil effectué par un agent IA par rapport aux règles que vous écrivez, et qui peut s'exécuter sur du matériel isolé que l'agent ne peut pas altérer. Les agents IA utilisent des outils (bases de données, CRM, e-mail, API internes) en envoyant des requêtes appelées appels d'outils, généralement via MCP, le Model Context Protocol. cMCP se place sur le chemin de ces appels, vérifie chacun d'eux par rapport à vos règles (écrites dans le langage de politique Cedar) et bloque ceux que les règles interdisent. Il peut s'exécuter à l'intérieur d'un TEE (trusted execution environment : matériel qui garde la mémoire d'un programme isolée, même vis-à-vis du propriétaire de la machine), là où l'agent qu'il gouverne ne peut pas l'atteindre. Chaque session se termine par un reçu signé, un TRACE Claim, que n'importe qui peut vérifier sans faire confiance à celui qui a exécuté la passerelle. Le reçu est adossé à un rapport matériel lorsque la passerelle s'exécute dans un TEE, et est uniquement signé (sans preuve matérielle) en mode logiciel. Vous découvrez ces termes ? Consultez les termes, en langage clair.

TL;DR : Pointez votre agent vers la passerelle cMCP. Elle vérifie chaque appel d'outil par rapport à vos règles Cedar, bloque ou masque (efface) ce que les règles refusent, et vous fournit un reçu signé qui montre si quelqu'un l'a altéré. Exécutez pip install cmcp-runtime et démarrez en mode logiciel sur n'importe quel ordinateur ; aucun matériel spécial requis.

Votre agent appelle Snowflake, Salesforce, une douzaine d'API. Qu'est-ce qui l'empêche de divulguer les données d'un client lors de l'un de ces appels ? Si un régulateur le demande, pourriez-vous prouver que ce n'est pas le cas ?

Le problème

Un agent appelle un outil. Le moteur de politique répond « autoriser ». L'appel d'outil passe.

Rien de tout cela ne prouve que le moteur de politique lui-même n'a pas été compromis. La gouvernance MCP purement logicielle ne peut pas garantir :

Que la politique Cedar sur le disque est bien celle qui s'est exécutée. Un administrateur malveillant peut remplacer le bundle après approbation ; la vérification du hash s'exécute dans le même OS que celui que l'administrateur contrôle.
Que la décision autoriser/refuser n'a pas été inversée en mémoire. Une CVE de chaîne d'approvisionnement dans l'évaluateur s'exécute dans le même espace d'adressage que l'attaquant.
Que le journal d'audit reflète ce qui s'est réellement passé. Toute partie détenant la clé de signature logicielle peut reconstruire une chaîne d'audit valide après coup.

Le plan de contrôle qui gouverne les appels d'outils doit s'exécuter là où il ne peut pas être atteint par le processus qu'il gouverne.

Application de politique attestée par le matériel pour les appels d'outils MCP. Chaque appel d'outil est intercepté, évalué par rapport à un bundle de politiques Cedar, et appliqué par un moteur de politique s'exécutant à l'intérieur d'un Trusted Execution Environment (TEE). Avant de servir le moindre appel d'outil, la passerelle mesure son code installé, son bundle de politiques et sa configuration dans le rapport d'attestation matérielle, et réatteste à chaque rechargement du bundle.

Dans un déploiement matériel, le cMCP Runtime traite les charges utiles des appels d'outils à l'intérieur du TEE. Ce que l'hôte et le fournisseur de connectivité peuvent lire dépend également de la politique de sortie, et le serveur d'outils en amont est un composant distinct en dehors du TEE. Le mode logiciel (CMCP_DEV_MODE) n'offre aucune isolation matérielle. LIMITATIONS.md liste ce que cMCP ne prévient pas.

Démarrage rapide

pip install cmcp-runtime

Créez cmcp-config.yaml :

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory facilite le réglage au premier lancement ; la valeur par défaut est `enforcing`
listen_addr: "127.0.0.1:8443"  # fixez le loopback : le mode dev s'exécute sans jeton bearer
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

listen_addr n'est pas optionnel ici. CMCP_DEV_MODE=1 ignore délibérément l'exigence de jeton bearer pour vous permettre d'essayer rapidement, et la liaison par défaut reste 0.0.0.0:8443. Sur la 0.3.0, cette combinaison montait une passerelle non authentifiée sur toutes les interfaces de votre machine. À partir de la 0.4.0, c'est refusé : le mode dev sans jeton ne peut lier qu'une adresse loopback, et une liaison non-loopback exige CMCP_BEARER_TOKEN. Fixez listen_addr explicitement et la configuration est correcte dans les deux cas.

Démarrez la passerelle :

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

Effectuez un appel d'outil :

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

Vous préférez une version guidée ? agentrust-io.com/quickstart parcourt le même chemin en une dizaine de minutes sur un ordinateur portable, sans matériel et sans inscription : installez, écrivez une règle Cedar forbid, observez un appel d'outil renvoyer 403 POLICY_DENY avant d'atteindre un service en amont, puis vérifiez le reçu signé.

Consultez docs/quickstart.md pour la procédure complète : politique Cedar, catalogue d'outils, premier TRACE Claim et vérification (aucun TEE matériel requis).

cmcp v0.4.0