مصادقة وكيل الذكاء الاصطناعي: حالات الاستخدام واحتياجات الهوية

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

تجربة مصادقة وكيل ChatGPT#

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

أثناء عملية الدفع، طلب مني تسجيل الدخول ثم أعاد لي التحكم.

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

يعلن مشغل OpenAI أنه لا يقوم أبدًا بتخزين بيانات اعتماد المستخدم ويتبع معايير الامتثال مثل SOC II. ومع ذلك، عندما تتفاعل الوكلاء طرف ثالث مع خدمات خارجية نيابةً عنك، تزداد مخاطر الأمان بشكل كبير.

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

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

مثلما ناقشت الخيوط X.

كيف يتم التعامل مع بيانات الاعتماد، وما هي مخاطر الأمان؟#

إعطاء وكيل الذكاء الاصطناعي بيانات الاعتماد الخاصة بك مباشرةً#

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

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

بدلاً من بيانات اعتماد النص العادي، توفر الرموز المميزة للوصول الشخصي (PATs) طريقة أكثر أمانًا لمنح الوصول دون الحاجة إلى كلمة مرور أو تسجيل دخول تفاعلي. تكون الرموز المميزة للوصول الشخصي مفيدة لـ CI/CD والبرامج النصية والتطبيقات الآلية التي تحتاج إلى الوصول إلى الموارد برمجيًّا. لتحسين الأمان، من الأفضل تقييد نطاقات PAT، وتعيين أوقات انتهاء الصلاحية، والسماح بالإلغاء لمنع التسريبات واختطاف الحسابات.

تفويض المستخدم عبر OAuth#

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

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

طريقة أفضل للتعامل مع هذا السيناريو هي تفويض ChatGPT Operator (أو أي وكيل آخر) للقراءة والكتابة على Airbnb دون مشاركة كلمة المرور أو بيانات الاعتماد الخاصة بك. بدلاً من السماح للمشغل بتسجيل الدخول مباشرةً، يمكنك منح الوصول من خلال عملية تفويض آمنة.

في رأيي، إذا كانت OpenAI Operator ترغب في تعزيز الثقة وأمان الهوية، فهناك عدة طرق لتحقيق ذلك.

1. نقل عملية تسجيل الدخول خارج المشغل: إجراء توقيع المستخدم خارج ChatGPT Operator. يعني ذلك أنك قد تنقر على زر "تسجيل الدخول باستخدام [الخدمة]" ويتم توجيهك إلى صفحة تسجيل الدخول الآمنة الخاصة بالخدمة للتحقق من هويتك، تمامًا خارج المحادثة أو المشغل. على سبيل المثال، إذا كان هناك مكون إضافي لـ Airbnb، فسيتم توجيهك إلى موقع Airbnb لإدخال بيانات اعتمادك وتفويض ChatGPT، ومن ثم سيستلم المكون الإضافي رمزًا. يتلقى ChatGPT فقط رمز وصول مؤقت أو مفتاح، مما يمنح الوصول المحدود (مثل "قراءة رحلتي")، بدلاً من رؤية كلمة المرور الحقيقية الخاصة بك.

2. جعل المستخدم يكمل تدفق الموافقة قبل أن يؤدي وكيل الذكاء الاصطناعي أي مهام. هذا النهج مشابه لكيفية تعامل العديد من المنتجات مع التكاملات والأسواق والخدمات المتصلة.

   صفحات اتصال النوتيون

   هنا مثال آخر، تمامًا مثل تكامل سوق Slack مع النوتيون. يطلب Slack الوصول إلى مساحة عمل محددة في النوتيون، ويمكنه قراءة المقالات وتقديمها في قنوات Slack الخاصة بك.

في الوقت نفسه، يوفر Slack أيضًا صفحة موافقة لتفويض النوتيون للوصول إلى مساحة العمل خلال هذه العملية.

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

تعزيز المصادقة للأنشطة الحساسة#

يمكن لوكيل الذكاء الاصطناعي التعامل مع المهام الروتينية بشكل مستقل وذاتي، ولكن بالنسبة للإجراءات ذات الخطورة العالية، يلزم التحقق الإضافي لضمان الأمان، — مثل إرسال الأموال أو تعديل إعدادات الأمان — يجب على المستخدم التحقق من هويته من خلال مصادقة متعددة العوامل (MFA). يمكن القيام بذلك عبر إشعارات الدفع، كلمات المرور المؤقتة (OTPs)، أو التحقق عبر القياسات الحيوية.

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

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

هوية موحدة وتسجيل دخول واحد (SSO) لأنظمة متعددة الوكلاء#

في نظام متعدد الوكلاء، يحتاج وكلاء الذكاء الاصطناعي غالبًا إلى التفاعل عبر منصات مختلفة. لتبسيط عملية المصادقة، يقوم المستخدمون بالتوثيق مرة واحدة عبر موفر الهوية (IdP) مثل Okta أو Azure AD أو جوجل Workspace. ثم يقوم الوكلاء بالمصادقة باستخدام SAML، OpenID Connect (OIDC)، مع إدارة الوصول من خلال التحكم في الوصول المستند إلى الأدوار (RBAC) أو التحكم في الوصول المستند إلى السمة (ABAC).

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

إدارة النطاق والأذونات#

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

1. الامتيازات الأدنى – منح الأذونات اللازمة فقط للعملية.
2. الوصول المحدود زمنيًا – تقييد مدة الوصول للحد من مخاطر الأمان.

يساعد التحكم في الوصول المستند إلى الأدوار (RBAC) في إدارة نطاق الوكيل عن طريق تعيين أدوار محددة لمهام معينة. للحصول على سيطرة أكثر دقة، يتيح التحكم في الوصول المستند إلى السمة (ABAC) إدارة أذونات سياقية وديناميكية، مما يضمن وصول الوكلاء إلى ما يحتاجونه فقط عند الحاجة.

توصيل خوادم MCP مع المصادقة#

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

لماذا يرتبط خادم MCP بالمصادقة، ولماذا يهم؟#

كتبنا سابقًا مقالًا لمساعدتك على فهم ما هو خادم MCP.

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

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

مرجع: https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained

بالنسبة لوكلاء الذكاء الاصطناعي الذين يستخدمون خادم MCP، تحدث تفاعلات متعددة بين خادم MCP، LLM، الوكيل، والمستخدم.

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

المصادقة عبر الوكيل آخذة في الظهور - يجب أن يتكيف منتجك#

مثال رائع هو Composio.dev، وهي منصة تكامل تركز على المطورين تعمل على تبسيط كيفية اتصال وكلاء الذكاء الاصطناعي والنماذج اللغوية الكبيرة (LLMs) بالتطبيقات والخدمات الخارجية. يُطلق عليه " المصادقة لوكلاء الذكاء الاصطناعي للعمل نيابة عن المستخدمين"، وهو في الأساس يوفر مجموعة من خوادم MCP (الموصلات) التي يمكن بسهولة دمجها في المنتجات القائمة على الذكاء الاصطناعي.

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

بناءً على الأمثلة السابقة، إذا اعتبرنا Google Drive (الخدمات البعيدة) كخادم MCP بدلاً من Airbnb، فإنه يصبح أكثر من مجرد تكامل طرف ثالث — إنه يعمل كمصدر بيانات خارجي. هذا يمكّن الوكيل من الوصول إلى المعلومات السياقية، والتفاعل مع النموذج اللغوي الكبير، وقد يكتسب الأذونات لإنشاء وقراءة وتحديث وحذف (CRUD) الملفات.

ومع ذلك، تبقى متطلبات المصادقة والتفويض الأساسية كما هي.

استخدام Logto للتعامل مع المصادقة لمنتجات الوكلاء الخاصة بك#

Logto هو حل CIAM متعدد الاستخدامات يدعم منتجات SaaS ووكيل الذكاء الاصطناعي، مما يجعل المصادقة والتفويض سهلًا. إليك السبب:

1. إدارة المصادقة لمنتجات وكيل الذكاء الاصطناعي – يدعم Logto OAuth 2.0 وSAML ومفاتيح API والرموز المميزة للوصول الشخصي وJWT، مما يسمح بالتكامل السهل مع خوادم MCP المتعددة. يمكنك حتى بناء خادم MCP خاص بك وربطه بـ Logto، بفضل بنيته المفتوحة المعايير.
2. قدرات موفر الهوية (IdP) – بمجرد أن يكون لديك مستخدمون مؤكدون لخدمتك، يمكن لـ Logto أن يعمل كموفر هوية، ويحول خدمتك إلى خادم MCP ويدمجها في نظام الذكاء الاصطناعي.
3. تفويض متقدم
   1. التحكم في الوصول المستند إلى الأدوار (RBAC) لإدارة أدوار المستخدم
   2. تحكم في الوصول المستند إلى الأذونات الموافق عليها باتفاقية JWT للتحكم الديناميكي الدقيق في الوصول
4. تحسين الأمان – ميزات مثل المصادقة متعددة العوامل (MFA) وتعزيز المصادقة تساعد في تأمين الإجراءات الحرجة وتحسين أمان الوكيل.

هل لديك أسئلة؟ تواصل معنا لمعرفة كيف يمكن لـ Logto تحسين تجربة وكيل الذكاء الاصطناعي الخاصة بك وتلبية احتياجات الأمان الخاصة بك.