cMCP: गोपनीय MCP रनटाइम

समुदाय अपडेट और योगदानकर्ता हाइलाइट्स: AgenTrust on LinkedIn।

MCP टूल नीति को एक TEE के भीतर लागू करें, जहाँ इसे नियंत्रित करने वाला एजेंट इसे छू न सके

Quick Start · Architecture · Configuration · CLI · Changelog

Developer Preview - Confidential Computing Summit, 23 जून 2026 को लॉन्च किया गया। v1.0 से पहले ब्रेकिंग बदलाव हो सकते हैं। आज वास्तव में क्या शिप होता है बनाम रोडमैप पर क्या है, इसके लिए STATUS.md देखें।

cMCP (Confidential MCP Runtime) एक ओपन-सोर्स गेटवे है जो AI एजेंट द्वारा किए गए प्रत्येक टूल कॉल को आपके लिखे नियमों के विरुद्ध जाँचता है, और ऐसे सील-बंद हार्डवेयर पर चल सकता है जिसे एजेंट छेड़छाड़ नहीं कर सकता। AI एजेंट टूल्स (डेटाबेस, CRM, ईमेल, आंतरिक API) का उपयोग टूल कॉल नामक अनुरोध भेजकर करते हैं, आमतौर पर MCP, यानी Model Context Protocol के माध्यम से। cMCP उन कॉलों के पथ में बैठता है, प्रत्येक को आपके नियमों (Cedar नीति भाषा में लिखे गए) के विरुद्ध जाँचता है, और उन कॉलों को ब्लॉक करता है जिन्हें नियम मना करते हैं। यह एक TEE (trusted execution environment: ऐसा हार्डवेयर जो किसी प्रोग्राम की मेमोरी को मशीन के मालिक से भी सील-बंद रखता है) के भीतर चल सकता है, जहाँ इसे नियंत्रित करने वाला एजेंट इसे छू नहीं सकता। प्रत्येक सत्र एक हस्ताक्षरित रसीद, एक TRACE Claim के साथ समाप्त होता है, जिसे कोई भी गेटवे चलाने वाले पर भरोसा किए बिना जाँच सकता है। जब गेटवे TEE में चलता है तो रसीद हार्डवेयर रिपोर्ट द्वारा समर्थित होती है, और सॉफ़्टवेयर मोड में केवल हस्ताक्षरित होती है (कोई हार्डवेयर प्रमाण नहीं)। इन शब्दों में नए हैं? शब्दावली, सरल अंग्रेज़ी में देखें।

TL;DR: अपने एजेंट को cMCP Gateway की ओर इंगित करें। यह प्रत्येक टूल कॉल को आपके Cedar नियमों के विरुद्ध जाँचता है, जिन्हें नियम अस्वीकार करते हैं उन्हें ब्लॉक या रिडैक्ट (खाली) करता है, और आपको एक हस्ताक्षरित रसीद देता है जो दिखाती है कि किसी ने इसमें छेड़छाड़ की या नहीं। pip install cmcp-runtime चलाएँ और किसी भी कंप्यूटर पर सॉफ़्टवेयर मोड में शुरू करें; किसी विशेष हार्डवेयर की आवश्यकता नहीं।

आपका एजेंट Snowflake, Salesforce, दर्जनों API को कॉल करता है। उन कॉलों में से किसी एक पर ग्राहक का डेटा लीक होने से क्या रोकता है? यदि कोई नियामक पूछे, तो क्या आप साबित कर पाएँगे कि ऐसा नहीं हुआ?

समस्या

एक एजेंट एक टूल को कॉल करता है। नीति इंजन कहता है अनुमति दें। टूल कॉल पार हो जाता है।

इनमें से कोई भी यह साबित नहीं करता कि नीति इंजन स्वयं समझौता नहीं किया गया था। केवल-सॉफ़्टवेयर MCP गवर्नेंस इसकी गारंटी नहीं दे सकता:

डिस्क पर मौजूद Cedar नीति वही है जो चली। एक दुर्भावनापूर्ण एडमिन अनुमोदन के बाद बंडल बदल सकता है; हैश जाँच उसी OS के भीतर चलती है जिसे एडमिन नियंत्रित करता है।
allow/deny निर्णय मेमोरी में पलटा नहीं गया। मूल्यांकनकर्ता में एक सप्लाई चेन CVE हमलावर के समान address space में चलता है।
ऑडिट लॉग दर्शाता है कि वास्तव में क्या हुआ। सॉफ़्टवेयर साइनिंग कुंजी रखने वाला कोई भी पक्ष बाद में एक वैध ऑडिट चेन पुनर्निर्मित कर सकता है।

टूल कॉलों को नियंत्रित करने वाला कंट्रोल प्लेन वहाँ चलना चाहिए जहाँ उसे नियंत्रित करने वाली प्रक्रिया पहुँच न सके।

MCP टूल कॉलों के लिए हार्डवेयर-प्रमाणित नीति प्रवर्तन। प्रत्येक टूल कॉल को इंटरसेप्ट किया जाता है, एक Cedar नीति बंडल के विरुद्ध मूल्यांकित किया जाता है, और एक Trusted Execution Environment (TEE) के भीतर चलने वाले नीति इंजन द्वारा लागू किया जाता है। एक भी टूल कॉल की सेवा करने से पहले, गेटवे अपने इंस्टॉल किए गए कोड, नीति बंडल और कॉन्फ़िग को हार्डवेयर अटेस्टेशन रिपोर्ट में मापता है, और जब भी बंडल पुनः लोड होता है तो पुनः अटेस्ट करता है।

हार्डवेयर परिनियोजन में, cMCP रनटाइम TEE के भीतर टूल-कॉल पेलोड को प्रोसेस करता है। होस्ट और कनेक्टिविटी प्रदाता क्या पढ़ सकते हैं यह भी egress नीति पर निर्भर करता है, और अपस्ट्रीम टूल सर्वर TEE के बाहर एक अलग घटक है। सॉफ़्टवेयर मोड (CMCP_DEV_MODE) कोई हार्डवेयर आइसोलेशन प्रदान नहीं करता। LIMITATIONS.md सूचीबद्ध करता है कि cMCP क्या नहीं रोकता।

Quick Start

pip install cmcp-runtime

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 वैकल्पिक नहीं है। CMCP_DEV_MODE=1 जानबूझकर bearer token की आवश्यकता को छोड़ देता है ताकि आप चीज़ें जल्दी आज़मा सकें, और डिफ़ॉल्ट बाइंड अभी भी 0.0.0.0:8443 है। 0.3.0 पर उस संयोजन ने आपकी मशीन के हर इंटरफ़ेस पर एक अनप्रमाणित गेटवे खड़ा कर दिया। 0.4.0 से इसे अस्वीकार कर दिया जाता है: टोकन-रहित डेव मोड केवल लूपबैक पते को बाइंड कर सकता है, और गैर-लूपबैक बाइंड के लिए CMCP_BEARER_TOKEN आवश्यक है। listen_addr को स्पष्ट रूप से पिन करें और कॉन्फ़िग दोनों पर सही रहेगा।

गेटवे शुरू करें:

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

एक टूल कॉल करें:

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

एक निर्देशित संस्करण पसंद करते हैं? agentrust-io.com/quickstart एक लैपटॉप पर लगभग दस मिनट में उसी पथ पर चलता है, बिना हार्डवेयर और बिना साइनअप: इंस्टॉल करें, एक Cedar forbid नियम लिखें, एक टूल कॉल को अपस्ट्रीम तक पहुँचने से पहले 403 POLICY_DENY लौटाते हुए देखें, फिर हस्ताक्षरित रसीद सत्यापित करें।

पूर्ण वॉकथ्रू के लिए docs/quickstart.md देखें: Cedar नीति, टूल कैटलॉग, पहला TRACE Claim, और सत्यापन (किसी हार्डवेयर TEE की आवश्यकता नहीं)।

यह कैसे काम करता है

एजेंट प्रत्येक टूल कॉल को सीधे MCP सर्वरों के बजाय cMCP Gateway को भेजता है।
स्टार्टअप पर, ट्रैफ़िक की सेवा करने से पहले, गेटवे अपने इंस्टॉल किए गए कोड, Cedar नीति बंडल और कॉन्फ़िग को मापता है। SEV-SNP, TDX और Azure CVM पर डाइजेस्ट report_data में बाइंड होता है; TPM टियर पर इसे एक प्रमाणित NV इंडेक्स में एक्सटेंड किया जाता है। नीति पुनः लोड होने पर एक नया अटेस्टेशन ट्रिगर होता है।
प्रत्येक आने वाली टूल कॉल का मूल्यांकन TEE के भीतर चलने वाला Cedar नीति इंजन करता है। परिणाम allow, deny, या redact होता है। कॉल और उसका निर्णय हार्डवेयर-सील्ड ऑडिट चेन में जोड़े जाते हैं।
सत्र के अंत में गेटवे एक TRACE Claim उत्पन्न करता है: एक हस्ताक्षरित, हार्डवेयर-प्रमाणित आर्टिफ़ैक्ट जो रिकॉर्ड करता है कि कौन से टूल चले, किस नीति ने प्रत्येक कॉल का निर्णय लिया, और पूरी ऑडिट चेन। एक सत्यापनकर्ता इसे ऑपरेटर पर भरोसा किए बिना जाँचता है।

cmcp v0.4.0