شرح انتشار التفويض: لماذا لا يكفي التحكم في الوصول على مستوى الطلب

لقد هيمن هجوم واحد على نقاشات أمن وكلاء الذكاء الاصطناعي لفترة طويلة، وهو حقن الأوامر (prompt injection)، لدرجة أن مشكلة هيكلية أكثر هدوءاً ظلت بلا اسم. والآن أصبح لها اسم: انتشار التفويض، وهو مصطلح طُرح في مسودة بحثية من مؤلف واحد على موقع arXiv في مايو 2026 من قبل Kamiwaza (الذي قدم أدلة تنفيذ أولية)، بعنوان "انتشار التفويض في أنظمة الذكاء الاصطناعي متعددة الوكلاء: حوكمة الهوية كبنية تحتية" (Tallam، arXiv:2605.05440)، التي يمكننا تلخيص أطروحتها في كلماتها الست المقتبسة — "نسمي هذه المشكلة انتشار التفويض" — وإعادة صياغتها في جملة واحدة: بينما يقوم الوكلاء غير البشريين باسترجاع البيانات، وتفويض المهام، وتجميع النتائج عبر حدود متغيرة، تكمن المشكلة الصعبة في الحفاظ على ثوابت التفويض عبر السلسلة، وهي مشكلة لا يمكن اختزالها في حقن الأوامر، ولا تعالجها بالكامل نماذج التحكم في الوصول التقليدية — مثل RBAC وABAC وReBAC — التي تستخدمها المؤسسات بالفعل. يفكك البحث المشكلة إلى ثلاث مشكلات فرعية محددة سيتعرف عليها أي مشغل لأنظمة الوكلاء المتعددة بمجرد ذكرها. التفويض المتعدي: يقوم الوكيل (أ)، المخول بمهمة ما، بتفويض مهمة فرعية للوكيل (ب) — فما الذي يُسمح لـ (ب) بفعله، وبناءً على سلطة من، وما الذي يمنع السلسلة من التوسع عند كل خطوة؟ استنتاج التجميع: كل عملية استرجاع في سير العمل مسموح بها بشكل فردي، ولكن عملية التجميع تنتج شيئاً لم يكن أي طرف مخولاً بالاطلاع عليه بمفرده. الصلاحية الزمنية: كان التفويض صالحاً عند بدء سير العمل — فهل لا يزال صالحاً في الخطوة الأربعين، بعد ساعة من الآن، وبعد إلغاء صلاحية الوصول؟ هذه خصائص على مستوى سير العمل، وليست على مستوى الطلب، وهذا هو السبب الدقيق وراء فشل آليات التحكم في الوصول المعتمدة على الطلب خلال العقدين الماضيين في حلها. هذا الدليل هو المرجع المؤسسي لهذا المصطلح: ما هو انتشار التفويض، ومن أين جاء، وكيف يختلف عن المشكلات التي يُصنف تحتها — والبنية التحتية التي يمكنها دعم ثوابت مختارة للعمليات المشاركة — بينما يظل استنتاج التجميع، وفقاً للبحث نفسه، مشكلة مفتوحة لا تحلها أي بنية حالية بالكامل — وفقاً للعنوان الفرعي للبحث: حوكمة الهوية كبنية تحتية. وكما هو الحال مع جميع مراجعنا للمصطلحات الحديثة، سنبقي هذه الصفحة محدثة مع تطور الأبحاث والمفردات.

ما هو انتشار التفويض؟ تعريف

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

تاريخ موجز: من النواب المرتبكين إلى العناصر غير البشرية

إن أصل المشكلة أقدم من المصطلح بعقود، وهذا جزء من سبب أهمية التسمية. لقد تم وصف النائب المرتبك — وهو برنامج ذو صلاحيات يتم خداعه لإساءة استخدام سلطته نيابة عن المتصل — في عام 1988 وشكل التفكير الأمني القائم على القدرات لجيل كامل؛ كانت تدفقات تفويض OAuth، وتأكيدات SAML، ونقاشات انتحال الشخصية مقابل التفويض في عصر SOA كلها إجابات جزئية لعالم كانت فيه العناصر عبارة عن تطبيقات وكانت السلاسل قصيرة. أضاف العقد الأول من القرن الحادي والعشرين النطاق ولكن ليس الشكل: جعلت الخدمات المصغرة من هوية الخدمة إلى الخدمة تخصصاً (mTLS، وSPIFFE، وهوية عبء العمل)، وبدأت صناعة إدارة الهوية والوصول (IAM) تتحدث عن هويات غير بشرية تفوق في عددها الهويات البشرية. ما تغير في الفترة 2024–2026 هو أن العناصر غير البشرية أصبحت مستقلة وتكوينيةوكلاء يقررون في وقت التشغيل الأدوات التي يجب استدعاؤها، ويُنشئون وكلاء فرعيين بمجموعات جزئية (أو مجموعات شاملة عرضية) من صلاحياتهم، ويقومون بالتوليف عبر كل ما لمسوه — سلاسل طويلة وديناميكية وغير مخطط لها، تماماً بالطرق التي تجاهلتها الآليات التقليدية. تتبعت النقاشات هذا الانحراف بشكل تدريجي — أدلة المصادقة والتفويض لبروتوكول MCP، وأطر عمل انعدام الثقة للوكلاء، وموجة الأمن القائم على الهوية، و </SEGMENT 1] إحصاء هوية الوكيل </SEGMENT 2] — حتى مايو 2026، عندما وضعت ورقة "كاميوازا" (Kamiwaza) إطاراً شاملاً للموضوع برمته: حيث حددت المشكلة، وفصلتها عن الحقن، وأضفت طابعاً رسمياً على المشكلات الفرعية الثلاث، واستنبطت سبعة متطلبات هيكلية للبنى التي تحافظ على الثوابت. ينطبق إطار عملنا القائم على أن التسمية تتبع الممارسة — فكل مؤسسة تدير مهام عمل متعددة الوكلاء تواجه هذه المشكلات الثلاث اليوم، سواء تمت تسميتها أم لا — وعندما تبدأ التسمية، تبدأ أسئلة المشتريات في طرح نفسها بوحدة التحليل الصحيحة، وهي سير العمل، وليس الطلب. </SEGMENT 3]

انتشار التفويض مقابل حقن الأوامر (Prompt Injection)، والتحكم في الوصول القائم على الأدوار (RBAC)، والمصادقة </SEGMENT 4]

هناك ثلاثة تباينات تحدد المصطلح، وكل منها يمثل خطأً شائعاً في التصنيف تمت معالجته. </SEGMENT 5] مقابل حقن الأوامر (Prompt Injection): </SEGMENT 6] الحقن هو هجوم — حيث يتلاعب خصم بوكيل لدفعه إلى إساءة استخدام صلاحيات يمتلكها بشكل شرعي؛ أما إخفاقات الانتشار فلا تحتاج إلى خصم — فالتفويض العادي، والتوليف المفيد، وسير العمل طويل الأمد تنتجها بشكل افتراضي، مما يعني أن النظام قد يكون محصناً ضد الحقن ومع ذلك يظل عرضة للتسريب من خلال آليات الأذونات الخاصة به. تتقاطع هاتان المشكلتان (فالوكيل الذي يتعرض للحقن مع توسيع مجموعة صلاحياته الفعلية يمثل حادثة أسوأ)، لكن حل إحداهما لا يعالج الأخرى، والشكوى الرئيسية في الورقة هي أن تركيز المحادثات الأمنية على الحقن ترك المشكلة الهيكلية دون تسمية. </SEGMENT 7] مقابل التحكم في الوصول القائم على الأدوار/السمات/العلاقات (RBAC/ABAC/ReBAC): </SEGMENT 8] النماذج التقليدية هي لغات سياسات تُطبق في وقت الطلب — وهي مدخلات قوية وضرورية لكنها لا تثبت بحد ذاتها ثوابت مستوى سير العمل، لأن فحص الدور لا يمكنه رؤية الصلاحيات المتراكمة عبر القفزات، والقاعدة الخاصة بكل مورد لا يمكنها رؤية ما جمعه التوليف، والسياسة التي يتم تقييمها في وقت الطلب لا يمكنها رؤية أن سير العمل الذي تنتمي إليه قد بدأ بموجب منح تم إلغاؤها لاحقاً. هذه النماذج هي مدخلات للحل، وليست الحل ذاته: فالثوابت تكمن في طبقة لا تقيمها تلك النماذج. </SEGMENT 9] مقابل المصادقة: </SEGMENT 10] معرفة </SEGMENT 11] من </SEGMENT 12] هو كل طرف — سواء عبر تدفقات OAuth، أو تبادل الرموز، أو هوية عبء العمل — هو المتطلب الأساسي الذي تُبنى عليه هذه المشكلة؛ فالانتشار هو ما يجب أن يظل قائماً </SEGMENT 13] بعد </SEGMENT 14] أن يتم تحديد هوية الجميع بشكل صحيح، ولهذا السبب فإن قول "لدينا نظام تسجيل دخول موحد (SSO) لوكلائنا" يجيب على سؤال مختلف عن ذلك الذي يطرحه هذا المصطلح. ملخص من سطر واحد للتباينات الثلاثة: لقد أمضت الصناعة عامين في تأمين </SEGMENT 15] الطلب </SEGMENT 16] و </SEGMENT 17] الأمر (Prompt) </SEGMENT 18]؛ بينما انتشار التفويض هو أمن </SEGMENT 19] السلسلة </SEGMENT 20].

انتشار التفويض في المؤسسات: حوكمة الهوية كبنية تحتية

هنا يأتي دور TrueFoundry، وقد أوضح العنوان الفرعي للورقة شكل الحجة: لا يمكن الحفاظ على الثوابت من خلال مطالبة كل فريق وكيل بتنفيذها، بل يجب أن تكون خصائص للطبقة التي تعبرها كل دعوة وكيل بالفعل. استعرض المشكلات الفرعية الثلاث مقابل الآلية الموثقة. التفويض المتعدي يُدار حيثما يحدث التفويض: يتدفق نطاق وصول أداة الوكيل عبر بوابة MCP، حيث يعني التفويض لكل مستخدم أن الدعوة اللاحقة تحمل صلاحية صاحب الطلب الأصلي إلى كل نظام — يرى نظام إدارة علاقات العملاء (CRM) أذونات المستخدم، وليس أذونات الوكيل العامة — ويعني التحديد القائم على المهام أن ما يتلقاه الوكيل الذي تم إنشاؤه هو تصريح محدود مشتق من تصريح الأصل، وليس مجموعة تراكمية موسعة؛ يصبح الثابت "قد تضيق الصلاحية، لكنها لا تتسع أبداً" خاصية هيكلية لكيفية إصدار بيانات الاعتماد بدلاً من كونها اتفاقية يتذكرها الفرق، وهو الانضباط الذي يطوره تحليل TBAC و OAuth على مستوى MCP بعمق. الصلاحية الزمنية تصبح خاصية للرمز المميز بدلاً من كونها وعداً بسير العمل: بيانات الاعتماد قصيرة العمر، والمحدثة تلقائياً، والقابلة للإلغاء مركزياً تعني أن المنحة التي تم إلغاؤها في الخطوة الثانية عشرة ستفشل في استدعاء الأداة في الخطوة الثالثة عشرة — يتم إعادة إجراء الفحص عند كل خطوة لأن كل خطوة تعبر المستوى، وهو المكان الوحيد الذي يعني "لا يزال صالحاً الآنيمكن الإجابة عليه بشكل مستمر لسير عمل يتجاوز ظروف بدئه. استنتاج التجميع هو الحالة الصعبة الصريحة — فلا توجد بوابة تحسب حساسية التوليف بشكل عام — ومساهمة البنية التحتية هي جعلها قابلة للحوكمة: على مستوى السلسلة تتبعات الطلبات تسجل عمليات الاسترجاع والاستدعاءات الوسيطة مع هوياتها التي تم حلها — وهي أدلة للمراجعة التدقيقية للعمليات المشاركة، وليست حكماً تلقائياً بالتفويض لما جمعه سير العمل؛ وتفرض حواجز الحماية على مخرجات الأدوات واستجابات النماذج الحدود القابلة للتعبير (فئات معلومات التعريف الشخصية، والمصادر المقيدة التي تنتقل إلى مخرجات غير مقيدة)؛ وطبقة تنسيق الوكلاء المتعددين التي يعمل عليها حوكمة الوكيل إلى الوكيل (A2A) تحافظ على بقاء التنقلات بين الوكلاء على نفس المستوى الخاضع للتدقيق مثل تنقلات الأدوات، بحيث لا تحتوي السلسلة على أي أجزاء غامضة. تدعو الورقة إلى بنى تحتية ذات متطلبات هيكلية؛ وهذا المستوى هو المكان الذي تتوقف فيه تلك المتطلبات عن كونها هندسة خاصة بكل فريق وتصبح مجرد إعدادات.

‍