cMCP: بيئة تشغيل MCP السرية

تحديثات المجتمع وأبرز المساهمين: AgenTrust على LinkedIn.

فرض سياسة أدوات MCP داخل TEE، حيث لا يستطيع الوكيل الذي تحكمه الوصول إليها

البدء السريع · البنية · الإعدادات · CLI · سجل التغييرات

معاينة للمطورين - أُطلقت في قمة الحوسبة السرية، 23 يونيو 2026. قد تتضمن تغييرات كاسرة قبل الإصدار v1.0. راجع STATUS.md لمعرفة ما يُشحن اليوم بالضبط مقابل ما هو على خارطة الطريق.

cMCP (بيئة تشغيل MCP السرية) هي بوابة مفتوحة المصدر تفحص كل استدعاء أداة يقوم به وكيل ذكاء اصطناعي مقابل قواعد تكتبها أنت، ويمكنها العمل على عتاد معزول لا يستطيع الوكيل العبث به. تستخدم وكلاء الذكاء الاصطناعي الأدوات (قواعد البيانات، أنظمة إدارة علاقات العملاء، البريد الإلكتروني، واجهات API الداخلية) عبر إرسال طلبات تُسمى استدعاءات الأدوات، عادةً عبر MCP، بروتوكول سياق النموذج. تقع cMCP في مسار تلك الاستدعاءات، وتفحص كل واحد منها مقابل قواعدك (المكتوبة بلغة سياسات Cedar)، وتحجب ما تحظره القواعد. يمكنها العمل داخل TEE (بيئة تنفيذ موثوقة: عتاد يحافظ على ذاكرة البرنامج معزولة حتى عن مالك الجهاز)، حيث لا يستطيع الوكيل الذي تحكمه الوصول إليها. تنتهي كل جلسة بإيصال موقّع، وهو TRACE Claim، يمكن لأي شخص التحقق منه دون الثقة بمن شغّل البوابة. يُدعم الإيصال بتقرير عتاد عندما تعمل البوابة داخل TEE، ويكون موقّعًا فقط (دون إثبات عتادي) في الوضع البرمجي. جديد على هذه المصطلحات؟ راجع المصطلحات، بلغة مبسطة.

باختصار: وجّه وكيلك إلى بوابة cMCP. تفحص كل استدعاء أداة مقابل قواعد Cedar الخاصة بك، وتحجب أو تحجب جزئيًا (تفرّغ) ما ترفضه القواعد، وتمنحك إيصالًا موقّعًا يُظهر ما إذا كان أي شخص قد عبث به. شغّل pip install cmcp-runtime وابدأ في الوضع البرمجي على أي حاسوب؛ لا حاجة إلى عتاد خاص.

يستدعي وكيلك Snowflake وSalesforce وعشرات من واجهات API. ما الذي يمنعه من تسريب بيانات عميل في أحد تلك الاستدعاءات؟ وإذا سأل جهة تنظيمية، هل يمكنك إثبات أنه لم يفعل ذلك؟

المشكلة

يستدعي الوكيل أداة. يقول محرك السياسات: اسمح. يمر استدعاء الأداة.

لا شيء من ذلك يثبت أن محرك السياسات نفسه لم يُخترق. لا يمكن لحوكمة MCP البرمجية فقط أن تضمن:

أن سياسة Cedar على القرص هي التي نُفّذت. يمكن لمسؤول مارق استبدال الحزمة بعد الموافقة؛ إذ يجري فحص التجزئة داخل نظام التشغيل نفسه الذي يتحكم به المسؤول.
أن قرار السماح/الرفض لم يُقلب في الذاكرة. تعمل ثغرة CVE في سلسلة التوريد داخل المُقيِّم في نفس مساحة العنوان التي يعمل فيها المهاجم.
أن سجل التدقيق يعكس ما حدث فعلاً. يمكن لأي طرف يحمل مفتاح التوقيع البرمجي إعادة بناء سلسلة تدقيق صالحة بعد وقوع الحدث.

يجب أن تعمل لوحة التحكم التي تحكم استدعاءات الأدوات في مكان لا تستطيع العملية التي تحكمها الوصول إليه.

فرض السياسات الموثّق بالعتاد لاستدعاءات أدوات MCP. يُعترَض كل استدعاء أداة، ويُقيَّم مقابل حزمة سياسات Cedar، ويُفرَض بواسطة محرك سياسات يعمل داخل بيئة تنفيذ موثوقة (TEE). وقبل أن يخدم استدعاء أداة واحدًا، يقيس البوابة شيفرتها المثبَّتة وحزمة سياساتها وإعداداتها ضمن تقرير التوثيق العتادي، ويعيد التوثيق كلما أُعيد تحميل الحزمة.

في النشر العتادي، تعالج بيئة تشغيل cMCP (cMCP Runtime) حمولات استدعاءات الأدوات داخل TEE. وما يمكن للمضيف ومزوّد الاتصال قراءته يعتمد أيضًا على سياسة الخروج، وخادم الأدوات الأعلى هو مكوّن منفصل خارج TEE. لا يوفّر الوضع البرمجي (CMCP_DEV_MODE) أي عزل عتادي. يسرد LIMITATIONS.md ما لا يمنعه cMCP.

البدء السريع

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 يتم رفض ذلك: لا يجوز لوضع التطوير بدون رمز أن يربط إلا عنوان loopback، ويتطلب الربط غير الـ loopback وجود 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 عبر المسار نفسه في نحو عشر دقائق على حاسوب محمول، دون أي عتاد ودون تسجيل: ثبّت، واكتب قاعدة forbid واحدة بلغة Cedar، وراقب استدعاء أداة يُرجع 403 POLICY_DENY قبل أن يصل إلى نظام خارجي، ثم تحقّق من الإيصال الموقّع.

راجع docs/quickstart.md للاطلاع على الدليل الكامل: سياسة Cedar، وكتالوج الأدوات، وأول TRACE Claim، والتحقق (دون الحاجة إلى عتاد TEE).

كيف يعمل

يرسل الوكيل كل استدعاء أداة إلى cMCP Gateway بدلًا من إرساله مباشرة إلى خوادم MCP.
عند بدء التشغيل، وقبل أن يبدأ بخدمة حركة المرور، تقيس البوابة شيفرتها المثبّتة وحزمة سياسة Cedar وإعداداتها. على SEV-SNP وTDX وAzure CVM تُربط البصمة في report_data؛ وعلى طبقة TPM تُمدَّد إلى فهرس NV معتمد. وإعادة تحميل السياسة تؤدي إلى إثبات جديد.
يُقيَّم كل استدعاء أداة وارد بواسطة محرك سياسة Cedar العامل داخل TEE. والنتيجة هي السماح أو الرفض أو الحجب. ويُضاف الاستدعاء وقراره إلى سلسلة التدقيق المختومة بالعتاد.
في نهاية الجلسة تُنتج البوابة TRACE Claim: أثر موقّع ومُوثَّق بالعتاد يسجّل الأدوات التي نُفِّذت، والسياسة التي قرّرت كل استدعاء، وسلسلة التدقيق الكاملة. ويتحقق المدقّق من ذلك دون الوثوق بالمشغّل.

Agent -> cMCP Runtime -> Cedar Policy Engine (TEE) -> Tool
                     |
               GatewayClaim (TRACE Profile)
               +-- trace.eat_profile
               +-- trace.runtime.platform + measurement
               +-- trace.policy.bundle_hash
               +-- trace.cnf.jwk  (Ed25519 confirmation key)
               +-- gateway.audit_chain (root/tip/length)
               +-- signature (Ed25519 over canonical JSON)

موفرو الأجهزة

المزوّد	المنصة	الضمان	ملاحظات
`tpm`	TPM 2.0 / vTPM (Azure، AWS، GCP Trusted Launch)	متوسط	اقتباس TPM محلي
`sev-snp`	AMD SEV-SNP (Azure DCasv5، AWS C6a Nitro)	عالٍ	AMD KDS
`tdx`	Intel TDX (Azure DCedsv5، GCP C3)	عالٍ	Intel PCS
`gpu-cc` (v0.2)	NVIDIA H100/H200/Blackwell (وضع CC)	عالٍ	خدمة NVIDIA للإثبات عن بُعد (NRAS)

cmcp