التهديد الداخلي لوكلاء الذكاء الاصطناعي: عندما يصبح الذكاء المصرّح له مصدر الخطر

لماذا نحتاج إلى مفهوم جديد للتهديد الداخلي؟

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

تقرير Honeypots for AI Agent Insider Threats يصف هذا التحول بوضوح: كلما اتسع استخدام الوكلاء في كتابة الكود وإدارة البنية التحتية والتعامل مع المعلومات الحساسة، نشأ شكل جديد من مخاطر الـInsider. التقرير لا يعرّف المشكلة على أنها «وكيل شرير» فقط، بل يقسم الطرق التي قد يتحول بها الوكيل إلى مصدر خطر إلى ثلاثة مسارات رئيسية: الخطأ، وسوء المواءمة، والاختراق العدائي. هذه الثلاثية مهمة لأنها تمنع المؤسسة من اختزال كل حادث في تفسير واحد.

من منظور سيادة، السؤال الحاكم هو:

هل الفعل الذي نفذه الوكيل كان داخل الهدف والتفويض ونطاق السلطة والسياق الذي اعتمدته المؤسسة؟

هذا السؤال أدق من سؤال: هل كان لدى الوكيل Permission؟

فالـPermission تصف قدرة تقنية. أما الحوكمة فتحتاج إلى معرفة إن كانت ممارسة هذه القدرة مشروعة في ذلك السياق، لذلك يجب فصل أربع طبقات على الأقل:

Identity → Access → Authority → Action

الهوية تجيب: من هو الفاعل؟

الوصول يجيب: ما الذي يستطيع الوصول إليه تقنيًا؟

السلطة تجيب: ما الذي فوضته المؤسسة أن يفعله؟

الفعل يثبت: ماذا فعل فعليًا؟

الخطر الداخلي يظهر عندما لا تتطابق هذه الطبقات.

الوكيل كـInsider لا كأداة فقط

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

يمكن أن يملك الوكيل مثلًا حق قراءة Repository وفتح Pull Request والوصول إلى بيئة CI/CD. هذه الصلاحيات قد تكون منطقية لمهمة تطوير. لكن نفس الصلاحيات قد تسمح له، تقنيًا، بتعديل ملف إعداد حساس أو إدخال Dependency غير معتمدة أو محاولة الوصول إلى Secret لا تحتاجه المهمة. هنا لا توجد بالضرورة مشكلة Authentication؛ المشكلة هي استخدام وصول مشروع خارج السلطة المقصودة.

ولهذا فإن Agent Insider Risk ليس مرادفًا لـCyberattack التقليدي. بعض الحالات قد تكون Attack فعلًا، لكن بعضها قد يكون خطأ تشغيليًا، وبعضها نتيجة تعليمات ملتبسة، وبعضها نتيجة compromise خارجي، وبعضها سلوكًا أكثر تعقيدًا يحتاج تحقيقًا قبل الحكم على سببه.

المسار الأول: الخطأ Mistake

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

مثال مؤسسي: وكيل عمليات طُلب منه تنظيف موارد مؤقتة بعد اختبار. لديه صلاحية حذف موارد في حساب سحابي. إذا فشل في تمييز Resource Group الاختبار عن الإنتاج، قد ينفذ حذفًا صحيحًا تقنيًا لكنه خاطئ حوكميًا. لم يسرق Credential ولم يتجاوز IAM؛ إنما مارس قدرة مسموحة في سياق غير مسموح.

هذا يكشف قصور الاعتماد على Access Control وحده. الضابط المطلوب هنا قد يكون Context-bound Authority: السلطة لا تُمنح للحذف عمومًا، بل للحذف داخل Environment محدد وعلى Resources تحمل خصائص محددة وبعد تحقق مسبق.

المسار الثاني: سوء المواءمة Misalignment

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

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

هذه النقطة حاسمة لأن التحقيق في Misalignment بعد وقوع حادث لا يبدأ من التخمين النفسي حول النموذج، بل من Evidence: تسلسل الأفعال، المدخلات، الأدوات المستدعاة، الصلاحيات المستخدمة، حالات النظام، التغييرات المنفذة، ونتائج كل مرحلة.

المسار الثالث: Adversarial Compromise

قد يكون الوكيل نفسه هدفًا لمهاجم خارجي. Prompt Injection، محتوى غير موثوق، تعليمات مزروعة في Repository أو مستند، Credential مسروق، Tool أو MCP Server مخترق، Dependency خبيثة، أو خدمة خارجية تعيد بيانات مصممة لتغيير السلوك؛ كلها قد تحول الوكيل الموثوق إلى قناة تنفيذ داخلية.

هذا السيناريو خطير لأن المؤسسة قد ترى في السجلات هوية الوكيل الشرعية وليس هوية المهاجم. من منظور IAM، العملية قد تبدو طبيعية: Token صالح، Role صالح، API request صحيح. لكن مصدر القرار أو الاتجاه الذي قاد إليه قد يكون عدائيًا.

هنا يصبح Attribution أكثر تعقيدًا. يجب ألا يقتصر السجل على «من أرسل الطلب؟»، بل يحتاج إلى ربط الفعل بالسياق: المهمة، الـprompt أو instruction source، البيانات غير الموثوقة التي دخلت السياق، الأداة المستخدمة، نسخة النموذج، الجلسة، السياسات، وقرار السماح أو المنع.

Threat Pathway: كيف يتحول الوصول المشروع إلى ضرر؟

يمكن تمثيل مسار التهديد الداخلي للوكيل بسلسلة عملية:

Authorized Identity → Legitimate Access → Trigger/Instruction → Agent Decision → Tool Invocation → Sensitive Action → Impact

التحكم التقليدي يركز غالبًا على أول مرحلتين: هل الهوية صحيحة؟ وهل لديها Permission؟

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

لهذا نحتاج إلى Authority Enforcement وليس IAM فقط. السلطة يجب أن تقيد ما يمكن للوكيل فعله داخل المهمة نفسها، لا أن تمنحه مجموعة Permissions ثابتة ثم تتوقع أن يستخدمها بحكمة دائمًا.

Access ليس Authority

سيادة تميز بين Effective Access وAgent Authority. هذا التمييز يصبح مركزيًا في Insider Threat.

إذا كان الوكيل يستطيع تقنيًا:

• قراءة كل ملفات الفريق.
• تعديل Repository.
• إنشاء Cloud Resources.
• إرسال بريد خارجي.
• استدعاء نظام دفع.

لكن مهمته الحالية تتطلب فقط قراءة ثلاثة ملفات وإنشاء Draft، فإن القدرة التقنية أوسع من السلطة الفعلية المطلوبة. الفرق بينهما هو مساحة خطر.

يمكن تسمية هذه المساحة Authority Gap: الفرق بين السلطة المعتمدة والسلطة القابلة للممارسة فعليًا. كلما اتسعت، زادت الخيارات التي يستطيع الوكيل اتخاذها خارج المقصود حتى لو بقي داخل حساب شرعي.

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

لماذا لا تكفي المراقبة التقليدية وحدها؟

Action Monitoring ضرورية، لكنها تواجه مشكلة الحجم والسياق. الوكيل قد ينفذ آلاف الأفعال المشروعة. اكتشاف فعل ضار بينها يتطلب معرفة ما إذا كان الفعل مناسبًا للهدف الحالي، وليس فقط ما إذا كان نادرًا أو تقنيًا خطيرًا.

التقرير يوضح أن مراقبة الأفعال تغطي مسارات أوسع من Honeypots، لكنها تنتج حجمًا كبيرًا من النشاط الذي يحتاج إلى فرز. كذلك فإن مراقبة Chain-of-Thought أو reasoning ليست أساسًا مضمونًا طويل الأجل؛ قد تصبح reasoning traces أقل إتاحة أو أقل قابلية للتفسير أو أكثر قابلية للإخفاء.

النتيجة ليست التخلي عن المراقبة، بل بناء Control Stack متعدد الطبقات:

Least Agency → Identity → Access Control → Authority Enforcement → Runtime Monitoring → Honeypots/Decoys → Containment → Investigation → Remediation

كل طبقة تعالج نوعًا مختلفًا من عدم اليقين.

ما هو Agent Honeypot؟

التقرير يعرّف Agent-focused honeypots باعتبارها فرصًا وهمية لتنفيذ أفعال غير مصرح بها تُزرع داخل بيئة الإنتاج. هذه الصياغة أوسع من مفهوم Honeypot التقليدي كخادم مزيف. قد يكون الـdecoy:

• Credential وهميًا يبدو صالحًا للاستخدام.
• ملفًا لا يوجد سبب مشروع لفتحه.
• Server أو endpoint وهميًا.
• موردًا إداريًا لا يدخل في مهمة الوكيل.
• Vulnerability ظاهرية داخل Sandbox.
• رسالة مصطنعة من Agent آخر تقترح تعاونًا غير مصرح به.
• فرصة وهمية لتجاوز مسار موافقة أو استخراج أصل حساس.

القيمة هنا أن التفاعل مع الـdecoy يمكن أن ينتج إشارة عالية الثقة إذا صُمم جيدًا، لأن الفاعل الطبيعي المنضبط لا يحتاج إلى لمسه أصلًا.

لكن يجب الانتباه إلى عبارة «إذا صُمم جيدًا». Decoy سيئ التصميم قد يخلق False Positives إذا كان قريبًا من مسار عمل مشروع، أو قد يصبح واضحًا جدًا فيتعلمه الوكيل ويتجنبه دون أن يعني ذلك أنه آمن.

ثلاث استراتيجيات مختلفة: Detection وIncrimination وDeterrence

أحد أهم أجزاء التقرير أنه لا يتعامل مع Honeypots كوظيفة واحدة. يميز بين ثلاث استراتيجيات يجب ألا تخلط المؤسسة بينها.

Detection

الهدف هو التقاط فعل غير مصرح به. إذا استخدم الوكيل Honey Credential أو حاول الوصول إلى مورد decoy لا توجد له حاجة مشروعة، يولد الحدث Alert. التقرير يعتبر Detection الاستراتيجية ذات قاعدة الأدلة الأقوى بين الثلاث، ويرى أنها قابلة للتجريب اليوم بتكلفة منخفضة نسبيًا.

ميزة Detection ليست التغطية الشاملة. على العكس، تغطيتها محدودة بالمسارات التي زرعت فيها المؤسسة Decoys. ميزتها هي جودة الإشارة: تفاعل مع مورد لا وظيفة مشروعة له يمكن أن يكون أكثر وضوحًا من تحليل آلاف الاستدعاءات العادية.

Incrimination

هنا لا يكون الهدف مجرد اكتشاف Action، بل جمع Behavioral Evidence يساعد المؤسسة على معرفة إن كانت أمام حادث عابر أم نمط أكثر إثارة للقلق. يمكن تصميم بيئة وهمية تتيح للوكيل فرصة آمنة نسبيًا للكشف عن سلوك كان سيصبح ضارًا لو حدث على أصل حقيقي.

لكن التقرير أكثر تحفظًا هنا. قاعدة الأدلة أضعف من Detection، ولا يكفي Honeypot Trigger وحده لاستخلاص نية الوكيل أو سببه. يلزم التحقيق في logs وreasoning traces إن كانت متاحة وبيانات الجلسة والسياق المحيط.

بالتالي القاعدة العملية هي:

Trigger = Evidence of interaction, not proof of malicious intent.

أي تفعيل الـHoneypot يثبت حدثًا يجب التحقيق فيه؛ لا يثبت تلقائيًا أن النموذج «قصد» الضرر.

Deterrence

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

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

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

لماذا تكون Honeypots مفيدة داخل Control Stack؟

التقرير يطرح أربع فوائد رئيسية يمكن تحويلها إلى متطلبات تصميم عملية.

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

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

الثالثة: Benchmark للـmonitoring. Trigger مستقل نسبيًا يمكن استخدامه لمعرفة هل أنظمة المراقبة الأخرى التقطت المسار نفسه أم لا. إذا مر التفاعل مع Decoy ولم ينتبه Runtime Monitor، فهذه فجوة يجب التحقيق فيها.

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

ماذا يحدث بعد Trigger؟

أضعف تطبيق محتمل هو Honeypot يرسل Email Alert ولا يحدث شيء آخر. القيمة الحقيقية تبدأ بعد التفعيل.

التدفق المطلوب يجب أن يكون محددًا مسبقًا:

Trigger → Immediate Containment → Evidence Preservation → Attribution → Investigation → Root Cause → Remediation → Controlled Recovery

Immediate Containment

بحسب حساسية الـdecoy، قد يحتاج النظام إلى:

• Pause للوكيل.
• تعليق Session.
• سحب Token.
• منع Tool معينة.
• خفض Authority Envelope.
• عزل Workspace أو Container.
• منع اتصال خارجي.
• تحويل المهمة إلى Human Review.

لا ينبغي أن تكون الاستجابة واحدة لكل Trigger. Honey Credential في بيئة إنتاج حساسة قد تبرر استجابة أقوى من Decoy منخفض الخطورة داخل Sandbox.

Evidence Preservation

قبل تنظيف البيئة يجب حفظ ما يكفي لإعادة بناء الحادثة:

• Agent identity.
• Session/run ID.
• المهمة الأصلية.
• التعليمات الداخلة.
• Tool calls.
• timestamps.
• network connections.
• الملفات أو الموارد التي لُمست.
• Credentials المستخدمة.
• policy decisions.
• approvals/denials.
• model/version/configuration.
• state قبل وبعد الحدث.

إذا حذفت المؤسسة الجلسة فورًا من دون حفظ state، قد تفقد الدليل الذي يفسر السبب.

Attribution

Attribution لا يعني فقط اسم الـAgent. يجب تحديد أي Instance وأي Run وأي Credential وأي Tool وأي Host وأي Container وأي سلسلة تفويض نفذت الفعل. Shared credentials تضعف هذه القدرة بشدة، ولذلك فإن Agent Identity المنفصلة ليست رفاهية؛ هي شرط للتحقيق.

Investigation

التحقيق يجب أن يختبر بدائل متعددة بدل الوصول مباشرة إلى استنتاج «Agent malicious». يمكن أن يكون السبب:

• خطأ في المهمة.
• سوء تفسير.
• Prompt Injection.
• Tool compromise.
• Credential leakage.
• Policy gap.
• Authority Gap.
• Misalignment محتمل.
• خطأ بشري في إعداد الـdecoy نفسه.

المطلوب جمع evidence يسمح باستبعاد الفرضيات تدريجيًا.

أين تفشل Honeypots؟

التقرير واضح في حدود هذه التقنية، وهذه الحدود يجب أن تبقى جزءًا من التصميم لا هامشًا في نهاية الصفحة.

أولًا، Honeypots ضعيفة أمام Diffuse Misbehavior؛ أي الضرر الذي يتراكم عبر مئات أو آلاف الأفعال الصغيرة التي تبدو منفردة عادية. مثال ذلك إدخال أخطاء صغيرة في مخرجات متعددة أو تحريف تدريجي في بحث أو بيانات. لا توجد بالضرورة لحظة واحدة يمكن وضع Trap واضح عندها.

ثانيًا، يمكن أن يحدث الضرر داخل Authorized Scope بالكامل. إذا كان الوكيل مخولًا بتعديل ملفات معينة، فقد يضيف تغييرًا خبيثًا أو سيئًا داخل ملف مشروع من دون لمس أي Decoy. هنا نحتاج إلى Output Validation وCode Review وBehavioral Monitoring، لا Honeypot فقط.

ثالثًا، Honeypots تغطي المسارات التي يستطيع المدافع تصورها. الهجوم الإبداعي الذي يسلك طريقًا لم يخطر على المصمم قد لا يواجه Decoy أصلًا.

رابعًا، Trigger لا يكشف motive وحده. الحدث يستدعي التحقيق ولا يغنيه.

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

معركة البيئة المعرفية Epistemic Environment

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

هذا يحول Honeypot من ملف وهمي ثابت إلى جزء من تصميم بيئة معرفية. إذا كان الـAgent يستطيع بسهولة سؤال API جانبية تكشف أن Server غير حقيقي، فالـdecoy ضعيف. وإذا كانت محاولة التحقق نفسها غير طبيعية بالنسبة للمهمة، يمكن أن تصبح محاولة الكشف Signal إضافية.

لكن هذا يفتح خطرًا آخر: استخدام AI نفسها لتصميم أو صيانة Honeypots قد يساعد على التوسع، لكنه يخلق سؤال Trust. إذا استخدمت المؤسسة نموذجًا غير موثوق لتصميم decoys ضد نماذج أخرى، فقد ينتج أنماطًا يسهل اكتشافها أو يهمل مسارات هجوم. الحل ليس منع AI-assisted design، بل فرض مراجعة مستقلة، استخدام Model Families مختلفة عند الحاجة، وقياس أداء الـhoneypot تجريبيًا بدل الاعتماد على وصف النموذج له.

من Honeypot إلى Authority Violation Sensor

من منظور سيادة، القيمة الأكبر ليست في نقل مفهوم Cyber Deception كما هو، بل ربطه بـAgent Authority.

يمكن تعريف Decoy ليس فقط بوصفه «موردًا لا ينبغي الوصول إليه»، بل بوصفه فرصة تقع خارج Authority Envelope للوكيل.

إذا كان Agent المالي مخولًا بإنشاء Draft حتى 10,000 دولار لكنه غير مخول باعتماد الدفع، يمكن بناء اختبار أو Decoy حول مسار الاعتماد. إذا حاول ممارسة سلطة ليست جزءًا من التفويض، فنحن أمام Authority Violation Signal.

بهذا تصبح العلاقة:

Objective → Delegation → Authority → Identity → Access → Decision → Action → Tripwire → Evidence → Intervention → Accountability

الـTripwire لا يحل محل Authority Enforcement Point. الأفضل أن يمنع النظام الفعل أصلًا إذا كان خارج السلطة. لكن عندما توجد مساحة تقنية لا يمكن تضييقها بالكامل، أو نحتاج إلى كشف سلوك الاستطلاع والتجاوز، تستطيع Decoys أن تضيف Sensor عالي القيمة.

ما الذي يجب أن تبنيه المؤسسة فعليًا؟

البرنامج الناضج لا يبدأ بشراء منتج Deception. يبدأ بنموذج سلطة واضح.

أولًا: Agent Inventory. لا يمكن زرع Decoys بذكاء إذا كانت المؤسسة لا تعرف أين تعمل الوكلاء وما الأدوات التي تستخدمها.

ثانيًا: Identity per Agent/Instance قدر الإمكان، مع Session attribution واضح.

ثالثًا: Authority Baseline يحدد ما هو مشروع لكل Agent: الأهداف، الأنظمة، البيانات، الأفعال، حدود المعاملات، الموافقات، الاتصال الخارجي، وإعادة التفويض.

رابعًا: Forbidden/No-legitimate-use actions. هذه أهم مادة أولية لاختيار Honeypots. كل مورد أو فعل لا يوجد سبب مشروع للمسار الحالي لاستخدامه هو مرشح.

خامسًا: Telemetry. لا قيمة لـdecoy إذا كان Trigger لا يصل بسرعة ولا يحمل Context كافيًا.

سادسًا: Response Playbook. من يوقف الوكيل؟ من يحتفظ بالأدلة؟ متى يُسحب Token؟ من يقرر إعادة التشغيل؟

سابعًا: Testing. يجب اختبار الـdecoy ضد السلوك الطبيعي وضد سيناريوهات عدائية. الهدف ليس فقط التأكد أن الـAlert يعمل، بل أيضًا أن المستخدم أو Agent الطبيعي لا يلمسه خطأ وأن الوكيل المستهدف لا يميزه بسهولة.

ثامنًا: Coverage Map. اربط كل Honeypot بمسار تهديد محدد. لا تعتبر عدد الـdecoys KPI للنجاح. عشرة Decoys تغطي أخطر Authority Paths أفضل من ألف ملف مزيف لا يمر بها أي سيناريو مهم.

مقاييس يجب أن تراقبها

بدل KPI تجميلي مثل «عدد Honeypots»، استخدم مقاييس تشغيلية أكثر دلالة:

• نسبة Authority Paths الحرجة التي تحتوي Detection Coverage.
• زمن Trigger-to-Containment.
• نسبة Triggers التي يمكن Attribution لها إلى Agent Run محدد.
• False Positive Rate في المهام الطبيعية.
• نسبة الحوادث التي تم فيها حفظ Evidence كامل.
• نسبة Decoys التي اكتشفها Agent أثناء الاختبار قبل Trigger.
• عدد المسارات التي تكشفها Honeypots ولا تكشفها المراقبة الأخرى.
• نسبة Authority Violations التي منعها Enforcement مقابل التي اكتشفتها Decoys بعد المحاولة.
• زمن تحديث الـdecoys بعد تغيير البيئة أو النموذج.

هذه المقاييس تجعل البرنامج قابلًا للتدقيق والتحسين بدل أن يتحول إلى عرض تقني مثير بلا أثر حوكمي.

نموذج نضج عملي

يمكن تقييم النضج في خمس حالات:

المستوى 0 — لا رؤية: لا توجد Agent Inventory أو Attribution واضحة.

المستوى 1 — مراقبة أساسية: توجد logs لكن من دون Authority Baseline أو Decoys.

المستوى 2 — Authority-aware: تعرف المؤسسة الحدود المسموحة وتراقب الأفعال خارجها.

المستوى 3 — Deception-enabled: توجد Honeypots مرتبطة بمسارات تهديد محددة واستجابة تلقائية مناسبة.

المستوى 4 — Adaptive Assurance: يتم اختبار Decoys دوريًا ضد Agents الفعلية، وتحليل Coverage، وتغيير التصميم مع تغيّر النماذج والبنية التحتية.

هذا النموذج ليس معيارًا صادرًا عن التقرير؛ هو طريقة تشغيلية في سيادة لتحويل أفكار التقرير إلى برنامج قابل للإدارة.

أخطاء تصميمية يجب منعها

أخطر خطأ هو اعتبار Honeypots بديلًا عن Least Privilege. إذا كان Agent يملك سلطة أوسع بكثير من حاجته، فلا معنى لوضع Decoy ثم ترك الأصول الحقيقية مكشوفة.

الخطأ الثاني هو اعتبار كل Trigger دليلًا على نية خبيثة. قد يكون هناك خطأ في التصميم أو المهمة أو الـdecoy.

الخطأ الثالث هو وضع Decoys من دون Containment. Alert بعد تنفيذ أثر حقيقي ليس كافيًا.

الخطأ الرابع هو استخدام Shared Credentials؛ هذا يقتل Attribution.

الخطأ الخامس هو نشر Decoys ثم عدم إعادة اختبارها عند تغيير Agent أو أدواته أو Environment.

الخطأ السادس هو قياس النجاح بعدد التنبيهات. انخفاض التنبيهات قد يعني انخفاض الخطر، وقد يعني أن Decoys لم تعد فعالة.

الخطأ السابع هو محاولة تفسير كل شيء من Chain-of-Thought. Evidence التشغيلية الخارجية يجب أن تبقى أساسًا مستقلًا.

قائمة تحقق تنفيذية

قبل إطلاق أي Agent Honeypot، اسأل:

1. هل نعرف Agent/Run الذي يمكن أن يصل إلى هذه البيئة؟
2. هل المورد الوهمي خارج كل مسار مشروع معقول؟
3. ما Authority Boundary التي يختبرها؟
4. ما Threat Pathway الذي يغطيه؟
5. ما Trigger الدقيق؟
6. كم يستغرق وصول Alert؟
7. ماذا يحدث تلقائيًا بعد Trigger؟
8. هل يمكننا وقف Agent أو تقليل سلطته فورًا؟
9. ما Evidence الذي يُحفظ قبل Reset؟
10. هل لدينا Attribution إلى Session وCredential وTool؟
11. ما تفسير False Positive المحتمل؟
12. هل اختبرناه ضد المهام الطبيعية؟
13. هل اختبرناه ضد نسخة من Agent المستهدف؟
14. ما الذي قد يكشف للوكيل أن المورد Decoy؟
15. متى نعيد الاختبار؟

إذا لم تستطع المؤسسة الإجابة عن هذه الأسئلة، فهي لا تملك Honeypot Program؛ لديها مجرد Decoy تقني.

الخلاصة

AI Agent Insider Threat يغيّر وحدة التحليل الأمني من «من دخل النظام؟» إلى «ماذا يفعل الفاعل الموثوق بالسلطة التي منحناها له؟» وهذا التحول يضع Identity وAccess وAuthority وRuntime Evidence في سلسلة واحدة.

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

القرار الصحيح للمؤسسة ليس «هل نستخدم Honeypots أم لا؟»، بل: أين توجد Authority Paths حرجة لا يمكن حمايتها بالكامل بالمنع، وأين يمكن لـDecoy مدروس أن يكشف محاولة تجاوز بسرعة ويمنحنا دليلًا للتحقيق؟

عندما توضع هذه التقنية داخل Control Stack يشمل Least Agency وAuthority Enforcement وMonitoring وContainment وForensics، تتحول من خدعة سيبرانية إلى مكوّن من مكونات حوكمة السلطة الوكيلية.