TBAC: التحكم في الوصول القائم على المهام لعصر الوكلاء الذكي

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

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

1. تاريخ موجز وصادق لنماذج التحكم في الوصول (BACs)

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

ABAC — التحكم في الوصول القائم على السمات، والذي تمت معالجته بشكل أساسي في معيار NIST SP 800-162 — استبدل البحث عن الأدوار بتقييم السياسات بناءً على سمات الموضوع، والمورد، والإجراء، والبيئة: اسمح إذا كان القسم = المالية والتصنيف ≤ داخلي وساعات العمل. إنه يشتري المرونة على حساب تعقيد صياغة السياسات، وكما تشير تحليلات أمن الوكلاء، فإنه يقيم السياق بشكل جيد ولكنه لا يفهم بطبيعته القصد خلف الطلب. ReBAC — التحكم في الوصول القائم على العلاقات، والذي اشتهر بفضل ورقة بحث "زانزيبار" من جوجل — يستمد الأذونات من علاقات الرسم البياني: يمكنك تعديل هذا المستند لأنك تمتلك المجلد الأصل الخاص به. وإلى جانب ذلك، يوجد التحكم في الوصول القائم على السياسات (PBAC) كمظلة لنهج محركات السياسات، والوصول في الوقت المناسب من إدارة الوصول المميز — وهو تصور، من عالم البشر، للأذونات محدودة المدة. كل نموذج من هذه النماذج يجيب على سؤال "من أنت، وما الذي يمنحك إياه هذا؟" — ويتم توفيره قبل بدء العمل. وهذا هو بالضبط الافتراض الذي تنتهكه الوكلاء (العملاء الأذكياء).

2. لماذا تكسر الوكلاء التحكم في الوصول المتمحور حول الهوية

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

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

3. دخول TBAC: فكرة قديمة حان وقتها أخيراً

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

توسع الصيغ الحديثة المفهوم الأصلي في اتجاهين. إن إطار عمل Cisco Outshift — الذي يعتمد على الأداة والمعاملة والمهمة — يضع TBAC صراحةً كطبقة تتجاوز RBAC وABAC وReBAC للذكاء الاصطناعي الوكيل: تفويض لا يقتصر على هوية الوكيل، بل على الأدوات التي يمكنه استدعاؤها، والمعاملات التي يمكنه إكمالها، والمهمة التي ينفذها. تبحث الأبحاث الحالية في كيفية تقييم "المهمة" من الأساس: يستخدم بحث arXiv نموذج لغة كبيراً (LLM) كقاضٍ مدرك لعدم اليقين لتحديد ما إذا كان الإجراء يخدم المهمة المصرح بها — وهو نهج واعد ومبكر وصريح بشأن مشكلاته المفتوحة. بين إجماع الممارسين والأبحاث، يظهر تعريف عملي. يعني TBAC في عصر الوكلاء: حزمة أذونات لكل مهمة (الحد الأدنى من الأدوات والبيانات لهذا الهدف)، ربط المدة (بيانات اعتماد قصيرة العمر ومحددة بنطاق المهمة مع صلاحية تنتهي في دقائق)، توثيق التفويض (تحمل المهمة هوية من فوضها، وبالنيابة عن من)، و نقاط التحقق من المعاملات (الخطوات غير القابلة للتراجع تخضع لبوابة صريحة). لا شيء من هذا يحل محل النماذج القديمة، بل يرتكز فوقها، وهي الرؤية التصميمية التي توضحها الأقسام التالية.

4. النموذج الطبقي: حيث لا يزال لكل نموذج وصول (BAC) مكانه المستحق

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

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

‍

‍