يتطلب تسميم ذاكرة وكلاء AI دفاعات تغطي دورة الحياة الكاملة

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

جدول المحتويات

ما هو تسميم ذاكرة وكيل AI؟

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

يمكن أن توجد الذاكرة في عدة أماكن:

تقنية التخزين ليست هي القضية المحدِّدة. فالاستمرارية، إلى جانب التأثير اللاحق، هي التي تنشئ حدود الأمان.

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

تهم ثلاثة أنماط من الهجمات عملياً:

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

ما الذي قاسَته ثلاث دراسات حديثة

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

اختبر GhostWriter الحقن الآن والتفعيل لاحقاً

قدّم When Agents Remember Too Much نظام GhostWriter، وهو هجوم من مرحلتين ضد وكلاء شخصيين يستخدمون الأدوات. يضع الخصم أولاً محتوى مخفياً في مصدر غير موثوق. ثم يعالج الوكيل ذلك المصدر ويكتب ذاكرة متأثرة بالمهاجم. وتسترجع مهمة لاحقة السجل وتفعّل تأثيره.

عبر الوكلاء والنماذج التي اختبرتها الورقة، حقق GhostWriter معدل حقن متوسطاً يقارب 98% ومعدل تفعيل متوسطاً يقارب 60%. كما اختبر المؤلفون AM-Sentry، الذي يجمع بين سياسة أكثر صرامة لحفظ الذاكرة ومرشح للاسترجاع. وتقيّم الورقة كلاً من نجاح الهجوم وفائدة المهمة في أسبوع عمل محاكى مخصص لها؛ وتختلف نتائج الدفاع حسب النموذج والإعداد.

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

فصل MemPoison بين الإخفاقات المباشرة والتركيبية والخاملة

جمع MemPoison 1,227 حالة جرى التحقق منها يدوياً عبر أربعة أنواع من الهجمات وثلاث قنوات للحقن وثلاث ركائز للذاكرة. وشمل التقييم سبع عائلات من النماذج مفتوحة الأوزان وثلاث عائلات من النماذج مغلقة الأوزان.

تتمثل مساهمة الورقة المفيدة في تصنيفها ذي المستويات الثلاثة. يشير L1 إلى فساد مباشر لسجل واحد. ويصبح L2 ضاراً عند استرجاع عدة سجلات معاً. أما L3 فيظل خاملاً حتى يفعّله سياق لاحق. ويفيد المؤلفون بأن دفاعات وقت الكتابة الأساسية تكبح الهجمات المباشرة بموثوقية أكبر من حالات L2 أو L3. وينسب تحليل التأثير الآلي لديهم الفجوة إلى سجلات تبدو سليمة عند تخزينها لكنها تصبح ضارة عند تركيبها أو عند وجود مُشغِّل.

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

اختبر MemGhost مسار توصيل عبر البريد الإلكتروني من خطوة واحدة

قدّم When Claws Remember but Do Not Tell معيار WhisperBench، وهو معيار من 108 حالات يستخدم سير عمل IMAP/SMTP حقيقياً ومهارة وكيل بريد إلكتروني. ويولّد إطار الهجوم MemGhost حمولة بريد إلكتروني واحدة دون ملاحظات أثناء التشغيل. ويتطلب النجاح أن يتبنى الوكيل ذاكرة مسمومة، وألا ينبه المستخدم في رده الفوري، وأن يغيّر سلوكه لاحقاً.

في 56 حالة محجوزة للاختبار، تفيد الورقة بنجاح شامل من طرف إلى طرف بنسبة 87.5% على OpenClaw مع GPT-5.4، و71.4% على Claude Code SDK مع Sonnet 4.6.

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

لماذا لا تكفي التصفية وقت الكتابة

ترى بوابة الكتابة السجل المقترح والأدلة المتاحة في تلك اللحظة. وقد لا ترى المهمة المستقبلية أو السجلات الأخرى التي ستُسترجع إلى جانبه أو الأداة التي سيستدعيها الوكيل لاحقاً.

ينشئ ذلك أربع نقاط عمياء:

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

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

بنية آمنة لذاكرة الوكيل

يحتاج النظام إلى سلسلة قابلة للتتبع من المصدر إلى الإجراء:

`source → write decision → stored version → retrieval decision → model context → policy decision → tool result`

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

1. اشترط نية صريحة للكتابات الدائمة

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

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

2. خزّن المصدر والنطاق ومدة الصلاحية مع السجل

يحتاج سجل الذاكرة المفيد إلى أكثر من النص والتضمين. خزّن على الأقل:

يمكن للتوقيع حماية سلامة السجل. لكنه لا يستطيع إثبات أن المحتوى الأصلي كان صحيحاً أو آمناً أو مصرحاً به.

3. طبّق العزل في الشيفرة والتخزين

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

4. ضع الكتابات منخفضة الثقة في الحجر الصحي

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

يوفر الحجر الصحي أيضاً مكاناً للمستجيبين للحوادث لحفظ الأدلة دون استمرار التأثير.

5. أعد تقييم السجلات وقت الاسترجاع

تعتمد مخاطر الاسترجاع على المهمة الحالية. قيّم المجموعة المحددة، لا كل سجل فقط:

6. أبقِ تفويض الأدوات مستقلاً

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

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

7. سجّل التأثير وادعم التراجع

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

ينبغي أن يزيل الحذف التأثير النشط، لا أن يخفي صفاً في واجهة المستخدم فقط. اختبر الفهارس والملخصات وذاكرات التخزين المؤقت والنسخ المتماثلة والسجلات المشتقة. يوصي إرشاد OWASP للوكلاء بذاكرة متحقَّقاً منها ومعزولة، إلى جانب الاختبارات العدائية وأدلة الإصدار؛ ويربط تحليله الأوسع للذاكرة الحقن المستمر للتعليمات بسطح تهديد ذاكرة الوكيل. OWASP Agent Security Cheat Sheet OWASP GenAI Security Project

اختر سياسة لكل فئة من فئات الذاكرة

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

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

سير عمل قابل لإعادة الإنتاج لاختبار تسميم الذاكرة

ابنِ أداة الاختبار حول علامات آمنة وحسابات قابلة للتخلص منها. لا تحتاج إلى بيانات اعتماد حقيقية أو حمولات استخراج بيانات لاكتشاف إخفاقات الاستمرارية والسياسة.

الخطوة 1: التقط خط أساس نظيفاً

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

الخطوة 2: عرّف حالات نظيفة ومسمومة متزاوجة

لكل حالة، أبقِ مهمة المستخدم ثابتة وغيّر مسار الذاكرة المرشح فقط. غطِّ على الأقل:

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

الخطوة 3: راقب كل حد

التقط أربع نتائج منفصلة:

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

الخطوة 4: قِس الفائدة والإيجابيات الكاذبة

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

الخطوة 5: حدّد بوابات الإصدار حسب المخاطر

تشمل البوابات المفيدة:

يُعد مشروع Agent Memory Guard مفتوح المصدر من OWASP إحدى إشارات التنفيذ لفحص الذاكرة وأدوات الاختبار. ويمكن لمستودعه وتقييمه المبلغ عنه ذاتياً مساعدة الفرق على فحص الأنماط، لكنهما لا يغنيان عن اختبار الوكيل والنموذج وخلفية الذاكرة ومكدس السياسة الفعلي.

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

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

قاست الأوراق نجاح الهجمات داخل معايير مصممة. ولم تقس معدل انتشار تسميم ذاكرة وكلاء AI على مستوى السكان في الإنتاج.

وهي تدعم ثلاثة استنتاجات أضيق:

وتستنتج الأوراق أن حوكمة الذاكرة تحتاج إلى دفاعات حساسة للسياق. كما توصي Microsoft وOWASP بشكل مستقل بالدفاع متعدد الطبقات عبر الكتابة والعزل والاسترجاع وتحكم المستخدم والرصد والاختبار.

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

أسئلة تطرحها الفرق

هل تسميم ذاكرة وكيل AI هو نفسه حقن التعليمات؟

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

هل يمكن لسجلات الذاكرة الموقعة منع التسميم؟

لا. يمكن للتوقيعات إثبات أن السجل لم يُعدَّل بعد إنشائه. لكنها لا تثبت أن المحتوى الأصلي كان صحيحاً أو آمناً أو مصرحاً به. ويحتاج التصميم الآمن أيضاً إلى المصدر ونية الكتابة الصريحة والنطاق ومدة الصلاحية وفحوص الاسترجاع وتفويض الإجراءات المستقل.

هل ينبغي أن تعمل دفاعات تسميم الذاكرة وقت الكتابة أم وقت الاسترجاع؟

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

التحقق من الادعاءات

المصادر