Atlassian Rovo يوضح لماذا تحتاج مساعدات AI إلى قواعد خروج

تبدو حقن التعليمات أحياناً كحيلة مخبرية ضد روبوت محادثة بسيط. لكن تقرير PromptArmor عن Atlassian Rovo أهم من ذلك، لأنه يوضح خطراً عملياً داخل الشركات: مساعد AI يقرأ بيانات عمل داخلية، يعالج محتوى غير موثوق، وما زال يملك طريقاً إلى عنوان خارجي. عند هذه النقطة يجب أن تكون حدود الأمان.

نشرت PromptArmor تقريرها في 5 أغسطس 2026. تقول الشركة إن Rovo يمكن التلاعب به لإرسال محتوى تذاكر Jira ووثائق Confluence إلى موقع يسيطر عليه مهاجم عبر تعليمات مخفية. وتقول أيضاً إنها أبلغت Atlassian في 23 مايو، وحصلت على رقم قضية في 25 مايو، ثم تابعت في يونيو ويوليو، ونشرت التقرير بعد أكثر من شهرين من دون إصلاح علني أو تواصل إضافي. عند إعداد هذا النص لم أجد رداً علنياً من Atlassian ينفي التقرير.

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

الخطر في جمع الصلاحيات

Rovo هو طبقة AI من Atlassian للعمل مع Jira وConfluence والخدمات المتصلة. تصفه Atlassian كمساعد يعرف عمل الشركة، يجمع سياق الأشخاص والمشاريع والكود، ويتصل بتطبيقات SaaS خارجية. صفحة الموصلات تذكر Google Drive وGitHub وGitLab وMicrosoft SharePoint وOutlook Mail وGmail وZendesk وBox وDropbox وFigma وAzure DevOps وServiceNow وSlack وغيرها.

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

تقول صفحات الثقة الخاصة بـ Atlassian إن صلاحيات المنصة والموصلات الخارجية تُحترم عند ضبطها بشكل صحيح. وتقول أيضاً إن الموصلات التي يديرها المسؤول ليست مفعلة افتراضياً، وإن بعض المصادر مثل Google Drive وSharePoint يمكن تقييدها بقوائم سماح أو حظر. هذه ضوابط مهمة، لكنها لا تجيب بالكامل عن سؤال PromptArmor: هل يستطيع المساعد أخذ بيانات كان مسموحاً له بقراءتها ووضعها في طلب خارجي بناه النموذج نفسه؟

سلسلة الهجوم الموصوفة

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

بعد ذلك يطلب المستخدم من Rovo مهمة عادية، مثل تنظيم التذاكر. يراجع Rovo بيانات Jira وConfluence لأن هذا جزء من وظيفته. تحاول التعليمات المخفية دفع المساعد إلى إضافة محتوى حساس داخل عنوان خارجي. ثم تفتح أداة URL ذلك العنوان، ويمكن للخادم المستقبل تسجيل البيانات في سجلاته.

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

ليست المشكلة أن النموذج صدّق التعليمات فقط

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

صياغة Simon Willison مفيدة هنا: بيانات خاصة، محتوى غير موثوق، واتصال خارجي. وجود عنصرين قد يكون قابلاً للإدارة. اجتماع العناصر الثلاثة يخلق مساراً لتسريب البيانات. Rovo ليس حالة وحيدة؛ يمكن أن يظهر النمط نفسه في وكلاء المتصفح، مساعدين للبرمجة، أدوات مكتبية، روبوتات دعم ومحركات بحث داخلية.

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

ما الذي يجب على المسؤولين فحصه

ابدأوا بالتحقق مما إذا كانت Rovo وميزات AI من Atlassian مفعلة في مؤسستكم. لا تعتمدوا على صفحة المنتج فقط؛ افحصوا لوحة إدارة المستأجر الفعلية.

بعد ذلك احصروا الموصلات. ركزوا على مستودعات الوثائق الواسعة، منصات الكود، أنظمة الدعم والبريد: Google Drive وSharePoint وGitHub وGitLab وZendesk وServiceNow وGmail وOutlook. الموصل المناسب للبحث قد يصبح أخطر إذا مزج المساعد نتائجه بتعليمات غير موثوقة وطلبات خارجية.

طبّقوا مبدأ أقل صلاحية. لا تربطوا جذراً كاملاً في Drive أو SharePoint إذا كانت قائمة محدودة من المجلدات تكفي. راجعوا المجموعات والضيوف والمتعاقدين والحسابات القديمة.

اسألوا Atlassian سؤالاً محدداً: إذا كان بحث الويب معطلاً، هل يستطيع Rovo فتح URL بناه النموذج؟ إذا كان ذلك ممكناً، هل يمكن تعطيل القدرة، أو تقييدها بمصادر موثوقة، أو تسجيل كل طلب؟

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

ما الذي يستطيع المستخدمون فعله

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

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