في كل موجة جديدة من المخاطر التي تستهدف مؤسسات اليوم، يظهر نمط ثابت: المهاجم لا يحتاج دائماً إلى اختراق “تقني” مباشر بقدر ما يحتاج إلى خداع النظام ليفعل ما لا ينبغي. أحدث ما يلفت الانتباه في هذا السياق هو ما رصدته تقارير أمنية حول مساعد الذكاء الاصطناعي من أتلاسيان (Rovo)، حيث يمكن أن تُستخدم تعليمات يتحكم بها المهاجم لتوجيه المساعد إلى جمع بيانات من جيـرا أو كونفلونس ضمن ما يملكه المستخدم المُسجّل من صلاحيات، ثم إرسال تلك البيانات إلى خادم خارجي—حتى دون أن يلاحظ المستخدم حدوث التسريب.

الأهم من التفاصيل التقنية هو الدرس الاستراتيجي: عندما يصبح المساعد قادرًا على “القراءة” و“التجميع” و“الربط” و“الاستدعاء” عبر واجهات متعددة، فإن حدود الحماية لا تُقاس فقط بوجود تحديثات أو تصحيحٍ واحد، بل بمدى إحكام التحكم في مصادر البيانات، وقنوات الإخراج، ونطاق الصلاحيات التي تُمنح للمساعد أثناء تنفيذ الطلب.

ما الذي اكتشفته التقارير؟ مساران لحقن الأوامر داخل Rovo

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

المسار الأول: تعليمات مخفية داخل المحتوى الذي يقرأه المساعد

قدمت شركة (PromptArmor) تفسيراً واضحاً لسلسلة هجوم وصفتها بأنها حقن أوامر غير مباشر عبر ما يُسمى حقن الأوامر داخل المطالبات (Prompt Injection). الفكرة الأساسية: يضع المهاجم نصاً/تعليمة داخل ملف أو محتوى سيقوم Rovo باستخدامه لاحقاً، ثم يتعامل النموذج مع جزء من هذا النص كتعليمات تنفيذية.

في مثال موثق، يقوم المستخدم برفع مستند يتضمن حقناً، ثم يطلب من Rovo تنظيم تذاكر (Jira). عندها قد يقوم Rovo بالبحث داخل جيـرا وكونفلونس كما طُلب، ثم يدمج النتائج داخل مسار طلب إلى خادم المهاجم بحيث تظهر البيانات في سجلات الخادم. ولفتت (PromptArmor) أن التسريب لا يتطلب—بحسب وصفها—خطوة موافقة بشرية منفصلة على مرحلة الإرسال.

كما أشارت الشركة إلى أن تعطيل خيار بحث الويب (web-search) لم يُلغِ السلسلة في حالة التجربة لديها، لأن طلب الإخراج تم عبر آلية منفصلة لاسترجاع URL—ما يثير سؤالاً جوهرياً: هل تعتبر المؤسسة خيار “بحث الويب” كحد أمان فعلي، أم مجرد تحكم في نوع مصدر البيانات بينما تظل قنوات الإخراج موجودة؟

المسار الثاني: تحميل تعليمات عبر معلمة في رابط داخل واجهة Rovo

في مسار آخر، رصدت (Varonis Threat Labs) ما أسمته (RovoBlast)، حيث يمكن تمرير تعليمات كاملة عبر معلمة داخل رابط (URL) لواجهة Rovo Chat. الفكرة تشبه “زر واحد” للمهاجم: عندما ينقر مستخدم مُسجّل الدخول على رابط يحمل التعليمات، يتم تحميلها داخل سياق المحادثة، ثم ينفذ المساعد خطوات جمع المعلومات وإرسالها إلى خادم المهاجم.

وبحسب ما ورد، تم اختبار التقنية لإثبات القدرة على استخراج بيانات حساسة—مثل مفاتيح API—من كونفلونس، مع الإشارة أيضاً إلى إمكانية استهداف بيانات متاحة عبر تكاملات ومصادر أخرى (مثل أدوات واتساب/مفاهيم تكاملات خارجية مرتبطة بـ [SharePoint] و[Outlook connectors] كما ورد في التقرير). هذا النوع من السلوك يرفع المخاطر لأن المستخدم لا يحتاج بالضرورة إلى فهم ما الذي يجري؛ يكفي أن يكون الرابط مقنعاً وأن تكون صلاحياته كافية.

لماذا هذا النوع من الهجمات خطير؟ لأن “الصلاحيات” تصبح وقوداً للتسريب

من المهم توضيح نقطة تُسهّل تقييم المخاطر: التقارير لا تصف بالضرورة اختراقاً لتجاوز الصلاحيات (Authorization Bypass) على مستوى كامل المستأجر (Tenant). الخطر—بحسب ما يوضحه مضمون التقارير—ينبع من أن المساعد يلتزم بنموذج صلاحيات المستخدم داخل منتجات أتلاسيان والتكاملات المرتبطة. بمعنى آخر: المهاجم لا “يكسر” الأمان؛ بل يوجّه النظام ليجمع ما هو مسموح للمستخدم برؤيته، ثم يخرجه خارج المؤسسة.

هذا النمط يُشبه منطق هجمات تصفية البيانات عبر واجهات شرعية (Data Exfiltration via Legitimate Features): إذا كان النظام مصمماً لجلب معلومات من مصادر داخلية ثم إظهارها للمستخدم، فقد يصبح—عند خداعه—قناة لتمرير تلك المعلومات إلى جهة لا ينبغي لها الوصول.

ولأن المساعد يعمل عبر سلسلة قرارات (قراءة → استنتاج → استدعاء → إخراج)، فإن أي نقطة ضعف في طريقة تفسير “ما هو تعليمات” يمكن أن تتحول إلى تسريب، حتى لو لم يكن هناك خطأ في التحقق من الهوية أو كلمة مرور أو جلسة.

كيف يتقاطع ذلك مع اتجاهات أوسع في أمن الذكاء الاصطناعي؟

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

كما يبرز مفهوم تداخل الأدوار: عندما يجمع النظام بين “وظيفة المساعد” و“وظيفة الوكيل” (Agent) التي قد تستدعي أدوات أو تقوم بإجراءات، يصبح من الضروري وضع سياسات أمان تفصل بين:

• البيانات التي تُقرأ (Sources) وبين الأوامر التي تُنفذ (Instructions).
• المصادقة والصلاحيات وبين قواعد الإخراج التي تمنع التسريب عبر قنوات الشبكة.
• خيارات التحكم مثل تعطيل بحث الويب، وبين حقيقة أن النظام قد يستخدم آليات أخرى لطلبات URL أو استرجاع موارد.

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

هل توجد معالجات؟ وما الذي تم إغلاقه فعلاً؟

وفقاً للمعطيات المتاحة في تقارير النشر:

• تم الإبلاغ عن مسار الروابط عبر Bugcrowd وتم اعتبار إصلاحه على الجانب الخادمي من أتلاسيان بتاريخ 8 يوليو 2026، مع تأكيد التحقق من صحة الإصلاح من قِبل المبلّغ.
• لم يتم ربط أي من المسارين—بحسب ما ورد—بمعرّف CVE في السجلات المعروفة (مثل NVD و[Known Exploited Vulnerabilities]) حتى تاريخ 8 أغسطس 2026 وفقاً لما ذكرته المعلومات المتاحة.
• بالنسبة للمسار الذي يعتمد على المحتوى الذي يقرأه المساعد، فقد أشارت إحدى التقارير إلى أن الحالة لم تكن مؤكدة الإغلاق وقت نشرها في 5 أغسطس 2026، وبالتالي يبقى تقييم الوضع بعد ذلك التاريخ مرتبطاً بما إذا كانت أتلاسيان قد نفذت تعديلات لاحقة على نفس المسار.

هذه التفاصيل تفرض على المؤسسات قاعدة واقعية: لا يكفي افتراض أن “الإصلاح” يغطي كل المسارات. في أنظمة المساعدات، قد تتغير حماية مسار بينما يبقى مسار آخر—بنفس المنطق—مفتوحاً ما لم يتم فحصه بوضوح.

كيف ينبغي على المؤسسات تخفيف المخاطر عملياً؟

لا توجد وصفة واحدة، لكن هناك إجراءات “عالية العائد” تتماشى مع أفضل الممارسات في إدارة مخاطر الذكاء الاصطناعي وواجهات الوكيل:

1) تقليص نطاق من يملك إمكانية استخدام Rovo

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

2) مراجعة التكاملات والاتصالات الخارجية

حتى عندما يُفترض أن “بحث الويب” هو حد أمان، فإن التقارير تشير إلى أن قنوات أخرى لطلبات URL قد تظل نشطة. لذلك يجب مراجعة:

• ما هي أدوات الاستدعاء المتاحة لوكيل Rovo.
• كيف يتم التحكم في مخرجات النموذج (Output Rendering) مثل الصور أو التنسيقات التي قد تحمل بيانات.
• سياسات الشبكة الصادرة (Outbound) وحدود السماح بالمجالات الخارجية.

3) تطبيق ضوابط الحوكمة على مستوى المؤسسة

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

4) وضع مراقبة لسلوك “الوصول + الإخراج”

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

• نماذج أنماط وصول غير معتادة لبيانات داخلية عبر حسابات مستخدمين.
• حجم/تكرار طلبات الشبكة الصادرة المرتبطة بجلسات المساعد.
• مخرجات محادثات تتضمن روابط أو عناصر قد تُستخدم كقنوات إخراج.

كيف نقرأ هذا الخبر دون تهويل؟

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

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

سؤال للنقاش: هل “تعطيل خيار” يكفي كحد أمان؟

إذا كان تعطيل بحث الويب لم يمنع—في حالة واحدة—مسار تسريب يعتمد على آلية أخرى لاسترجاع URL، فماذا يعني ذلك سياساتياً؟ هل تعتمد مؤسستكم على “مفتاح إعداد” واحد كحاجز أمان، أم لديها تصور واضح لقنوات الإخراج والمصادر والأدوات التي قد يستخدمها المساعد؟

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

روابط مساعدة:
حقن الأوامر (Prompt Injection),
تسريب البيانات (Data Exfiltration).

للتواصل والمتابعة:
فيسبوك |
إكس