معمارية التنفيذ المراقَب
Controlled Execution Architecture
تعريف معمارية التنفيذ المراقَب
التعريف: معمارية التنفيذ المراقَب هي إطار أمني لحوكمة تنفيذ المهام الحساسة بواسطة أنظمة الذكاء الاصطناعي، يهدف إلى منع تنفيذ العمليات غير المصرح بها، وفرض نقاط تحقق واضحة قبل الأفعال الخارجية، مع تسجيل الأدلة اللازمة لإثبات سلامة كل عملية.
ما هي معمارية التنفيذ المراقَب؟
معمارية التنفيذ المراقَب هي نموذج معماري يضع طبقة حوكمة وأمان بين نظام الذكاء الاصطناعي وبين تنفيذ الأفعال الحساسة في العالم الخارجي.
لا يكفي أن يقرر المساعد الذكي تنفيذ مهمة ما؛ بل يجب أن تمر العملية عبر مجموعة من الشروط والحواجز التي تحدد الصلاحية، وحالة الطلب، ووجود الموافقة المطلوبة، وعدم وجود تجميد أمني، وتوافر الأدلة اللازمة للتنفيذ.
ويهدف هذا النموذج إلى جعل القرار والتنفيذ والتدقيق عمليات منفصلة وقابلة للتحقق، بحيث لا يمكن اعتبار العملية ناجحة لمجرد أن النظام الذكي أعلن نجاحها.
المكونات الأساسية
1. طلب التنفيذ: يمثل العملية التي يريد النظام تنفيذها، مع بيانات الطلب وإصداره وسياقه.
2. آلة الحالات: تحدد الحالات المسموح بها للطلب والانتقالات القانونية بينها.
3. الحراس: شروط يجب تحققها قبل السماح بالانتقال إلى حالة أخرى.
4. بوابة التنفيذ النهائية: آخر نقطة تحقق قبل تنفيذ الفعل الخارجي.
5. التجميد: آلية تمنع التنفيذ عند وجود خطر أو طلب تجميد.
6. Outbox: طبقة موثوقة لتسجيل الأفعال التي يجب تنفيذها خارجيًا.
7. Idempotency: آلية تمنع تكرار الفعل الخارجي عند إعادة المحاولة.
8. سجل التدقيق: يسجل الأحداث والقرارات والأدلة المرتبطة بكل عملية.
9. Reconciliation: يتحقق من توافق الحالة الداخلية مع نتيجة الفعل الخارجي.
آلة الحالات
تستخدم المعمارية آلة حالات رسمية لمنع الانتقالات غير المصرح بها. لا يجوز للطلب الانتقال مباشرة من حالة أولية إلى حالة تنفيذ حساسة دون المرور بالحالات والحواجز المطلوبة.
| الحالة | المعنى |
|---|---|
REQUESTED |
تم إنشاء الطلب. |
VALIDATING |
يجري التحقق من الطلب والصلاحيات. |
AWAITING_APPROVAL |
الطلب يحتاج إلى موافقة بشرية. |
APPROVED |
تمت الموافقة المطلوبة. |
FROZEN |
تم تجميد الطلب ومنع التنفيذ. |
READY_FOR_EXECUTION |
اكتملت شروط ما قبل التنفيذ. |
EXECUTING |
بدأ الفعل الخارجي. |
COMPLETED |
تم التحقق من اكتمال العملية. |
DENIED |
تم رفض الطلب. |
FAILED |
فشل التنفيذ أو التحقق. |
قواعد الانتقال والحواجز الأمنية
لا يسمح محرك القرار بالقفز بين الحالات بصورة مباشرة أو تجاوز نقطة تحقق إلزامية.
قاعدة المنع:
إذا كان شرط الانتقال غير معروف أو تعذر التحقق منه، تكون النتيجة
DENY
بدلًا من افتراض السماح.
قاعدة التجميد:
وجود
freeze_request
صالح يمنع أي انتقال حساس إلى التنفيذ.
قاعدة الموافقة: العمليات الحساسة التي تتطلب موافقة بشرية لا تنتقل إلى التنفيذ قبل تسجيل الموافقة المطلوبة.
قاعدة الصلاحية: لا يكفي وجود المستخدم أو الوكيل؛ يجب أن تكون الصلاحية محددة ومناسبة للفعل المطلوب.
قاعدة الأدلة: لا يعتبر التنفيذ ناجحًا دون وجود أدلة التنفيذ المطلوبة.
بوابة التنفيذ النهائية
تمثل
Final Execution Gate
آخر نقطة أمنية تفصل النظام الداخلي عن الفعل الخارجي.
يجب على البوابة إعادة تقييم الشروط الحساسة مباشرة قبل التنفيذ، حتى إذا كانت جميع الشروط صحيحة في مرحلة سابقة.
يجب التحقق من:
- حالة الطلب الحالية.
- نسخة الطلب.
- الصلاحية المطلوبة.
- الموافقة البشرية عند الحاجة.
- حالة التجميد.
- سلامة سجل التدقيق.
- وجود Outbox صالح.
- وجود Idempotency Key.
- عدم وجود تعارض أو حالة غير مؤكدة.
إذا فشل أي تحقق، يجب أن تكون النتيجة
DENY
وألا يبدأ الفعل الخارجي.
تجميد الطلب
يستخدم
freeze_request
لإيقاف الطلب ومنع انتقاله إلى تنفيذ حساس عند اكتشاف خطر أو تعارض أو حاجة إلى مراجعة بشرية.
يجب تنفيذ عملية التجميد بصورة ذرّية تمنع السباقات والتزامن غير الآمن بين طلب التجميد ومحاولة التنفيذ.
عند تجميد الطلب يتم إنشاء Security Event مستقل يوضح سبب التجميد والجهة التي أنشأته ووقت حدوثه.
لا يجوز إعادة فتح الطلب تلقائيًا. إعادة الفتح تتطلب مراجعة بشرية موثقة وتسجيل قرار جديد في سجل التدقيق.
إذا كان
freeze_request
سابقًا أو متزامنًا مع محاولة تنفيذ حساسة، فإن النتيجة النهائية يجب أن تكون المنع.
Outbox ومفتاح Idempotency
تستخدم طبقة
Outbox
للفصل بين القرار الداخلي وبين إرسال الفعل إلى النظام الخارجي.
أما
Idempotency Key
فيضمن عدم تنفيذ العملية نفسها أكثر من مرة عند حدوث إعادة محاولة أو إعادة تشغيل للنظام.
يجب أن يكون لكل فعل خارجي حساس مفتاح تنفيذ فريد يمكن استخدامه للتحقق من عدم تكرار العملية.
لا يجوز إنشاء عملية خارجية جديدة لمجرد أن النظام أعيد تشغيله إذا كان المفتاح نفسه قد سجل تنفيذًا سابقًا.
عند وجود حالة غير مؤكدة، يجب الانتقال إلى مسار آمن مثل
DENY
أو
RECONCILIATION_REQUIRED
بدلًا من إعادة التنفيذ بصورة عمياء.
سلسلة سجل التدقيق
يجب أن يكون سجل التدقيق متسلسلًا وقابلًا للتحقق، بحيث يرتبط كل حدث بالحدث السابق من خلال
previous_event_hash
ويحتوي على
current_event_hash
الخاص به.
{
"sequence": 42,
"request_id": "REQ-001",
"event_type": "FINAL_EXECUTION_GATE",
"previous_event_hash": "SHA256_HASH",
"current_event_hash": "SHA256_HASH",
"timestamp": "2026-08-17T00:00:00Z",
"decision": "ALLOW",
"reason": "All execution conditions verified"
}
تعتمد عملية التحقق على تمثيل موحد للبيانات
canonical serialization
ثم حساب
SHA-256
للتحقق من سلامة السلسلة.
عند اكتشاف اختلاف في التسلسل أو التجزئة أو البيانات الأساسية، يجب رفض السجل أو تجميد الطلب المرتبط به وفق سياسة الأمان.
المصالحة والتحقق من نتيجة التنفيذ
لا تعني استجابة النظام الخارجي أن العملية الداخلية أصبحت ناجحة تلقائيًا. يجب التحقق من نتيجة الفعل الخارجي ومقارنتها بالحالة المسجلة داخليًا.
تقوم
Reconciliation
بمراجعة الأدلة المتاحة مثل معرف العملية الخارجية، وحالة Outbox، ومفتاح Idempotency، وسجل التدقيق، ونتيجة النظام الخارجي.
قاعدة أساسية:
لا يجوز اعتبار العملية
COMPLETED
دون وجود أدلة متوافقة تثبت تنفيذ الفعل الخارجي.
عند عدم القدرة على إثبات النتيجة، تبقى العملية في حالة عدم يقين وتخضع للمصالحة بدلًا من اعتبارها ناجحة.
الثوابت الأمنية
تستند المعمارية إلى مجموعة من الثوابت التي يجب ألا تنتهكها أي عملية:
- لا تنفيذ حساس دون المرور عبر
Final Execution Gate. - لا تنفيذ عند وجود تجميد فعال.
- لا تجاوز للحالات الإلزامية.
- لا اعتماد على حالة غير مؤكدة باعتبارها سماحًا.
- لا تنفيذ متكرر للفعل نفسه عند استخدام Idempotency Key صالح.
- لا اعتبار للتنفيذ ناجحًا دون أدلة تشغيلية قابلة للتدقيق.
- لا إعادة فتح تلقائية للطلبات المجمدة.
- كل انتقال حساس يجب أن يترك أثرًا في سجل التدقيق.
- كل قرار رفض يجب أن يحتوي على سبب واضح.
- كل تعارض أمني يجب أن ينتهي إلى المنع أو المراجعة.
اختبارات التكامل
يجب اختبار المعمارية ليس فقط في الحالات الطبيعية، بل أيضًا في ظروف التزامن وإعادة التشغيل والتعارض والعبث بالسجل.
| اسم الاختبار | الهدف |
|---|---|
test_freeze_before_sensitive_transition |
إثبات أن التجميد السابق يمنع الانتقال الحساس. |
test_concurrent_freeze_and_execution |
اختبار التزامن بين التجميد والتنفيذ. |
test_final_execution_gate_blocks_frozen_request |
إثبات أن بوابة التنفيذ النهائية تمنع الطلب المجمد. |
test_idempotency_prevents_duplicate_execution |
منع تنفيذ الفعل الخارجي مرتين. |
test_audit_hash_chain_integrity |
التحقق من سلامة سلسلة التجزئة. |
test_sequence_integrity |
منع فقدان أو تجاوز ترتيب الأحداث. |
test_tampered_audit_record_freezes_request |
تجميد الطلب عند اكتشاف العبث بالسجل. |
test_restart_does_not_duplicate_outbox_action |
منع التكرار بعد إعادة تشغيل النظام. |
test_uncertain_state_denies_execution |
إثبات أن الحالة غير المؤكدة تنتهي إلى المنع. |
معايير القبول
- لا يمكن تنفيذ أي فعل حساس دون المرور عبر
Final Execution Gate. - أي
freeze_requestسابق أو متزامن يمنع التنفيذ الحساس. - لا يمكن تجاوز الحالات المسموح بها في آلة الحالات.
- كل انتقال حساس ينتج سجل تدقيق قابلًا للتحقق.
- سلامة سلسلة الأحداث قابلة للتحقق باستخدام
SHA-256. - يمنع
Idempotencyالتكرار غير المقصود للفعل الخارجي. - حالات عدم اليقين لا تتحول إلى
ALLOWتلقائيًا. - لا تعتبر العملية
COMPLETEDدون أدلة التنفيذ المطلوبة. - لا يمكن إعادة فتح الطلب المجمد دون مراجعة بشرية موثقة.
- جميع حالات الرفض تحتوي على سبب يمكن تدقيقه.
الخلاصة
تقدم معمارية التنفيذ المراقَب نموذجًا لفصل التفكير عن الفعل الخارجي، بحيث لا تتحول قدرة نظام الذكاء الاصطناعي على اتخاذ القرار إلى صلاحية مباشرة لتنفيذ العمليات الحساسة.
وتعتمد المعمارية على آلة حالات رسمية، وحواجز انتقال، وموافقة بشرية عند الحاجة، وتجميد ذري للطلبات، وبوابة تنفيذ نهائية، وOutbox، وIdempotency، وسجل تدقيق متسلسل، ومصالحة للتحقق من النتائج.
الفكرة الأساسية: في الأنظمة الذكية الآمنة، لا يكفي أن يكون القرار صحيحًا؛ بل يجب أن يكون التنفيذ نفسه مصرحًا به، قابلًا للإيقاف، قابلًا للإثبات، وقابلًا للتدقيق.