agentrust-io/cmcpcMCP : Passerelle MCP confidentielle. Application de politiques attestée par le matériel pour les appels d'outils MCP.
Mises à jour de la communauté et actualités des contributeurs : AgenTrust sur LinkedIn.
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 : un environnement d'exécution de confiance, c'est-à-dire du matériel qui maintient 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 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 il est uniquement signé (sans preuve matérielle) en mode logiciel. Vous découvrez ces termes ? Voir les termes, en langage clair.
En bref : Pointez votre agent vers la passerelle cMCP. Elle vérifie chaque appel d'outil par rapport à vos règles Cedar, bloque ou masque (remplace par du vide) 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-runtimeet démarrez en mode logiciel sur n'importe quel ordinateur ; aucun matériel spécial n'est 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 le contraire ?
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 :
Le plan de contrôle qui gouverne les appels d'outils doit s'exécuter là où le processus qu'il gouverne ne peut l'atteindre.
Application des politiques attestée par le matériel pour les appels d'outils MCP. Chaque appel d'outil est intercepté, évalué par rapport à un ensemble de politiques Cedar, et appliqué par un moteur de politiques s'exécutant à l'intérieur d'un environnement d'exécution de confiance (TEE). Avant de servir un seul appel d'outil, la passerelle mesure son code installé, son ensemble de politiques et sa configuration dans le rapport d'attestation matérielle, et réatteste à chaque rechargement de l'ensemble.
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 énumère ce que cMCP ne prévient pas.
pip install cmcp-runtime
Créez 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'est pas facultatif ici. CMCP_DEV_MODE=1 ignore délibérément
l'exigence de jeton bearer afin que vous puissiez tester rapidement, et la liaison par défaut est
toujours 0.0.0.0:8443. Sur la version 0.3.0, cette combinaison créait une passerelle
non authentifiée sur toutes les interfaces de votre machine. À partir de la version 0.4.0, elle est refusée : le mode
dev sans jeton ne peut se lier qu'à une adresse de bouclage, et une liaison non-loopback nécessite
CMCP_BEARER_TOKEN. Fixez listen_addr explicitement et la configuration sera correcte dans
les deux cas.
Démarrez la passerelle :
CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml
Faire 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).