MCP في المؤسسات: ربط الوكلاء بـ Confluence وJira وMicrosoft 365 بأمان

ما هو بروتوكول سياق النموذج (MCP)؟

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

لماذا يُعدّ ربط الوكلاء بأدوات المؤسسة مسألة أمنية؟

سؤال التكامل يسأل: هل يستطيع الوكيل الوصول إلى Confluence؟ أما السؤال الأمني فيسأل: ماذا يحق له أن يقرأ حين يصل، ونيابةً عن من، وماذا يحدث للنص الذي يعيده؟ ففي التكامل التقليدي يضغط شخص على زر ويُدقَّق حساب خدمة. أما مع الوكيل فيصدر الاستدعاء عن نموذج، وغالبًا ضمن حلقة، انطلاقًا من نص قد يكون هو نفسه آتيًا من صفحة مسترجعة.

وتنتج عن ذلك أربعة هواجس أعدّها النطاق الحقيقي لأي مشروع MCP:

• الصلاحيات: ينبغي أن يرى الوكيل ما يحق للشخص السائل رؤيته، لا ما يستطيع الرمز المشترك رؤيته.
• حقن التعليمات عبر المحتوى المسترجع: صفحة الويكي أو التذكرة بيانات، لكن النموذج قد يقرأ فيها تعليمات.
• تصنيف البيانات: يجب ألا يتدفق المحتوى السري أو الحساس إلى أماكن لا ينبغي أن يبلغها، ومنها النماذج الخارجية.
• التدقيق: لا بد من القدرة على إعادة بناء ما قُدِّم، ولمن، ولماذا.

ما أبرز المخاطر وما الضوابط المقابلة لها؟

معظم الإخفاقات التي أتوقعها في هذا المجال ليست إخفاقات في البروتوكول نفسه. بل تأتي من حساب خدمة واسع الصلاحيات لم يقيّده أحد بالشخص السائل. ويربط الجدول كل خطر بالضابط الذي أبحث عنه عند مراجعة أي موصّل.

كيف تتصل ORBIT بـ Confluence وJira وMicrosoft 365؟

لدى ORBIT، منصة السياق التي بنيتها، طريقان إلى الأدوات الخارجية. تغطي الموصّلات الأصلية SharePoint وOneDrive وConfluence وJira. وتغطي موصّلات MCP كلًّا من Confluence وJira وMicrosoft 365 وGoogle Workspace وSlack وGitHub وLinear وObsidian وFigma، مع مساعد بدء من خمس خطوات. ويزامن عامل (worker) الموصّلات وفق جدول، كل 60 دقيقة افتراضيًا.

ويغذي الطريقان خط الاستيعاب نفسه. فصفحة Confluence أو تذكرة Jira تمر بكشف البيانات الشخصية والتصنيف والتقطيع قبل أن يجوز تقديمها لأي وكيل. والخيار التصميمي الذي أهتم به أن الوكيل لا يخاطب Confluence مباشرة أبدًا، بل يخاطب ORBIT التي تحتفظ بنسخة متزامنة ومصنَّفة.

وهناك حد يجب ذكره بوضوح، حتى لا يُفهم من الموصّلات أكثر مما تقدمه: تسجيل الدخول التفاعلي عبر OAuth لـ Microsoft 365 وGoogle وLinear من خلال MCP مدرج في خارطة الطريق ولم يُنجَز بعد.

كيف تحافظ ORBIT على الصلاحيات والتصنيف؟

القاعدة معلنة في سطر واحد في ملف README: لا يُقدَّم المحتوى إلا إذا كان تصنيفه أقل من أدنى قيمة بين تخويل المستخدم وتخويل الوكيل والسقف المحدد في الطلب، أو مساويًا لها. ويعمل الوكيل نيابةً عن عضو في المشروع، وبدون ذلك لا يصل إلا إلى ما هو مفتوح لكل المشروع.

وتسترجع NOVA، وكيل المنتج الشخصي الذي بنيته، سياق ORBIT بصفة المستخدم، فتسري القاعدة نفسها حين يطلب منها شخص مخرجًا. وهذه هي الآليات الكامنة وراء القاعدة كما يصفها README:

• سلم تصنيف من C0 (عام) إلى C3 (سري)، متوافق مع سياسة المؤسسة.
• قوائم وصول على الوثائق والمقاطع والذاكرة. وترث الذاكرة المشتقة أشد القوائم تقييدًا وأعلى تصنيف بين مصادرها.
• تُسجَّل حالات الاستبعاد بسبب الوصول أو التصنيف لكنها تُحجب عمّن لا يملك الوصول: لا عنوان ولا مقتطف ولا معرّف. ولا يتلقى الوكلاء سوى عدّادات، فلا يعرف الوكيل حتى عنوان ما مُنع من رؤيته.
• كشف للبيانات الشخصية عند الاستيعاب، ويستخدم السياق المقدَّم دائمًا النص المحجوب.
• أحداث إلغاء مثل document.acl_changed وmember.removed وagent.revoked في سجل التغييرات وفي الويب هوك الموقَّعة، ليبطل المستهلكون ما اشتقوه.

كيف تتعامل ORBIT مع حقن التعليمات في المحتوى المسترجع؟

حقن التعليمات هو الخطر الذي يجعله MCP أوضح ما يكون، لأن الوكيل صار يقرأ نصوصًا كتبها أشخاص لم يلتقِ بهم قط. ولا أعتقد أن مرشحًا واحدًا يحل المشكلة، ولا أن أي دفاع منها يغني عن غيره، ولذلك تجمع ORBIT عدة دفاعات، وكلها ظاهرة في إعداداتها:

• عند الاستيعاب يُمنح كل مقطع درجة. وإذا تجاوزت عتبة (0.6 افتراضيًا) حُجر المقطع إلى أن يفرج عنه مالك المشروع. ويمكن إضافة مصنِّف محلي اختياري.
• عند التقديم يُوسم كل ما يُسلَّم للوكلاء بأنه بيانات غير موثوقة، وهي تقنية تُعرف غالبًا باسم spotlighting.
• تتلقى المصادر منخفضة الثقة عقوبة في الترتيب (0.15 افتراضيًا)، فتظهر بوتيرة أقل.
• ينطلق إنذار تسميم حين يقترح مصدر حديث أو وكيل عددًا غير معتاد من العناصر خلال نافذة زمنية (8 خلال 24 ساعة افتراضيًا).

ماذا يعرض خادم MCP الخاص بـ ORBIT، وكيف تُحتوى الخوادم الخارجية؟

ORBIT خادم MCP أيضًا، عبر streamable HTTP. يحمل كل وكيل مفتاح واجهة مرتبطًا بمشروع، ولا يُخزَّن منه سوى بصمة SHA-256. ويعرض الخادم 12 أداة، منها get_context وsearch_sources وexpand_source وpropose_memory. وهذه الأخيرة تنشئ اقتراحًا يجب أن يصادق عليه إنسان، فلا يستطيع الوكيل الكتابة مباشرة في الذاكرة الموثوقة.

أما خوادم MCP الخارجية فتعكس ORBIT فيها الثقة المعتادة. إذ لا يُشغَّل سوى خوادم القوالب المعدّة سلفًا، من قائمة مسموح بها، وبوسائط تُبنى من جهة الخادم. وتعمل في بيئة معزولة لا تحتوي إلا على أوراق اعتماد ذلك الموصّل، مع مهل وسقوف لعدد العناصر. وتُشفَّر أسرار الموصّلات ولا تُعرض مجددًا، وتضمّن صور الخلفية إصدارات مثبّتة من Node.js وخوادم MCP، فلا تُنزَّل أي شيفرة أثناء التشغيل. ويوجد قالب مخصص، لكنه معطّل افتراضيًا ومقصور على المسؤولين.

هل ORBIT جاهزة للإنتاج، ومن أين تبدأ؟

لا. ORBIT نسخة تجريبية عامة وغير مُصادَق عليها للاستخدام في الإنتاج. ويذكر ملف README أن التقوية الكاملة للإنتاج، ومنها الدخول الموحد والمصادقة متعددة العوامل والتدقيق المتسلسل والنسخ الاحتياطية، ما تزال قيد التنفيذ. وليست لدي نتائج مقيسة أستشهد بها: فما سبق يصف ما يوفره المشروع لا ما حققه. وتحتوي بيانات العرض التجريبي على محتوى وهمي عن قصد من فئتي C2 (سري) وC3 (بالغ السرية)،ويحذّر README من خلط بيانات حقيقية بها. وأكرر هذا التحذير هنا لأن الخطأ في هذا الأمر مكلف.

وأيًّا كانت الأداة التي تختارها، فهذا هو الترتيب الذي أتبعه، وهو لا يتطلب منصة جديدة منذ اليوم الأول:

• أحصِ كل خادم MCP وكل موصّل، وعيّن مسؤولًا لكل منها.
• استبدل حسابات الخدمة المشتركة بوصول نيابةً عن الشخص السائل.
• صنّف المحتوى قبل أن يبلغ الوكيل، وحدّد ما يجوز أن تتلقاه النماذج الخارجية.
• عامل كل نص مسترجع بوصفه بيانات غير موثوقة لا تعليمات.
• اعتمد قائمة مسموحًا بها للخوادم وأبقِ المخصصة منها معطلة.
• سجّل ما قُدِّم ولماذا، واختبر ببيانات وهمية أولًا.