💻 computer science

Sleeper Channels and Provenance Gates: Persistent Prompt Injection in Always-on Autonomous AI Agents

تقدم هذه الورقة "قنوات النوم"، وهي ثغرة أمنية مستمرة في حقن الأوامر (prompt injection) في وكلاء الذكاء الاصطناعي المستقلين الذين يعملون باستمرار، حيث تستمر المدخلات غير الموثوقة وتنفذ لاحقاً عبر واجهات مختلفة، وتقترح دفاعاً متعدد المستويات يرتكز على "بوابات المصدر" (provenance gates) التي تستخدم ملخصات نموذجية لـ "الحدث-المثيل" (action-instance digests) وإقرارات المالك لمنع مثل هذه الهجمات، مدعومة بأداة تدقيق ثابتة ومحول وقت التشغيل.

المؤلفون الأصليون: Narek Maloyan, Dmitry Namiot

نُشر 2026-05-14

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Narek Maloyan, Dmitry Namiot

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

تحذرنا ورقة بحثية بعنوان "القنوات النائمة وبوابات الأصل" (Sleeper Channels and Provenance Gates) من طريقة خبيثة وماكرة لاختراق هذا المساعد. إليك تفصيل ذلك بكلمات بسيطة:

1. هجوم "القناة النائمة": قنبلة مؤقتة

عادةً، عندما نفكر في اختراق الذكاء الاصطناعي، نتخيل شخصاً يخدعه الآن عبر أمر غريب. لكن هذه الورقة تصف شيئاً مختلفاً: القناة النائمة (Sleeper Channel).

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

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

2. لماذا تفشل الدفاعات الحالية؟

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

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

تسمي الورقة هذه المشكلة بـ "النائب المرتبك" (Confused Deputy)؛ المساعد هو "النائب"؛ هو ينفذ ما طلبته، لكنه مرتبك بشأن من الذي أتى بالفكرة الخطيرة في الأصل.

3. الحل: "بوابة الأصل" (Provenance Gate)

لإصلاح ذلك، يقترح المؤلفون نظاماً أمنياً جديداً يسمى بوابات الأصل (Provenance Gates).

التشبيه: نظام "الإيصالات"
تخيل أن كل معلومة يستخدمها الذكاء الاصطناعي يرفق بها "إيصال رقمي".

إذا قرأ الذكاء الاصطناعي بريداً إلكترونياً من غريب، يحصل هذا البريد على إيصال يقول: "المصدر: غريب".
إذا كتب الذكاء الاصطناعي ملاحظة بناءً على هذا البريد، فإن الملاحظة ترث الإيصال: "المصدر: غريب".
إذا حاول الذكاء الاصطناعي لاحقاً إعداد مهمة مجدولة بناءً على تلك الملاحظة، يقوم النظام بفحص الإيصال.

حارس البوابة (بوابة الأصل):
قبل أن يُسمح للذكاء الاصطناعي بالقيام بأي شيء مهم (مثل إرسال بريد إلكتروني، أو تغيير ملف، أو جدولة موعد)، يجب أن يمر عبر بوابة أمنية.

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

4. ما الذي فعلوه بالفعل؟

لم يكتفِ المؤلفون بكتابة نظرية فحسب؛ بل بنوا نموذجاً أولياً لإثبات نجاح الأمر.

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

5. الخلاصة

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

الطريقة القديمة: "هل طلب المالك هذا؟" (نعم -> افعل ذلك).
الطريقة الجديدة: "هل طلب المالك هذا، وَهل وافق المالك أيضاً على مصدر الفكرة الكامنة وراءه؟" (إذا جاءت الفكرة من غريب -> توقف).

يسمي المؤلفون هذا "دفاعاً متعدد المستويات"، مما يعني أن لديهم نسخة أساسية ونسخة أقوى، لكن الفكرة الجوهرية بسيطة: لا تسمح للذكاء الاصطناعي بالتصرف بناءً على أفكار التقطها من غرباء دون الحصول على "موافقة" صريحة وجديدة منك.

ملخص تقني: القنوات النائمة وبوابات إثبات المصدر

تعريف المشكلة: القنوات النائمة (Sleeper Channels)

تحدد الورقة فئة تهديد مستحدثة في وكلاء الذكاء الاصطناعي المستقلين الذين يعملون بنظام "التشغيل الدائم" (مثل OpenClaw وHermes Agent)، وتسمى القنوات النائمة. على عكس هجمات حقن الأوامر التقليدية، التي تحدث عادةً ضمن جولة أو جلسة واحدة، تقوم هجمات القنوات النائمة بفصل الاستقبال ( $T_0$ ) عن الأثر ( $T_1$ ) عبر الزمن، والركائز التخزينية، وأسطح الاتصال.

في هذا السيناريو، يتم استيعاب مدخل غير موثوق (مثل رسالة في دردشة جماعية أو بريد إلكتروني) من قبل الوكيل، ويستمر كملحوظة في الذاكرة، أو مهارة ذاتية التأليف، أو وظيفة مجدولة، أو تعديل في نظام الملفات. تظل هذه القطعة البرمجية (Artifact) داخل نطاق سلطة الوكيل حتى يتم استدعاؤها وتنفيذها بواسطة محفز حميد (مثل طلب لاحق من المالك أو حلقة تشغيل ذاتية). ينطلق الهجوم عبر سطح مختلف عن سطح الاستقبال، وغالبًا ما يستغل حالة "النائب المرتبك" (Confused Deputy) حيث ينفذ الوكيل أمرًا نيابة عن المالك، دون أن يدرك أن معلمات الأمر نشأت من مصدر غير موثوق.

تعرف الورقة هذه الفئة باستخدام محورين:

ركيزة الاستمرار (Persistence Substrate): أين تستمر التعليمات الخبيثة (الذاكرة، مهارة ذاتية التأليف، نظام الملفات، محفز مجدول/خارجي).
فصل الإطلاق (Firing-Separation): درجة الفصل بين الاستقبال والتنفيذ (نفس الجلسة، عبر قنوات مختلفة، عبر فاعلين مختلفين، عبر سياقات تنفيذ مختلفة).

تجادل الورقة بأن الأدبيات الحالية تعامل هذه القدرات بشكل منعزل (مثل الحقن أحادي الجولة أو تسميم الذاكرة) وتفشل في معالجة التهديد الموحد المتمثل في الاستمرار متعدد الركائز المقترن بالإطلاق المتأخر عبر أسطح مختلفة.

المنهجية ونموذج التهديد

تتبنى المؤلفة نموذج تهديد يكون فيه المهاجم "غير موثوق به ولكن مقبول"، مما يعني أن محتواه يصل إلى الوكيل عبر قنوات مفعلة ولكن منخفضة الثقة (دردشات جماعية، رسائل بريد إلكتروني، روابط URL تم جلبها). المدافع هو مالك الوكيل. يستند التحليل إلى التزام محدد (Commit) لزمن تشغيل OpenClaw (الالتزام 3120401f...1829b1b6)، مع التحقق من جميع الادعاءات مقابل الكود المصدري المرفق.

تقدم الورقة تصنيفًا (الجدول الأول) يربط ركائز الاستمرار ( $M_1$ – $M_5$ ) مقابل فصول الإطلاق ( $C_0$ – $C_4$ ). وهي تسلط الضوء على أربعة سيناريوهات توضيحية لم تحددها الدراسات السابقة بدقة:

A4 (مثال جارٍ): هجوم "Cron عبر نائب مرتبك" ( $M_5 \times C_4$ ). يقوم المهاجم بتضمين رابط ويب (Webhook) خبيث في بريد إلكتروني. يقوم الوكيل بتلخيص هذا المحتوى في الذاكرة. بعد أيام، يطلب المالك من الوكيل "إعداد فحص الحالة اليومي". يسترجع الوكيل الملحوظة، ويقوم بتركيب وظيفة cron تحتوي على رابط المهاجم، وينفذها. الاستمرار هو إدخال الـ cron؛ والإطلاق يحدث في برنامج cron الخاص بالنظام، خارج عملية الوكيل.
A2: حصان طروادة في مهارة عبر دردشة جماعية ( $M_3 \times C_2$ ).
A3: تسريب بيانات عبر قنوات مختلفة عبر الذاكرة ( $M_2 \times C_2$ ).
A5: تعديل ملفات الإعدادات (Dotfile patching) ( $M_4 \times C_4$ ).

المساهمات الرئيسية: دفاع إثبات المصدر (D2)

تقترح الورقة استراتيجية دفاع متعددة الطبقات، حيث يمثل D2 المساهمة الجوهرية. ينقل D2 حدود الإنفاذ إلى خارج حلقة النموذج، معتمدًا على تتبع إثبات المصدر (Provenance Tracking) وتوثيق حالة الإجراء (Action-Instance Attestation).

الآليات الجوهرية

وسم وتمرير القطع البرمجية (Artifact Tagging and Propagation): يحافظ زمن التشغيل على حالة إثبات المصدر ( $\Pi$ ) لكل قطعة برمجية (ذاكرة، مهارات، ملفات، استدعاءات أدوات). تسجل العلامات ( $\tau$ ) المصدر (القناة، الفاعل الرئيسي، الجهاز). المدخلات غير الموثوقة توسع مجموعة إثبات المصدر بشكل صارم.
ملخص حالة الإجراء (Action-Instance Digest): يتم إنشاء هاش لكل إجراء تبعي $\alpha$ في ملخص معياري $\delta(\alpha)$ باستخدام هاش مقاوم للتصادم (SHA-256) فوق بايتات الإجراء المعيارية (بما في ذلك الوسائط والهدف). هذا يمنع "غسيل إعادة الصياغة" (Paraphrase Laundering) حيث يعيد النموذج كتابة تعليمات المهاجم لإخفاء أصلها.
خطافات الوساطة (Mediation Hooks): يتطلب الدفاع وساطة كاملة عبر عشرة خطافات زمن تشغيل (H1–H10).
- خطافات التحديث (H1–H5): تملأ العلامات وتمرر إثبات المصدر أثناء الاستقبال والإنشاء.
- خطافات البوابة (H6–H10): نقاط قرار قبل عمليات الإرسال ذات الآثار الجانبية (مثل تنفيذ Shell، كتابة الملفات، الجدولة).
توثيق المالك بضربة واحدة (One-Shot Owner Attestation): بالنسبة للإجراءات ذات إثبات المصدر غير الموثوق، تتطلب البوابة منحًا $g$ من فاعل موثوق. يجب أن يتطابق هذا المنح مع ملخص الإجراء $\delta(\alpha)$ ، ويحتوي على رمز فريد (Nonce) لمنع إعادة التشغيل (Replay)، ويصل عبر قناة مرافقة موثقة بالأجهزة ( $\Sigma$ ) لا يمكن للنموذج الإرسال إليها.

نظرية السلامة (Soundness Theorem)

تقدم المؤلفة نظرية سلامة لـ D2، بافتراض سبعة ثوابت لزمن التشغيل (الوساطة، العلامة، السببية، القناة، توثيق المنح، الرمز الفريد، الهاش). تنص النظرية على أن الإرسال يُسمح به فقط إذا:

كانت جميع القطع البرمجية المساهمة في المجموعة السببية تمتلك إثبات مصدر موثوق ( $\Pi_\alpha \subseteq T$ )، أو
يوجد توثيق صالح، حديث، وموثوق من المالك لحالة الإجراء المحددة بالضبط.

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

النتالئج والتقييم

لا تدعي الورقة تقديم نظام إنتاجي منتشر، بل تقدم حجة جدوى مرتبطة بالمصدر وتنفيذ مرجعي قابل للتنفيذ.

الفحص التجريبي (A4): في "فحص دخاني" (Smoke Probe) شمل 20 تجربة أحادية الجولة، تم إعطاء نموذج استدلال متطور تحذير الأمان الخاص بـ OpenClaw والسياق الخبيث. 19/20 من النماذج أصدرت استدعاء أداة cron.add صالحًا يشير إلى رابط المهاجم، مما يثبت أن التحذيرات داخل السياق (D1) غير كافية لمنع الهجوم.
التنفيذ المرجعي: يتضمن الأثر المرفق عند github.com/maloyan/sleeper-channels:
- تنفيذ بلغة TypeScript لدالة قرار بوابة D2.
- مجموعة تدقيق ثابتة (13 حالة) تتحقق من وجود أسطر المصدر المذكورة في OpenClaw ومطابقتها لنموذج التهديد.
- محول زمن تشغيل ينفذ الخطافات H1، H2، H3، H6، وH9 حول مسار الـ cron.
- مجموعة اختبار تضم 42 حالة تغطي قواعد القرار، غسيل المدخلات المتعددة، وإعادة تشغيل المنح.
التحقق: نجح محول زمن التشغيل في إثبات أن استدعاء المهاجم (A4) مرفوض بسبب إثبات المصدر غير الموثوق، بينما يتم قبول وظائف الـ cron الصادرة عن المالك فقط.

الأهمية والادعاءات

تضع الورقة نفسها كـ ورقة وضع وتصميم تعالج فئة تهديد القنوات النائمة وتوفر مواصفات رسمية للدفاع.

الجدة: هي العمل الأول الذي يعامل الجمع بين الاستمرار متعدد الركائز والإطلاق المتأخر عبر أسطح مختلفة كفئة تهديد موحدة في الوكلاء الذين يعملون بنظام التشغيل الحي.
مكان الدفاع: تجادل الورقة بأن إشارات إثبات المصدر يجب أن تُنفذ خارج حلقة النموذج. الاعتماد على النموذج لرفض المدخلات غير الموثوقة (D1) هو أمر هش أمام الهجمات التكيفية.
الرسمية: تقدم ملخصًا معياريًا لـ "إجراء الحالة" (Action-instance digest) لهزيمة غسيل إعادة الصياغة وهجمات إعادة التشغيل، معالجةً الفجوات في مقترحات المجتمع السابقة (مثل المشكلة رقم [10] في Upstream) التي افتقرت إلى الأساس التجريبي ومواصفات الإنفاذ الرسمية.
التواضع: تصرح المؤلفة صراحةً بأن معدلات نجاح الهجوم التجريبية، وفعالية النشر الكامل، ومقايضات التكلفة والمنفعة، مؤجلة لدراسة لاحقة مسجلة مسبقًا. العمل الحالي يضع التصنيف، والدفاع الرسمي، وجدوى الهجوم والدفاع على التزام محدد لزمن التشغيل.