قالب سجل تصميم مصيدة لوكيل ذكاء اصطناعي

⚡ الخلاصة السريعة

الهدف ليس زيادة عدد المصائد؛ بل القدرة على تفسير الحدث والاحتواء وإثبات أن النشر آمن.

قالب سجل تصميم مصيدة لوكيل ذكاء اصطناعي

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

1. هوية سجل تصميم المصيدة

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

حقول التسجيل الإلزامية: المعرف، القيمة أو المرجع، مصدر الإثبات، مالك القرار، حالة المراجعة، التاريخ، ملاحظة عدم اليقين عند وجودها.

2. الغرض والأصل المحمي

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

3. تعريف الوكيل وسلطته

اجعل Agent ID وإصدار النموذج واسم التطبيق وبيئة النشر واسم مالك العملية وروابط أدواته حقولًا مستقلة. سجّل نطاق السلطة المعتمدة، ومن أصدر التفويض، وموعد انتهائه، وما إذا كان الوكيل يستطيع استدعاء وكلاء آخرين. أرفق مرجع IAM الفعلي وAccess Token Scope دون تخزين الرمز نفسه. حدد الفرق بين الإذن التقني وبين السلطة التشغيلية؛ فوجود صلاحية قراءة عامة داخل خدمة لا يجيز استخدامها لأي غرض. إذا كان الوكيل يستعير هوية مستخدم، يجب معرفة ما إذا كان التفويض يشمل الوصول نيابة عنه في المهمة الحالية أم يعتمد فقط على تسجيل الدخول.

4. سيناريو الخداع ونقطة الظهور

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

5. حدود السلامة وعدم التأثير

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

6. تعريف المحفز Trigger

اكتب الشرط الفني القابل للقياس الذي ينشئ الحدث: API operation محددة، أو استخدام Credential ID خداعي، أو تعديل Resource معرف مسبقًا. لا يكفي حقل «استخدام غير مصرح»؛ هذا حكم يحتاج دليلًا. أضف شروط استبعاد Known Benign Operations، وكيفية التعامل مع الأنظمة التي تفحص الملفات أو تختبر الاعتمادات دوريًا. يجب أن يحمل المحفز Event ID مستقلًا ورابطًا إلى معرف الوكيل والجلسة، مع وقت خادم موثوق. حدّد ما إذا كان الشرط يعتمد على المقارنة مع السياسة أو على مجرد الاتصال بمورد لا ينبغي استعماله، وبيّن الفرق في قوة الدليل.

7. المراقبة والإسناد

عرّف مصادر Telemetry المطلوبة، وكيف تُربط الـTool Call بالـAgent Run والطلب البشري الأصلي. حدد ما إذا كانت هناك هوية مشتركة تستخدمها عدة خدمات، وما الحقول البديلة اللازمة لفصلها. يمكن أن تخزن أحداثاً من Gateway وIdentity Provider ونظام التطبيق ومراقبة الأدوات، بشرط توحيد الوقت وتعريف قواعد الربط. يجب كشف حالات عدم اكتمال Attribution بدل افتراض أن آخر مستخدم سجّل دخوله هو المسؤول. دوّن سياسة منع العبث بالسجلات، وإجراءات فحص انقطاع Telemetry، ومخاطر فقد أحداث النشاط السريع في أنظمة الوكلاء.

8. التنبيه والمستلمون

حدد Alert Severity مع تبرير مستمد من الفعل والضرر المحتمل، وليس من كون المصيدة موجودة. عرّف فريق الاستلام الأساسي والبديل ووقت التغطية خارج ساعات العمل وزمن الاستجابة المستهدف. ينبغي أن تظهر في التنبيه تفاصيل كافية لبدء الاحتواء من دون تسريب أسرار أو نسخ مستندات شخصية. ضمّن رابط Run والحدث والسياسة وبيئة العمل ومالك الخدمة. إذا تكرر المحفز من نفس الوكيل، عرّف آلية التجميع حتى لا تتحول عشرات الأحداث إلى عشرات قضايا منفصلة بلا معنى. لا تخفِ التكرار الذي يدل على محاولات جديدة؛ استخدم Timeline ضمن قضية واحدة مع عدادات مستقلة.

9. خيارات الاحتواء

يجب أن يسجل التصميم الإجراء المسموح آليًا عند كل درجة خطورة: حظر Tool Call أو تعليق Run أو إبطال Credential أو طلب موافقة بشرية. ضع قاعدة صريحة للأفعال التي تتطلب تدخل مالك النظام حتى لا يتحول ضابط أمني إلى توقف إنتاجي غير مأذون. اختبر نقطة Enforcement خارج النموذج نفسه؛ الطلب النصي إلى الوكيل «توقف» ليس إيقافًا مضمونًا. افحص المهام الخلفية والجلسات والاعتمادات المشتركة. اربط قرار الإيقاف بحدود القدرة على التراجع وبالآثار على أطراف أخرى من الخدمة، ثم حدّد إجراء استعادة مشروطًا بنتيجة التحقيق.

10. جمع الأدلة

حدّد الأدلة التي ينبغي التقاطها عند الحدث: طلب المهمة، نسخة السياسة، معرف الوكيل، طلب الأداة، الاستجابة، مصدر المدخلات، وسجل التفويض. استخدم Evidence Reference وبصمات Hash وفق نظام حفظ المؤسسة ولا تنسخ الأسرار إلى الجداول العامة. سجل صاحب الصلاحية للاطلاع ومدة الاحتفاظ والتاريخ المتوقع للحذف. يجب دعم مراجعة مستقلة تستطيع إعادة بناء ترتيب الأفعال من مصادر أولية، لا من تلخيص توليدي فقط. إن تعذر جمع أحد الأدلة المطلوبة فضع فجوة واضحة واستجابة بديلة بدل اعتبار القضية مكتملة تلقائيًا. افصل سجل الواقعة عن تفسير دوافعها.

11. الاختبارات السلبية والإيجابية

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

12. مقاييس النجاح وحدود التفسير

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

13. مراجعة التغيير وإلغاء المصيدة

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

14. قرار القبول وتوقيع المسؤولين

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

اختبار القبول النهائي

لا يُعتمد السجل إلا بعد إثبات أن المورد الوهمي لا يؤدي إلى ضرر حقيقي، وأن Trigger قابل للإسناد إلى السياق الصحيح، وأن سلوك الوكيل المشروع لا يعطل، وأن الاستجابة والتراجع مختبران. يجب الاحتفاظ بتاريخ النسخة وتاريخ الإلغاء والتغيير. المصدر: IAPS — Honeypots for AI Agent Insider Threats.