صُمم الويب لعزل المواقع عن بعضها، لكن وكلاء الذكاء الاصطناعي يهدمون هذا الجدار

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

هذا الفصل الصامت بين المواقع هو أحد أهم الإنجازات الهندسية التي سمحت للويب الحديث بالنمو. واليوم يأتي Browser Agent (وكيل المتصفح) ليختبر صلابة هذا المبدأ. فإذا طلبنا منه حجز رحلة أو مقارنة منتجات أو تنظيم يوم عمل، سيحتاج إلى قراءة موقع، ونقل معلومة إلى موقع آخر، والنقر وملء النماذج والعمل من خلال حسابات سبق أن سجل المستخدم دخوله إليها.

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

Same-Origin Policy: الجدار الخفي الذي يحمي كل تبويب

يعتمد أمن الويب على قاعدة أساسية تسمى Same-Origin Policy (سياسة المصدر الواحد). وفي هذا السياق، يشير مصطلح Origin (المصدر) إلى هوية تقنية تحددها عادة ثلاثة عناصر: بروتوكول الصفحة، واسم النطاق، والمنفذ. تمنع هذه السياسة الشيفرة العاملة داخل موقع من قراءة محتوى حساس تابع لموقع ذي Origin مختلف أو تعديله بصورة تلقائية.

إذا أقنعك مهاجم بفتح صفحة خبيثة بينما بريدك أو حسابك المصرفي مفتوح في تبويب آخر، يفترض ألا تتمكن الصفحة من قراءة الرسائل أو معرفة الرصيد أو الوصول إلى ملفات الارتباط المخزنة. وتدعم هذا الحاجز آليات إضافية مثل Site Isolation (عزل المواقع) وBrowser Sandbox (صندوق حماية المتصفح).

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

كيف يغير Browser Agent قواعد اللعبة؟

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

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

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

تجربة عملية تتجاوز Same-Origin Policy

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

في التصميمات الأقل تقييداً، وجد الباحثان أن نجاح حقن أمر قد يسمح باستغلال الوكيل للالتفاف على Same-Origin Policy. وفي تجربة كاملة على ChatGPT Atlas باستخدام Agent Mode (وضع الوكيل)، وضعت تعليمات خبيثة في صفحة، ثم دفعت الوكيل إلى تضمين معلومات من إطار تابع لموقع آخر داخل ملخص، قبل إرسال النص المدمج عبر نموذج يسيطر عليه المهاجم.

كما ذكر الفريق أن Chrome مع Gemini وClaude for Chrome ومتصفح Comet من Perplexity امتلكت شروطاً مهمة قد تسمح بهجمات Cross-Origin (عابرة للمصادر) إذا نجح حقن الأمر. ورصد مخاطر أخرى تشمل Cross-Origin Action Forgery (تزوير إجراءات عبر مصادر مختلفة)، وقراءة بعض Masked Inputs (المدخلات المقنّعة)، وChat Memory Poisoning (تسميم ذاكرة المحادثة).

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

المشكلة ليست في نموذج الذكاء الاصطناعي وحده

قدمت أبحاث منفصلة من شركة Manifold Security مثالاً على أهمية التفاصيل البرمجية المحيطة بالنموذج. قالت الشركة إن إضافة Claude for Chrome أمكن دفعها بواسطة إضافة أخرى إلى تشغيل Workflows (مسارات عمل) قادرة على قراءة Gmail أو فتح مستندات Google، وإن معاملاً في رابط كان يستطيع إخفاء Permission Prompts (طلبات الأذونات) في حالات معينة. وأضاف الباحثون أنهم أعادوا اختبار المشكلات بعد إبلاغ Anthropic بها.

هذه نتائج ينسبها المقال إلى الباحثين وإلى نسخ وإعدادات محددة، وليست دليلاً على اختراق كل جلسة Claude أو كل متصفح يعمل بالذكاء الاصطناعي. لكنها تؤكد درساً مهماً: النموذج جزء واحد فقط. صلاحيات الإضافة، ومسارات العمل، ونوافذ الموافقة، وBrowser APIs (واجهات برمجة المتصفح) هي التي تحدد ما يستطيع النموذج المتلاعب به تنفيذه فعلياً.

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

لماذا لا يكفي أن نقول: أوقفوا Prompt Injection؟

لا يزال Prompt Injection (حقن الأوامر) مشكلة أمنية مفتوحة لأن Large Language Models أو LLMs (النماذج اللغوية الكبيرة) صُممت أصلاً لتفسير اللغة. والمرونة التي تساعد الوكيل على فهم طلب غير مألوف تجعل الفصل المطلق بين الأمر الموثوق والنص العدائي شديد الصعوبة.

تضع OWASP حقن الأوامر، وSensitive Information Disclosure (كشف المعلومات الحساسة)، وExcessive Agency (الصلاحيات التنفيذية المفرطة) ضمن أبرز مخاطر تطبيقات النماذج اللغوية. يمكن للتدريب الأفضل والمرشحات وكواشف الهجوم خفض الخطر، لكنها دفاعات احتمالية. ولا ينبغي أن يعتمد إجراء خطير على أن يصدر النموذج الحكم الصحيح في كل مرة.

لهذا يطرح الأمن التقليدي سؤالاً مختلفاً: إذا التبس الأمر على المكوّن الذكي، فما الذي تسمح له البنية التقنية بالوصول إليه وتغييره؟

حل غوغل المقترح: Agent Origin Sets لكل مهمة

شرحت غوغل تصميماً متعدد الطبقات لقدرات الوكيل في Chrome. يشمل التصميم نموذجاً منفصلاً يسمى User Alignment Critic (مراجع توافق الإجراء مع طلب المستخدم)، يراجع الإجراءات المقترحة من دون أن يرى المحتوى الخام غير الموثوق. ويشمل أيضاً كشف حقن الأوامر، وطلب موافقة المستخدم على الإجراءات الحساسة، واستخدام Agent Origin Sets (مجموعات المصادر الخاصة بالوكيل) لكل مهمة.

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

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

الجائزة الحقيقية هي Authenticated Web

لا يتعلق الحماس لوكلاء المتصفح بالراحة فقط. فـAuthenticated Web (الويب الذي سجل المستخدم دخوله إليه) يحتوي على واحدة من أغنى مجموعات الصلاحيات الرقمية: البريد، والتقويم، والملفات السحابية، والعناوين المحفوظة، وأنظمة العمل، وحسابات التسوق، وأحياناً وسائل الدفع.

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

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

كيف يبدو Agentic Browser أكثر أماناً؟

• Least Privilege (أقل قدر من الصلاحيات): يحصل الوكيل على المواقع والإجراءات الضرورية للمهمة الحالية فقط، ثم تُسحب الصلاحية.
• Origin-Aware Data Flow (تدفق بيانات يراعي المصدر): يحتفظ النظام بمكان قدوم المعلومة، ويمنع انتقال البيانات الحساسة إلى وجهة غير مرتبطة.
• Non-Bypassable Confirmation (موافقة لا يمكن تجاوزها): تتوقف عمليات الدفع وتغيير الحساب وإرسال الرسائل وتنزيل الملفات وتصدير البيانات عند نقطة يفرضها المتصفح.
• Trusted and Untrusted Separation (فصل المحتوى الموثوق عن غير الموثوق): لا يرى مكوّن المراجعة الأمنية المحتوى العدائي نفسه الذي ربما خدع نموذج التخطيط.
• Audit Logs (سجلات التدقيق): يحتاج المستخدم ومدير النظام إلى سجل مفهوم لما قرأه الوكيل وما حاول تنفيذه وما غيّره.
• Ephemeral Memory (ذاكرة مؤقتة): تنتهي ذاكرة المهمة، ولا ينتقل تأثير صفحة غير موثوقة بصمت إلى جلسات لاحقة.

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

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

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

لا حاجة إلى هدم الجدار

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

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