Atomic Decision Boundaries: A Structural Requirement for Guaranteeing Execution-Time Admissibility in Autonomous Systems

ملخص تقني لورقة: "الحدود القرارية الذرية: متطلب هيكلي لضمان القبول وقت التنفيذ في الأنظمة المستقلة" بقلم مارسيلو فرنانديز.

1. بيان المشكلة

تقوم الأنظمة المستقلة بشكل متزايد بتنفيذ إجراءات تُعدّل الحالة المشتركة بشكل غير قابل للتراجع (مثل: التحويلات المالية، استدعاءات واجهة برمجة التطبيقات API، عمليات الملفات). تعمل آليات الحوكمة الحالية (مثل RBAC وOPA وغيرها) عادةً وفق نموذج تقييم منقسم:

1. التقييم: يقوم محرك السياسات بالتحقق مما إذا كان الإجراء مقبولاً بناءً على الحالة الراهنة للنظام ($s_{eval}$).
2. التنفيذ: إذا كان مسموحاً به، يتم تنفيذ الإجراء، مما ينقل النظام إلى حالة جديدة ($s_{exec}$).

المشكلة الجوهرية: في البيئات المتزامنة، يمكن للحالة أن تتغير بين التقييم والتنفيذ نتيجة لأفعال البيئة غير المنضبطة (مثل: قيام وكيل آخر بتعديل مورد مشترك). هذا يخلق فجوة "وقت التحقق/وقت الاستخدام" (TOCTOU). فالإجراء الذي يُعتبر "مقبولاً" عند $s_{eval}$ قد يصبح "غير مقبول" عند $s_{exec}$. وتجادل الورقة بأن أي قدر من تحسين السياسات أو إثراء الحالة الخارجية لن يحل هذه المشكلة إذا ظل الهيكل "منقسماً"، لأن الفجوة هي فجوة هيكلية وليست معلوماتية.

2. المنهجية والنموذج الصوري

قام المؤلف بصياغة المشكلة باستخدام أنظمة الانتقال المسمى (LTS) للتمييز بين فئتين من أنظمة الحوكمة:

• أنظمة الحدود القرارية الذرية (Atomic Decision Boundary Systems):
  • يتم حساب القرار (سماح/رفض/تصعيد) وانتقال الحالة الناتج عنه كخطوة واحدة غير قابلة للتجزئة في نظام الانتقال المسمى (LTS).
  • تُعرف صورياً عبر دالة $F: S \times A \to D \times S$ حيث يتم تقييم القبول وتطبيق الانتقال في آن واحد. لا يمكن لأي فعل من أفعال البيئة أن يتخلل ما بين عملية التحقق وعملية الالتزام (Commit).
• أنظمة التقييم المنقسمة (Split Evaluation Systems):
  • دالة القرار $D$ ودالة الانتقال $T$ هما انتقالان منفصلان في نظام (LTS).
  • يتبع التنفيذ التسلسل التالي: $s \xrightarrow{dec} s_D \xrightarrow{env} s^* \xrightarrow{exec} s'$.
  • من الضروري أن أفعال البيئة ($e \in A_{env}$) يمكن أن تتخلل ما بين انتقال القرار وانتقال التنفيذ، مما قد يغير الحالة من $s$ إلى $s^*$.

الافتراضات الرئيسية:

1. عدم التبسيط (Non-Triviality): القبول يعتمد على الحالة، والحالة يمكن أن تتغير.
2. بيئة معادية (Adversarial Environment): أفعال البيئة غير منضبطة ويمكن أن تتخلل العمليات في أسوأ لحظة ممكنة (وهو افتراض قياسي في الأنظمة المتزامنة).

نتيجة "التصعيد" (Escalate):
قدمت الورقة مجال قرار ثلاثي القيم $D = \{Allow, Refuse, Escalate\}$.

• التصعيد (Escalate): يعلق الانتقال للمراجعة من قبل المشرف.
• رؤية جوهرية: التصعيد لا يحل مشكلة الذرية (Atomicity)، بل ينقل فقط حد القرار إلى المشرف. ويجب أن يكون قرار المشرف نفسه "ذرياً" لضمان القبول.

3. المساهمات الرئيسية

1. التعريف الصوري للقبول: تعريف القبول ليس كخاصية للإجراء في حد ذاته، بل كخاصية لـ الحالة في اللحظة الدقيقة للالتزام بالانتقال.
2. التصنيف الهيكلي: التمييز بين الأنظمة الذرية والأنظمة المنقسمة بناءً على طوبولوجيا نظام الانتقال المسمى (LTS) (وتحديداً وجود حالة وسيطة معرضة للبيئة).
3. مبرهنة عدم التكافؤ (النتيجة الرئيسية): إثبات أنه تحت افتراضات التزامن الواقعية، لا يمكن لأي نظام منقسم أن يكون مكافئاً لنظام ذري فيما يتعلق بالحفاظ على القبول.
   • البرهان: استخدام مثال مضاد بنائي يوضح مساراً (trace) ينفذ فيه النظام المنقسم انتقالاً غير مقبول لأن الحالة تغيرت بين قرار "السماح" وبين التنفيذ.
4. متطلب إغلاق التصعيد (Escalation Closure Requirement): إثبات أن نتيجة "التصعيد" تحافظ على ضمانات السلامة إذا وفقط إذا كانت عملية حل المشرف نفسها ذرية.
5. توصيف الأنظمة: تصنيف آليات الحوكمة الحالية (مثل RBAC و OPA و AWS IAM و Cedar) كـ أنظمة منقسمة، وتحديد بروتوكول التحكم في الوكيل (ACP) كـ نظام ذري.

4. النتائج والمبرهنات الرئيسية

• المبرهنة 5.1 (عدم التكافؤ): لأي نظام تقييم منقسم، يوجد مسار تنفيذ يتم فيه تنفيذ إجراء في حالة غير مقبولة، بينما كان النظام الذري سيمنع هذا الانتقال نفسه.
• النتيجة 5.3: الأنظمة المنقسمة لا يمكنها ضمان القبول وقت التنفيذ تحت جميع المسارات.
• النتيجة 5.4: إضافة حالة خارجية (مثل قراءة سجل أقفال مشترك) لا يعيد الذرية؛ فالفجوة تظل قائمة لأن القراءة والكتابة تظلان عمليتين منفصلتين.
• النتيجة 5.6: التصعيد ليس حلاً بديلاً. إذا قام المشرف بحل طلب مُصعد، فإن هذا الحل يجب أن يكون ذرياً (القرار + التنفيذ مقترنان) للحفاظ على الضمان.

5. الأهمية والآثار المترتبة

• تحول هيكلي: تجادل الورقة بأن "السياسات الأفضل" أو "الفحوصات الأسرع" ليست كافية. لضمان السلامة في الأنظمة المستقلة متعددة الوكلاء، يجب أن يفرض الهيكل نفسه الذرية عند حد القرار.
• الاستقلال عن التنفيذ: الذرية هي خاصية هيكلية، وليست تفصيلاً تنفيذياً. سواء تم تحقيق ذلك عبر معاملات قواعد البيانات (Database Transactions)، أو عمليات المقارنة والتبديل (CAS) على مستوى العتاد، أو رموز البروتوكول، يجب على النظام ضمان أن فحص السياسة وتعديل الحالة هما عملية واحدة غير قابلة للتجزئة.
• محدودية الأدوات الحالية: الأدوات واسعة الاستخدام مثل OPA و RBAC و AWS IAM عاجزة هيكلياً عن توفير ضمانات القبول وقت التنفيذ في البيئات المتزامنة لأنها تفصل بين القرار والتنفيذ.
• تأسيس للعمل المستقبلي: تعمل هذه الورقة كحجر أساس نظري (الورقة 0) لسلسلة من الأوراق حول حوكمة الوكلاء، وتحديداً لتبرير تصميم بروتوكول التحكم في الوكيل (ACP) (الورقة 1)، الذي ينفذ هذا الحد الذري باستخدام "رموز تنفيذ" (Execution Tokens) أحادية الاستخدام.

6. الخاتمة

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