MCP ليس مجرد موصل، بل هو واجهة إدارة لعصر الوكلاء

مشكلة التأطير: كلمة "رابط" لا تعكس بوضوح القرار الذي تتخذه فعلياً.

عندما طرحت شركة أنثروبيك بروتوكول سياق النموذج (MCP) في نوفمبر 2024 كمعيار مفتوح لربط أنظمة الذكاء الاصطناعي بمصادر البيانات وأدوات الأعمال، اتبعت الصناعة نهجها المعتاد مع مواصفات التكامل الجديدة: صنّفت MCP ضمن قسم "البنية التحتية". محوّلات، وسائل نقل، طريقة منظمة لتجنب كتابة برامج ربط منفصلة لكل نموذج ولكل أداة. كل هذا true، وهو أمر غير ذي صلة بالنسبة لمديري تقنية المعلومات، أو مديري التكنولوجيا، أو مديري أمن المعلومات.

إليك إعادة الصياغة المهمة للمؤسسة. بمجرد أن يتمكن الموظف من الاتصال بأداة تقرأ بيانات عملائك أو تكتب في أنظمة سجلاتك، تكون قد أنشأت نقطة تحكم جديدة - سواءً أسميتها أم لا. MCP هو المكان الذي يمكن فيه تحديد نقطة التحكم هذه بشكل واضح. لا يقتصر الأمر على كيفية وصول الموظف إلى أدواتك فحسب، بل يتعلق أيضًا بتحديد هوية المتصل، وهويته، والأدوات المتاحة، وكيفية تسجيل كل مكالمة، وتكلفة كل مكالمة. هذه مسائل تتعلق بالحوكمة، وليست مسائل اتصال. هذه مسائل تتعلق بالحوكمة، وليست مسائل تتعلق بالاتصال.

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

لماذا تعيد "العديد من عمليات التكامل المخصصة" إنشاء الحوكمة بهدوء مرات عديدة؟

معظم الشركات لا تبدأ عصر الوكلاء بصفحة بيضاء. يأتون بمجموعة من التكاملات الجزئية: موصل مخصص هنا، وحساب خدمة هناك، وواجهة برمجة تطبيقات API أنشأها فريق قبل فصلين دراسيين ولا يتذكرها أحد تمامًا. كان كل منها قرارًا محليًا معقولًا. لكنها مجتمعةً تُشكل مشكلة حوكمة، لأن كل واحدة منها تُعيد تطبيق الهوية، والتفويض، والتسجيل، والتحكم في الأسعار/التكاليف بأسلوبها الخاص - أو تتجاهل بعضها تمامًا.

ثلاثة أنماط فشل متوقعة. أولًا، تباين الهويات: يعمل أحد التكاملات كحساب خدمة مشترك، بينما ينتحل آخر هوية المستخدم النهائي، ويستخدم ثالث مفتاحًا طويل الأمد أنشأه شخص انتقل إلى فريق آخر - لذا فإن سؤال "من فعل هذا؟" له N إجابة مختلفة، ولا توجد إجابة كاملة. ثانيًا، تشتت الصلاحيات، لأن قواعد ما يمكن أن تفعله الأداة موجودة في N قاعدة بيانات برمجية مع N دورة مراجعة؛ فالرقابة التي شددتها في مكان ما تبقى غير مشددة في مكان آخر. ثالثًا - وهو ما يلاحظه قسم المالية والتدقيق أولًا - تباين الأرقام، حيث أن الإجابة على نفس السؤال من خلال مساري تكامل تُعطي إجابتين. بمجرد أن يتوقف أصحاب المصلحة عن الثقة في الأرقام، يفقد برنامج الوكيل أهميته.

البديل الموحد ليس سحريًا ولا مجانيًا، ولكنه يُغير طبيعة العمل. فبدلًا من إدارة عدد كبير من عمليات التكامل مرات عديدة، تُدار واجهة واحدة مرة واحدة، وتُتاح الأدوات من خلالها بشكل مُتعمد. تُحدد الهوية في مكان واحد. وتُصبح الصلاحيات خاصية للواجهة، وليست عادة لكل موصل. كما أن التسجيل موحد، لذا فإن سجل التدقيق يُصبح سجلًا حقيقيًا. وتتوقف الأرقام عن التباين لوجود مسار واحد لحسابها. البديل الموحد ليس سحريًا ولا مجانيًا، ولكنه يُغير طبيعة العمل.

الهوية وسياق المستأجر: يُحددان عند الدخول، وليس في الأداة

أول سؤال يجب على واجهة الحوكمة الإجابة عنه هو: لمن تُمنح صلاحية المكالمة؟ في سياق برمجيات الخدمة السحابية متعددة المستأجرين، يكون هذا الأمر دقيقًا، لوجود عاملين منفصلين: هوية المتصل (أي وكيل، يتصرف لصالح أي مستخدم أو خدمة) وسياق المستأجر الذي تعمل المكالمة ضمنه (بيانات العميل وحقوقه المطبقة). يؤدي الخلط بينهما إلى ظهور خطأ "الوكيل المرتبك" الكلاسيكي، حيث يتم توجيه وكيل مصادق عليه بشكل صحيح لغرض معين للتصرف بصلاحيات لم يكن من المفترض أن يرثها.

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

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

التفويض لكل أداة: العرض هو قرار، وليس افتراضيًا

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

بشكلٍ عملي، يجب أن يكون التفويض متعدد المحاور، لا مجرد مفتاح تشغيل/إيقاف. نستخدم نموذجًا ثلاثي المحاور - النطاق والمستوى، حيث يُستمد المستوى من سياق المستأجر كما هو موضح أعلاه - بحيث لا تُتاح أداةٌ مُعينة إلا عندما يسمح نطاق المُستدعي بذلك، ويشملها مستوى المستأجر. تكمن أهمية المحور الثاني في أن القدرة لا تعتمد فقط على هوية الطالب، بل أيضًا على استحقاقات العميل السارية. هذا يحافظ على شفافية الوصول: إضافة أداة جديدة إلى الكتالوج لا يجعلها متاحة تلقائيًا لكل وكيل في كل بيئة.

النموذج الذهني الذي يجب تقديمه لمهندسي النظام هو دليل استخدام، وليس لوحة تحكم. كل أداة في الدليل اكتسبت مكانها من خلال قرار بشأن من يمكنه استخدامها وتحت أي شروط. الأدوات التي لا يحتاجها أي وكيل حاليًا غير موجودة في الكتالوج. "الكل أو لا شيء" هو اقتصاد false؛ "الاختيار المدروس لكل أداة" هو الموقف الوحيد الذي يصمد أمام التدقيق الفعلي.

كتابات الفشل: عدم التماثل بين القراءة والتنفيذ

القراءة والكتابة ليستا متكافئتين من الناحية الأخلاقية، ولا ينبغي لنظام إدارة حسابك أن يتظاهر بذلك. فالقراءة الخاطئة تُرجع بيانات قديمة أو فارغة - قابلة للاسترداد، وغالبًا ما تكون غير مرئية. يؤدي أي خطأ في عملية الكتابة إلى تغيير نظام السجلات، أو إرسال رسالة إلى عميل حقيقي، أو تحويل أموال. تكلفة الخطأ غير متكافئة، لذا يجب أن يكون الوضع الافتراضي غير متكافئ أيضًا.

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

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

دفاتر الميزانية ومفتاح الإيقاف: إدارة التكلفة كعنصر تحكم من الدرجة الأولى

تُضيف الوكلاء نوعًا جديدًا من المخاطر لم تكن موجودة في عمليات التكامل التقليدية: الإنفاق التلقائي. قد تستدعي حلقةٌ ما الأدوات، عبر خللٍ برمجي أو استجابةٍ خبيثة، بشكلٍ يفوق بكثير ما هو مُخطط له، مما يُؤدي إلى استنزاف ميزانية API، وفرض رسومٍ لاحقة، أو إغراق العملاء. لذا، يجب أن يكون التحكم في التكاليف جزءًا لا يتجزأ من نظام الحوكمة، لا أن يُضاف لاحقًا كتنبيهٍ للفواتير يُفعّل بعد وقوع الضرر.

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

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

التدقيق والتنقيح: محدد النطاق، ومؤقت، وقابل للملاحظة

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

وبالمثل، يجب أن يحترم سجل التدقيق نفسه البيانات التي يُسجلها. نُطبق تنقيحًا لكل مكالمة بحيث يُسجل السجل ما حدث - أي أداة، وتحت أي هوية وسياق مستأجر، وبأي نتيجة - دون أن يُصبح نسخة ثانوية من البيانات الحساسة للغاية التي وُضعت الضوابط لحمايتها. سجل التدقيق الذي يُراكم سجلات العملاء كنص عادي ليس ضابطًا؛ بل هو مسؤولية جديدة باسم مُنمق.

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

ربط ذلك بالمخاطر المستمرة - والشفافية بشأن ما تبقى

لا يُعد أي من هذا إعدادًا لمرة واحدة. يُؤكد إطار إدارة مخاطر الذكاء الاصطناعي الصادر عن المعهد الوطني للمعايير والتكنولوجيا (AI RMF 1.0) صراحةً أن إدارة مخاطر الذكاء الاصطناعي عملية مستمرة، وليست مجرد قائمة مراجعة تُكملها وتضعها جانبًا. تُعدّ واجهة الحوكمة قيّمة لأنها تُتيح لهذه العملية المستمرة مكانًا واحدًا للتنفيذ: فعند ظهور خطر جديد، يُمكنك تعديل الصلاحيات والميزانيات ومستوى التعرض أو التدقيق من خلال واجهة واحدة، بدلًا من متابعة التغيير عبر العديد من عمليات التكامل. هذا التوحيد هو ما يجعل الحوكمة المستمرة قابلة للتطبيق بدلًا من كونها مجرد طموح. وهو أيضًا السبب في أن قرار التعرض المدروس يُؤتي ثماره مرتين - مرة عند اتخاذه، ومرة ​​أخرى في كل مرة تحتاج فيها إلى مراجعته.

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

لقد بنينا منصتنا على هذا المبدأ. يُتيح SocialHub.AI أدوات الطبقة الدلالية عبر MCP باستخدام بروتوكول HTTP لنقل البيانات المتدفقة، ويمكن الوصول إليها من وكلاء مثل Claude وGitHub Copilot وMicrosoft و365 Copilot، مع تطبيق عناصر التحكم الموضحة هنا على الواجهة بدلاً من توزيعها عبر الموصلات: نظام ترخيص ثلاثي المحاور مع تحديد المستوى من سياق المستأجر، وكتابات مُغلقة عند الفشل، وسجل ميزانية لكل تشغيل/يوم/30 يومًا مع مفتاح إيقاف قبل التنفيذ، ومفاتيح وكيل محددة النطاق والوقت مع تنقيح وتدقيق لكل مكالمة. وهو نفس نظام الحوكمة الذي يدعم عمل برنامج الولاء حيث ساعدنا في زيادة مساهمة McDonald's China في إجمالي قيمة مبيعات الأعضاء من حوالي 5% إلى 85% - ولا تدوم النتائج بهذا الحجم إلا عندما تكون واجهة البيانات موثوقة بطبيعتها. ...

إذا كنت بصدد تحديد كيفية تعامل الوكلاء مع أنظمة سجلاتك، فإن السؤال الذي يجب طرحه على فريقك ليس "أي موصل؟"، بل "أين تُحدد الهوية والتفويض والتسجيل والتكلفة، وهل يتم ذلك في مكان واحد أم في عدة أماكن؟". إذا كنت ترغب في رؤية كيف تبدو واجهة MCP التي تُركز على الحوكمة في الواقع العملي، فاحجز عرضًا توضيحيًا، أو اقرأ المزيد عن منهجنا في /platform/ai-frontier. إذا كنت ترغب في رؤية كيف تبدو واجهة MCP التي تُركز على الحوكمة في المقام الأول عمليًا، فاحجز عرضًا توضيحيًا، أو اقرأ المزيد عن منهجنا في /platform/ai-frontier.