لكن هذا ليس هجومًا على خوارزمية AES نفسها، ولا يعني أن التشفير قد كُسر. التشفير هنا وسيلة للتمويه: قد يرى مرشح المحتوى سلسلة غير مفهومة، بينما يمتلك الوكيل الأدوات اللازمة لإعادة تحويلها لاحقًا إلى تعليمات قابلة للمعالجة.

وهنا تكمن النقطة الأهم: فحص النص الظاهر لا يساوي التحكم في ما يستطيع الوكيل فعله بعد أن يفسر بيانات مصدر غير موثوق أو يفك تشفيرها أو يشغّلها أو يتلقاها عبر أداة.

سلسلة الهجوم المبلغ عنها

يمكن تلخيص السيناريو في أربع مراحل:

1. صفحة خبيثة تبدو طبيعية: يطلب المستخدم من Grok تلخيص محتوى موجود في الصفحة أو تحليله.
2. إدراج الحمولة المشفّرة وإرشادات فكها: تقول Adversa إن الحمولة تستخدم AES-256-GCM مع مفتاح مشتق عبر PBKDF2، ما يبقي التعليمات الرئيسية غير واضحة أثناء الفحص الأولي للمحتوى.
3. تشغيل منطق فك التشفير: يُقال إن Grok يشغّل الكود المقدم داخل بيئة Python أو بيئة عزل، فتظهر التعليمات الصريحة عبر مسار تنفيذ الكود أو الأدوات بدلًا من ظهورها كنص واضح في الصفحة الأصلية. ووفق Adversa، يتعامل Grok بعد ذلك مع النتيجة باعتبارها سياقًا موثوقًا.
4. تغيير الإجراء التالي للوكيل: توجه الحمولة Grok، بحسب التقرير، إلى استخراج تفاصيل خاصة بالجلسة وإدراجها في عنوان URL، ثم فتح العنوان لإرسال البيانات إلى نقطة نهاية يتحكم بها المهاجم.

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

لماذا تمثل بيئة التشغيل حدّ الأمان الحقيقي؟

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

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

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

ماذا نعرف عن الإبلاغ والإصلاح؟

بحسب رواية Adversa، أبلغ أوتيفسكي xAI بالمشكلة وقدمها عبر منصة HackerOne في 3 يونيو 2026. وفي إفصاحها المنشور في 20 أغسطس، قالت الشركة إن المشكلة ظلت بلا حل لأكثر من شهرين رغم المتابعات.

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

ما الذي ينبغي إصلاحه؟

تركز توصيات Adversa على بيئة تشغيل الوكيل، لا على إضافة مزيد من مرشحات الكلمات المفتاحية. وتشمل الضوابط الأهم:

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

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

صلة القضية بهجمات أخرى على وكلاء الذكاء الاصطناعي

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

وُصفت ثغرة EchoLeak في Microsoft 365 Copilot بأنها ثغرة حقن تعليمات «بلا نقرة»، إذ كان من الممكن لبريد إلكتروني مُعدّ بعناية أن يتيح استخراجًا عن بُعد وغير موثق للبيانات المتاحة للمساعد. وتحدد دراسة أكاديمية القضية بالمعرف CVE-2025-32711.

وفي حالة منفصلة، أفادت تقارير عن سلسلة CoSnitch في Copilot Personal، إذ كان رابط مُعدّ خصيصًا قادرًا على تشغيل تعليمات واستخراج بيانات من تطبيقات متصلة؛ وقال الباحثون إن Microsoft أطلقت تصحيحات في 18 أغسطس 2026.

أما وكلاء البرمجة، فيواجهون خطرًا مشابهًا عبر مستودعات الأكواد بدلًا من صفحات الويب. فقد أفادت Adversa بأن مستودعات خبيثة يمكن أن تستغل سلوكيات الثقة والإعدادات في مساعدين عدة، من بينها Claude Code وCursor CLI وGemini CLI وCopilot CLI، لتشغيل خوادم MCP يتحكم بها المهاجم مع صلاحيات قد تكون واسعة. كما وصفت الشركة في تقرير آخر تجاوزًا لسياسات الحماية عبر سلاسل طويلة من أوامر الصدفة، مع احتمال سرقة بيانات الاعتماد أو الأسرار.

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

الدلالة الأمنية الأوسع

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

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

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

لكن هذا ليس هجومًا على خوارزمية AES نفسها، ولا يعني أن التشفير قد كُسر. التشفير هنا وسيلة للتمويه: قد يرى مرشح المحتوى سلسلة غير مفهومة، بينما يمتلك الوكيل الأدوات اللازمة لإعادة تحويلها لاحقًا إلى تعليمات قابلة للمعالجة.

وهنا تكمن النقطة الأهم: فحص النص الظاهر لا يساوي التحكم في ما يستطيع الوكيل فعله بعد أن يفسر بيانات مصدر غير موثوق أو يفك تشفيرها أو يشغّلها أو يتلقاها عبر أداة.

سلسلة الهجوم المبلغ عنها

يمكن تلخيص السيناريو في أربع مراحل:

1. صفحة خبيثة تبدو طبيعية: يطلب المستخدم من Grok تلخيص محتوى موجود في الصفحة أو تحليله.
2. إدراج الحمولة المشفّرة وإرشادات فكها: تقول Adversa إن الحمولة تستخدم AES-256-GCM مع مفتاح مشتق عبر PBKDF2، ما يبقي التعليمات الرئيسية غير واضحة أثناء الفحص الأولي للمحتوى.
3. تشغيل منطق فك التشفير: يُقال إن Grok يشغّل الكود المقدم داخل بيئة Python أو بيئة عزل، فتظهر التعليمات الصريحة عبر مسار تنفيذ الكود أو الأدوات بدلًا من ظهورها كنص واضح في الصفحة الأصلية. ووفق Adversa، يتعامل Grok بعد ذلك مع النتيجة باعتبارها سياقًا موثوقًا.
4. تغيير الإجراء التالي للوكيل: توجه الحمولة Grok، بحسب التقرير، إلى استخراج تفاصيل خاصة بالجلسة وإدراجها في عنوان URL، ثم فتح العنوان لإرسال البيانات إلى نقطة نهاية يتحكم بها المهاجم.

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

لماذا تمثل بيئة التشغيل حدّ الأمان الحقيقي؟

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

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

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

ماذا نعرف عن الإبلاغ والإصلاح؟

بحسب رواية Adversa، أبلغ أوتيفسكي xAI بالمشكلة وقدمها عبر منصة HackerOne في 3 يونيو 2026. وفي إفصاحها المنشور في 20 أغسطس، قالت الشركة إن المشكلة ظلت بلا حل لأكثر من شهرين رغم المتابعات.

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

ما الذي ينبغي إصلاحه؟

تركز توصيات Adversa على بيئة تشغيل الوكيل، لا على إضافة مزيد من مرشحات الكلمات المفتاحية. وتشمل الضوابط الأهم:

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

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

صلة القضية بهجمات أخرى على وكلاء الذكاء الاصطناعي

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

وُصفت ثغرة EchoLeak في Microsoft 365 Copilot بأنها ثغرة حقن تعليمات «بلا نقرة»، إذ كان من الممكن لبريد إلكتروني مُعدّ بعناية أن يتيح استخراجًا عن بُعد وغير موثق للبيانات المتاحة للمساعد. وتحدد دراسة أكاديمية القضية بالمعرف CVE-2025-32711.

وفي حالة منفصلة، أفادت تقارير عن سلسلة CoSnitch في Copilot Personal، إذ كان رابط مُعدّ خصيصًا قادرًا على تشغيل تعليمات واستخراج بيانات من تطبيقات متصلة؛ وقال الباحثون إن Microsoft أطلقت تصحيحات في 18 أغسطس 2026.

أما وكلاء البرمجة، فيواجهون خطرًا مشابهًا عبر مستودعات الأكواد بدلًا من صفحات الويب. فقد أفادت Adversa بأن مستودعات خبيثة يمكن أن تستغل سلوكيات الثقة والإعدادات في مساعدين عدة، من بينها Claude Code وCursor CLI وGemini CLI وCopilot CLI، لتشغيل خوادم MCP يتحكم بها المهاجم مع صلاحيات قد تكون واسعة. كما وصفت الشركة في تقرير آخر تجاوزًا لسياسات الحماية عبر سلاسل طويلة من أوامر الصدفة، مع احتمال سرقة بيانات الاعتماد أو الأسرار.

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

الدلالة الأمنية الأوسع

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

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

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