تطرح Google تصوراً أمنياً متعدد الطبقات لقدرات التصفح الوكيلي في Chrome، مع التركيز على التهديد الأبرز أمام المتصفحات القادرة على تنفيذ المهام تلقائياً: حقن الأوامر غير المباشر. ويمكن لهذا النوع من الهجمات أن يظهر داخل مواقع ضارة أو محتوى تابع لجهات خارجية في إطارات iframe أو مراجعات المستخدمين، ثم يدفع الوكيل إلى تنفيذ أفعال لا تتوافق مع هدف المستخدم، مثل بدء معاملات مالية أو إخراج بيانات حساسة.
تقول Google إن تصميم التصفح الوكيلي الآمن في Chrome استفاد من تعاون خبراء الأمن في الشركة، ومن وسائل الحماية القائمة في Gemini ومبادئ أمن الوكلاء. وتجمع البنية المقترحة بين دفاعات حتمية وأخرى احتمالية، بهدف جعل استغلال الوكيل أكثر صعوبة وكلفة، مع إبقاء المستخدم داخل دائرة التحكم عند تنفيذ الإجراءات المؤثرة.
نموذج مستقل لمراجعة أفعال الوكيل
يعتمد Gemini في مرحلة التخطيط على محتوى الصفحات الذي يشاركه Chrome معه لتحديد الخطوة التالية. لكن هذا المحتوى غير موثوق بطبيعته، ولذلك يظل نموذج التخطيط عرضة لمحاولات التأثير التي تهدف إلى تغيير مسار المهمة. وتستخدم Google تقنيات مثل Spotlighting لتوجيه النموذج إلى تفضيل تعليمات المستخدم والنظام على التعليمات الموجودة في الصفحة، كما أدرجت هجمات معروفة ضمن تدريب Gemini لمساعدته على تجنبها.
ولإضافة طبقة أخرى، تقدم Google مكوّناً باسم User Alignment Critic، وهو نموذج منفصل مبني باستخدام Gemini ويعمل بوصفه مكوّناً عالي الثقة. يأتي هذا النموذج بعد اكتمال التخطيط ليفحص كل فعل مقترح، ويركز على سؤال محدد: هل يخدم الفعل الهدف الذي حدده المستخدم؟ وإذا اعتبر الفعل غير متوافق مع الهدف، يستطيع رفضه.
لا يرى هذا المكوّن محتوى الويب غير المصفى، بل يطّلع على بيانات وصفية مرتبطة بالفعل المقترح. وتمنحه هذه البنية سياقاً أقل، لكنها تبقي مهمته أبسط وأكثر عزلاً عن المحتوى الضار: الموافقة أو الرفض. وعند رفض أحد الأفعال، يرسل الناقد ملاحظاته إلى نموذج التخطيط لإعادة صياغة الخطة، فيما يستطيع النظام إعادة التحكم إلى المستخدم عند تكرر حالات الفشل.
تقييد نطاق المواقع التي يستطيع الوكيل الوصول إليها
تمدد Google مبادئ عزل المواقع وسياسة المصدر نفسه إلى بيئة الوكلاء عبر مفهوم Agent Origin Sets. فالوكلاء يحتاجون إلى العمل عبر أكثر من موقع، مثل جمع مكونات من موقع ثم تعبئة عربة تسوق في موقع آخر، لكن منح وكيل مخترق قدرة غير مقيدة على التفاعل مع مواقع عشوائية قد يحوله إلى مسار لتجاوز عزل المواقع وتسريب البيانات من جلسات تسجيل الدخول المحلية.
تحدد وظيفة تحكم موثوقة الأصول المرتبطة بالمهمة، وتقسمها لكل جلسة إلى مجموعتين واضحتين:
- أصول للقراءة فقط: يُسمح لـGemini باستهلاك محتواها، بينما لا يظهر للنموذج محتوى إطار iframe إذا لم يكن مصدره ضمن هذه المجموعة.
- أصول للقراءة والكتابة: يُسمح للوكيل بالقراءة منها وتنفيذ أفعال عليها، مثل النقر والكتابة.
يحد هذا الفصل من احتمال تمرير البيانات بين مصادر غير مرتبطة بالمهمة، كما يسمح للمتصفح بعدم إرسال البيانات الواقعة خارج مجموعة القراءة إلى النموذج أصلاً. ولا يستطيع نموذج التخطيط إضافة مصادر جديدة من تلقاء نفسه؛ إذ يجب أن توافق وظيفة التحكم عليها. وينطبق فصل مشابه على المحتوى غير المرتبط بالويب، مثل استدعاءات الأدوات، عبر التمييز بين استدعاءات القراءة والكتابة والتحقق من ملاءمتها للمهمة.
كما تخضع عمليات الانتقال إلى مصادر جديدة للمراجعة. فإذا اقترح المخطط الانتقال إلى مصدر غير موجود في مجموعة القراءة، تتحقق نسخة من User Alignment Critic من صلته بالمهمة قبل إضافته وبدء الانتقال. وتستخدم Chrome أيضاً فحصاً حتمياً لتقييد عناوين URL التي ينشئها النموذج بالعناوين العامة المعروفة، لأن العناوين المصممة من النموذج قد تُستغل لإخراج معلومات خاصة. أما إذا انتقلت الصفحة تلقائياً إلى مصدر جديد، فيخضع المصدر للمراجعة نفسها.
تقر Google بأن ضبط هذه الحدود من المحاولة الأولى صعب قبل معرفة كيفية تفاعل مهام المستخدمين معها. ولذلك طبقت مبدئياً نسخة أبسط من التحكم في الأصول تتابع مجموعة القراءة والكتابة، مع خطط لضبط وظائف التحكم وبقية عناصر النظام لتقليل الاحتكاك وتحسين الأمان.
تأكيدات المستخدم ومراقبة الإجراءات الحساسة
يعرض Chrome خطوات الوكيل في سجل عمل داخل علامة التبويب، بحيث يستطيع المستخدم متابعة ما يحدث لحظة بلحظة، كما يمكنه إيقاف المهمة أو استعادة التحكم في أي وقت. وتدعم هذه الشفافية مجموعة من الفحوص الحتمية والقائمة على النماذج، التي تطلب تأكيد المستخدم قبل الإجراءات المؤثرة.
تشمل نقاط التوقف الأساسية ما يلي:
- طلب تأكيد قبل الانتقال إلى مواقع حساسة، مثل المواقع المتعلقة بالمعاملات المصرفية أو المعلومات الطبية الشخصية، استناداً إلى فحص حتمي لقائمة من المواقع الحساسة.
- طلب تأكيد قبل تسجيل الدخول إلى موقع باستخدام Google Password Manager، مع عدم إتاحة كلمات المرور المخزنة مباشرة للنموذج.
- التوقف قبل إجراءات مثل إتمام عملية شراء أو دفع أو إرسال رسالة أو أي فعل ذي تبعات، ثم طلب الإذن أو مطالبة المستخدم بتنفيذ الخطوة التالية.
الكشف والاختبار والاستجابة
يفحص النظام كل صفحة يراها الوكيل بحثاً عن حقن أوامر غير مباشر، بالتوازي مع فحص Chrome الفوري عبر Safe Browsing والذكاء الاصطناعي على الجهاز لرصد عمليات الاحتيال التقليدية. ويعمل مصنف حقن الأوامر بالتوازي مع استدلال نموذج التخطيط، ويمكنه منع الأفعال التي يحدد أن محتوى الصفحة دفع إليها بهدف إبعاد الوكيل عن غرض المستخدم. وتقر Google بأن المصنف لن يرصد كل تأثير ضار محتمل، لكنه يمثل طبقة إضافية ضمن دفاع متعدد الطبقات.
وللتحقق من فعالية هذه الضوابط، أنشأت Google أنظمة اختبار هجومي آلية تولد مواقع ضارة معزولة تحاول إخراج الوكيل عن مساره. تبدأ الاختبارات بهجمات صاغها باحثون أمنيون، ثم توسعها باستخدام نماذج لغوية وتقنية جرى تكييفها لوكلاء المتصفح. وتركز الاختبارات على المحتوى واسع الانتشار، مثل منشورات المستخدمين على مواقع التواصل والإعلانات، وعلى الهجمات التي قد تسبب ضرراً مستديماً، مثل المعاملات المالية أو تسريب بيانات الاعتماد. وتستخدم Google معدل نجاح الهجمات لتقييم التغييرات الهندسية ومنع التراجعات، بينما تساعد التحديثات التلقائية لـChrome في إيصال الإصلاحات بسرعة.
حدّثت Google إرشادات برنامج مكافآت الثغرات لديها لتوضيح كيفية تركيز الباحثين الخارجيين على قدرات Chrome الوكيلية، وتقول إنها ستدفع ما يصل إلى 20,000 دولار للثغرات الخطيرة التي تثبت اختراق الحدود الأمنية. وتؤكد الشركة أن أمن وكلاء الويب لا يزال مجالاً ناشئاً، وأن هذه الحماية ستتطور مع استمرار الاختبار والتعاون مع مجتمع أبحاث الأمن.