البوابة البشرية: تصميم الموافقات على أدوات MCP عند حدود Gateway

يمنح MCP العملاء والخوادم طريقة قياسية لاكتشاف الأدوات واستدعائها. ولكنه يتعمد عدم توحيد واجهة المستخدم الخاصة بالموافقة أو سير عمل العنصر البشري في المخطط (human-in-the-loop). تنص مواصفة أدوات 2026-07-28 على أن التطبيقات حرة في اختيار نموذج التفاعل الخاص بها، مع التوصية بأن تحافظ التطبيقات على قدرة العنصر البشري على رفض استدعاءات الأدوات. تقع الموافقات على أدوات MCP من TrueFoundry في المساحة التنفيذية لتلك المواصفة: حيث يمكن لـ Gateway احتجاز طلب مُطابق لـ tools/call، وإنشاء طلب موافقة، وإخطار المعتمد، وإعادة نتيجة ناجحة تحمل بيانات وصفية (metadata) خاصة بالموافقة لـ TrueFoundry حتى يستطيع المتصل المتوافق التمييز بين في انتظار الموافقة وفشل تنفيذ الأداة. القيمة الهندسيّة لا تكمن في أن MCP قام بتوحيد نظام الموافقة قياسيًا—فهو لم يفعل ذلك—بل في أنه يمكن فرض الموافقة عند حدود أداة مشتركة، ونطاقها مرتبط بالهوية والأداة، وتكون مرتبطة بمسار التنفيذ دون تحويل قرار بشري مؤقت إلى سياسة تفويض دائمة.

1. البداية عند حدود البروتوكول

التمييز الأهم هو بين ما يقوم MCP بتقييسه قياسيًا وما تقوم Gateway بتنفيذه. يقوم MCP بتقييس اكتشاف الأدوات، والاستدعاء، والمخططات (schemas)، والنتائج، و—في مراجعة 2026-07-28—طرق أغنى لسير عمل الأداة التي تتطلب إدخالات إضافية. توجيهات المواصفة الخاصة بتفاعل المستخدم أكثر مرونة بشكل متعمد: يجب على التطبيقات جعل عرض الأداة واستدعائها مرئيين ويجب أن تمنح الإنسان القدرة على رفض العمليات، لكن البروتوكول لا يفرض واجهة تأكيد معينة أو دورة حياة للموافقة. ينشئ ذلك مساحة لـ gateway لفرض سياسة على مستوى المؤسسة دون التظاهر بأن كائن السياسة الخاص بها هو جزء من MCP نفسه.

يمكن قراءة التدفق الموثق لـ TrueFoundry على أنه ست خطوات. يصل tools/call إلى MCP Gateway ويطابق سياسة موافقة؛ تحتجز Gateway الاستدعاء بدلاً من استدعاء الأداة اللاحقة (downstream)؛ تنشئ طلب الموافقة المعلق أو تعيد استخدامه وتخطر مسار المعتمد المهيأ؛ يتلقى المتصل نتيجة ناجحة ينقل _meta.approval_status الخاص بها أن التنفيذ معلق؛ يوافق الإنسان أو يرفض؛ وعند الموافقة، تحرر Gateway التنفيذ وفقًا للصلاحية المهيأة. يمكن للاستدعاءات المكررة لنفس سياق الطالب/الأداة المعلق إعادة استخدام الطلب المعلق بدلاً من إنشائهم إشعار موافقة جديد في كل مرة.

التوقف المؤقت هو حالة على مستوى التنفيذ، وليس خطأً في البروتوكول. يمثل ذلك عقدًا جيدًا مع العميل لأن المنسق (orchestrator) الذي يفهم البيانات الوصفية يمكنه التفريع بناءً على "في انتظار الموافقة" بدلاً من التعامل مع الأداة على أنها غير متاحة. لكن العبء صريح: العملاء الذين لا يفهمون البيانات الوصفية لـ TrueFoundry ليسوا مضمونين للانتظار بشكل صحيح. تحدد مواصفة MCP بتاريخ 2026-07-28 أيضًا نتائج input_required للطلبات متعددة جولات الذهاب والإياب وتنقل Tasks طويلة التشغيل إلى امتداد؛ وتلك آليات موحدة قياسيًا في MCP مع دلالات إرسال مختلفة. لذلك، يجب وصف بوابة الموافقة بأنها متوافقة مع عالم MCP متزايد القابلية للمقاطعة، وليس كـ MCP Task تم إدراجها بواسطة Gateway.

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

2. الدلالات الأمنية تكمن في النطاق

من الأسهل استيعاب ميزة الموافقة عندما يتم التعامل معها كنقطة تحقق تفويض ضيقة بدلاً من طبقة أمان شاملة. هناك أربع خصائص مهمة.

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

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

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

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

3. إجهاد الموافقة هو وضع فشل تشغيلي

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

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

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

تدقيق البوابة. لكل أداة مشروطة بموافقة، أجب عن سبعة أسئلة: لماذا هناك حاجة إلى إنسان بدلاً من السياسة الثابتة؟ هل الصلاحية لتنفيذ واحد أم مستندة إلى الوقت؟ إذا كانت مستندة إلى الوقت، ما هي تغييرات الوسائط اللاحقة التي يمكن أن تحدث دون إعادة موافقة؟ ما هي الهوية المحسومة التي تمتلك الترخيص؟ من هو المعتمد المسمى وما هو التراجع (fallback)؟ هل يمكن للعميل المتصل التعرف صراحة على اتفاقية النتيجة المعلقة وإعادة المحاولة؟ وإذا كان الاشتراط يكيّف بناءً على توضيحات MCP المرفقة مثل destructiveHint، هل الخادم موثوق—أم أن المؤسسة صنفت الأداة بشكل مستقل؟ ثم تحقق من أنه يمكن ربط معرف طلب الموافقة بـ سجل تنفيذ الأداة وقرارها المقابل. الهدف هو إثبات وجود قرار حقيقي، وليس حجمًا كبيرًا من أحداث "تمت الموافقة".

4. أين تقع البوابة — وما لا تحل محله

يحتاج مسار الأدوات في بيئة الإنتاج إلى عدة عناصر تحكم بمهام مختلفة. يحدد السجل أو عملية القبول الخوادم والأدوات المسموح بها في البيئة. يحسم التوثيق (Authentication) هوية المتصل. يحدد التحكم في الوصول الأدوات التي يمكن لـ هذا المتصل الوصول إليها. تفحص حواجز الحماية قبل الأداة الاستدعاء أو تحوله. يمكن لـ الموافقة على الأداة احتجاز الاستدعاء المسموح به لقرار بشري. تفرض Gateway هذا الاحتجاز. يقدم خادم MCP اللاحق (downstream) الأثر الجانبي. تفحص حواجز الحماية بعد الأداة النتيجة. توفر التتبعات وسجلات الموافقة سلسلة الأدلة.

يوضح هذا أيضًا العلاقة مع العنصر البشري في المخطط لـ Agent Harness. يمكن لـ Harness إيقاف وكيل مُدار مؤقتًا قبل استدعاء أداة حساسة، وإصدار tool.approval_required، وإنهاء الدورة الحالية، واستئناف الجلسة نفسها عند وصول UserToolApprovalEvent. تفرض الموافقات على أدوات Gateway السياسة عند حدود MCP المشتركة. يمكن لكلاهما إيقاف تنفيذ الأداة شرطيًا؛ وهما يختلفان في دورة الحياة والموقع، ليس لأن أحدهما هو "نقطة تحقق للتفكير" والآخر هو بوابة الأداة الوحيدة.

هناك حدود تستحق التصريح بها بوضوح. الموافقة لا تحل محل التفويض (authorization). لا يزال من الممكن تضليل الإنسان بواسطة وصف أداة مسموم أو وسائط متلاعب بها، لذلك تظل مراجعة القبول وعناصر التحكم على مستوى الوسائط ضرورية. التوضيحات المرفقة بالأداة ليست موثوقة لمجرد أنها تصل عبر MCP. تتداول التراخيص المستندة إلى الوقت المراجعة المكررة مقابل الراحة المحدودة عمداً. يضيف التوافر البشري زمن تأخير ويمكن أن يصبح اعتمادًا على الموثوقية. ولا يمكن لسياسة Gateway تحكيم حركة مرور MCP التي تتجاوز Gateway.

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

المراجع

• مصادر MCP الرئيسية — مواصفات أدوات MCP 2026-07-28 (نموذج تفاعل المستخدم، نتائج input_required، التوضيحات المرفقة بالأداة)؛ إصدار مواصفة MCP 2026-07-28 (امتداد Tasks ونظرة عامة على المراجعة).
• توثيق TrueFoundry — الموافقات على أدوات MCP؛ MCP Gateway؛ العنصر البشري في المخطط لـ Agent Harness؛ الأدوار والمشاركون؛ حواجز حماية MCP قبل/بعد الأداة؛ لوحة قياس المقاييس.
• السياق الهندسي ذات الصلة بـ TrueFoundry — سجل MCP؛ الدفاع ضد تسميم الأدوات؛ التحكم في الوصول القائم على المهام؛ تمرير التفويض؛ الحوكمة والتدقيق.

تم وصف آليات المنتج في هذه المقالة بناءً على توثيق TrueFoundry الحالي؛ وتستند ادعاءات البروتوكول إلى مواصفة MCP 2026-07-28 ومواد الإصدار الرسمية. إن دلالات النتيجة المعلقة وترخيص الموافقة في TrueFoundry هي اتفاقيات على مستوى المنتج، وليست حالات موافقة قياسية في MCP. مقاييس التشغيل الخاصة بالموافقة المقترحة أعلاه هي قياسات يوصى بها، وليست ادعاءات بأن لوحة قياس المقاييس الحالية تعرض مخططات موافقة مخصصة. يمكن أن يتغير سلوك المنتج والتوثيق؛ تحقق من المستندات الحالية قبل التعامل مع أسماء الحقول أو دلالات السياسة كعقد توافق.

‍