كيف تدير Manus حالة تسجيل الدخول وبيانات اعتماد المستخدم في متصفح السحابة

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

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

في المقالة السابقة، ناقشنا مخاطر الأمان المرتبطة، خصوصًا عندما يدير المتصفح بيانات اعتماد المستخدم، مما قد يؤدي إلى وجود ثغرات أمنية. https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience

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

في هذه المقالة، سأستعرض كيف يواجه بعض الوكلاء بالفعل التحدي الذي أسميه "تسجيل الدخول والمصادقة داخل المتصفح".

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

نهج Manus: "تسجيل الدخول مرة واحدة، وابق متصلاً"#

صممت Manus ميزة تسمى المتصفح السحابي، والتي تعمل كجهاز كمبيوتر بعيد ومعزول يعمل بالكامل في السحابة. فكر فيها كمتصفح ويب خاص بالوكيل الخاص بك، مع ميزة رئيسية: يمكنه تذكر حالة تسجيل الدخول الخاصة بك، حتى عبر الأجهزة والمهام المختلفة.

إليك كيف تعمل:

1. تسجل الدخول يدويًا إلى موقع ويب داخل المتصفح السحابي. هذا يحتاج أن يحدث مرة واحدة فقط لكل موقع.
2. تقوم Manus بحفظ بيانات جلستك: الكوكيز، التخزين المحلي، وكل ما يحافظ على تسجيل دخولك.
3. تتم تشفير هذه البيانات مرتين: أولاً محليًا، ثم ثانية في السحابة. لا يتم حفظ أي شيء كنص صريح.
4. عندما يحتاج الوكيل لإعادة زيارة هذا الموقع، تقوم Manus تلقائيًا بحقن الجلسة في صندوق آمن جديد. يظن الموقع أنك لا تزال متصلاً.
5. يمكنك المزامنة بين الأجهزة، ومسح بيانات الجلسة يدويًا في أي وقت من الإعدادات.

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

المتصفحات المحلية (مثل Chrome) والمتصفحات السحابية المدعومة بالوكيل#

قد تسأل: "أليس هذا مثل استخدام Chrome؟ لماذا يبدو المتصفح السحابي المدعوم بالوكيل أكثر خطورة؟" دعنا نوضح الأسباب.

• لماذا يكون من الآمن عمومًا إعطاء بيانات الاعتماد الخاصة بك لـ Chrome
• لماذا قد يكون إعطاؤها لمتصفح وكيل سحابي أكثر خطورة
• من يُعتبر "طرفًا أول" مقابل "طرف ثالث" في كل سياق

الاختلافات الجوهرية: المتصفح المحلي مقابل متصفح الوكيل السحابي#

لماذا من الأكثر أمانًا إعطاء Chrome اسم المستخدم وكلمة المرور#

1. أنت المشغّل Chrome هو واجهة طرف أول، تتحكم فيه، وترى ما يفعله، ويتبع بيئة الحوسبة الخاصة بك. تدخل كلمات المرور عن قصد، والمتصفح يوفر مطالبات مرئية وقابلة للتدقيق.

2. تكامل الأمان المحكم تخزن المتصفحات مثل Chrome كلمات المرور باستخدام تخزين نظام التشغيل الآمن، وغالبًا ما تتطلب بصمة حيوية أو الدخول للجهاز لفك التشفير. كما تعمل التعبئة التلقائية فقط في السياقات المتوقعة (مثال: النطاقات المطابقة).

3. الحد الأدنى من التفويض أنت لا "تعطي" Chrome كلمة مرورك بشكل دائم، بل يتذكر ما كتبته بإذنك الصريح. أنت الفاعل، وليس طرفًا ثالثًا.

لماذا المتصفحات السحابية للوكيل تحمل مخاطر#

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

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

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

الطرف الأول مقابل الطرف الثالث#

دعونا نشرح حقًا ما يعنيه الطرف الأول مقابل الطرف الثالث ولماذا يُرى Chrome كطرف أول، في حين أن متصفح وكيل سحابي ليس كذلك.

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

لكن، كما توضح Manus:

نحن نحفظ معلومات تسجيل الدخول الخاصة بك كمجموعة من الملفات المشفرة ونرفعها بأمان إلى خوادمنا. هذه المعلومات تتضمن:

• ملفات الكوكيز
• التخزين المحلي

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

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

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

ما الذي تتقنه Manus (وما يمكن أن يسوء)#

ما يعمل بفعالية:#

• جلسات سلسة تمامًا: لست بحاجة لتسجيل الدخول في كل مرة، حتى عبر جهاز مختلف.
• أمان يركز على المستخدم: كل شيء مشفّر من الطرف للطرف، وتتحكم بالكامل في ما يتم تخزينه.
• شفافية واحترام: Manus لا تستخدم بيانات الدخول الخاصة بك للتدريب أو التحليلات.

ما يحتاج الانتباه:#

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

طرق أخرى يتعامل بها الوكلاء مع تسجيل الدخول#

تقدم Manus نهجًا ذكيًا لكنه ليس الوحيد. دعنا نستعرض طرقًا شائعة أخرى يستخدمها الوكلاء لتسجيل الدخول نيابة عن المستخدمين:

إدخال بيانات الاعتماد#

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

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

رموز OAuth#

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

طرق برمجية أخرى (مثل مفاتيح API)#

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

كل طريقة تمثل توازنًا بين سهولة الاستخدام والأمن. إعادة تشغيل الجلسة بنمط Manus في الوسط: أكثر مرونة من OAuth عند كثير من الحالات، لكنها ليست آمنة فطريًا مثله.

من المثالي في هذا السيناريو القائم على المتصفح أن تدمج Manus مسبقًا مع مواقع محددة (مثل قائمة مرقمة للمواقع المدعومة). يمنح المستخدمون موافقة مسبقة، بحيث يعمل الوكيل بأمان باستخدام رموز OAuth بدل تخزين البيانات أو إعادة تشغيل الجلسات.

إلى أين يتجه المستقبل: الوكلاء كمهنيين موثوقين#

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

نتجه نحو:

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

باختصار: سينتقل الوكلاء من "روبوتات مساعدة" إلى "مشغلين معتمدين"، ولديهم بيانات الاعتماد المناسبة لذلك.

ما هي الخزينة، ولماذا هي مهمة؟#

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

لهذا السبب تعتبر أدوات مثل الخزينة أو أنظمة إدارة مفاتيح التشفير (EKM) مهمة.

الخزينة هي حل لإدارة الأسرار يسمح للفرق بـ:

• تخزين الرموز، ومفاتيح API، وبيانات الاعتماد بأمان
• إصدار بيانات اعتماد ديناميكية قصيرة المدى عند الطلب
• التحكم في من يمكنه الوصول إلى ماذا، مع سجلات مراقبة كاملة
• تدوير الأسرار تلقائيًا وسحب الصلاحية على الفور
• التكامل مع قنوات CI/CD وتطبيقات السحابة

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

أفكار أخيرة#

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

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

عندما يمتلك ذكاؤك الاصطناعي مفاتيح حياتك الرقمية، تريد أن تعرف: من منحهم، ومدة صلاحيتهم، وأي باب يفتحونه بالفعل.

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

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