المشكلة في موصلات الذكاء الاصطناعي ليست في الاتصال بالخدمة بحد ذاته، بل في مقدار ما يستطيع الموصل قراءته أو تغييره بعد الاتصال. قد تحتاج مهمة بسيطة إلى قراءة ملف واحد، بينما تُمنح الأداة صلاحية أوسع تشمل مجلدات كاملة أو البريد أو التقويم أو القدرة على التعديل والحذف. لذلك فإن تقليل صلاحيات موصلات الذكاء الاصطناعي يبدأ من سؤال بسيط: ما أقل مستوى وصول يسمح للمهمة بالعمل دون منح قدرة إضافية لا تستخدمها فعليًا؟
هذا النهج يطابق مبدأ أقل صلاحية أو Least Privilege، الذي يعرّفه المعهد الوطني الأمريكي للمعايير والتقنية NIST بأنه قصر موارد النظام وصلاحياته على الحد الأدنى اللازم لتنفيذ الوظيفة المطلوبة. الفكرة لا تمنع استخدام الموصلات، وإنما تجعل نطاق الضرر المحتمل أصغر إذا أسيء استخدام حساب أو رمز وصول أو أداة متصلة.
قبل منح أي صلاحية للموصل
قبل أن تكمل
- ابدأ بصلاحية القراءة فقط إذا كانت المهمة لا تحتاج إلى إنشاء أو تعديل بيانات.
- اربط الحساب أو المجلد أو مساحة العمل المطلوبة بدل إتاحة نطاق أوسع متى كان ذلك ممكنًا.
- افصل بين صلاحيات مزوّد الخدمة نفسه وبين صلاحيات تنفيذ الإجراءات داخل أداة الذكاء الاصطناعي.
- تجنّب الأذونات الشاملة مثل الوصول إلى جميع الملفات أو البريد أو الدليل المؤسسي ما لم تكن الوظيفة تعتمد عليها فعلًا.
- اجعل الإجراءات المؤثرة، مثل الإرسال والحذف والتعديل، بحاجة إلى موافقة عندما تدعم المنصة ذلك.
- راجع الصلاحيات بعد انتهاء المشروع واسحب ما لم يعد مطلوبًا.
ابدأ بالمهمة لا باسم الموصل
من الأخطاء الشائعة أن تبدأ بالسؤال: «ما الصلاحيات التي يحتاجها موصل Google Drive أو Outlook أو Slack؟». السؤال الأدق هو: ماذا أريد من الموصل أن يفعل في هذه المهمة تحديدًا؟ فقد يكون الغرض مجرد العثور على مستند وقراءته، أو تلخيص رسائل، أو إنشاء حدث في التقويم، أو تعديل سجل داخل نظام أعمال. كل حالة تتطلب نطاقًا مختلفًا.
اكتب الوظيفة المطلوبة بجملة واحدة قبل الاتصال، مثل: «أريد قراءة المستندات الموجودة في مجلد المشروع وتلخيصها، دون تعديلها». هذه الجملة تكشف مباشرة أن الكتابة والحذف وإنشاء الملفات ليست ضرورية. وإذا كانت المهمة «إنشاء مواعيد جديدة بعد موافقتي»، فقراءة التقويم والكتابة فيه قد تكون ضرورية، لكن حذف الأحداث أو الوصول إلى البريد لا يصبح ضروريًا لمجرد أن الحساب نفسه يحتوي عليهما.
كل قدرة لا تحتاجها المهمة هي صلاحية يمكن محاولة الاستغناء عنها.
حوّل الوظيفة إلى قائمة صلاحيات قبل الاتصال
أفضل طريقة عملية هي تفكيك المهمة إلى أفعال وموارد ونطاق. بدل قبول شاشة أذونات طويلة باعتبارها خطوة روتينية، حدد مسبقًا ما تتوقع رؤيته فيها.
- حدد البيانات: هل يحتاج الموصل إلى ملفات، بريد، تقويم، محادثات، جهات اتصال أم نظام إدارة مشاريع؟
- حدد الفعل: هل المطلوب بحث وقراءة فقط، أم إنشاء، أم تعديل، أم حذف؟
- حدد النطاق: هل يحتاج إلى عنصر واحد، مجلد، قناة، صندوق بريد، مساحة عمل أم المؤسسة كاملة؟
- حدد المدة: هل الاتصال مطلوب باستمرار أم لفترة تنفيذ مهمة محددة؟
- حدد صاحب الحساب: هل يمكن استخدام حساب مخصص محدود الصلاحيات بدل حساب المدير أو الحساب الرئيسي؟
- حدد ما يتطلب موافقة: خصوصًا الإرسال، النشر، الحذف، تغيير الصلاحيات أو تعديل بيانات مهمة.
بعد ذلك قارن القائمة بشاشة التفويض. إذا وجدت إذنًا لا تستطيع ربطه بوظيفة واضحة، فلا تعتبره مطلوبًا تلقائيًا. تحقق من وثائق الخدمة أو من إمكانية تعطيل الوظيفة التي تحتاج ذلك الإذن.
القراءة والكتابة والحذف ليست مستوى واحدًا من المخاطرة
التمييز بين أنواع الإجراءات مهم أكثر من عدد الأذونات وحده. موصل يقرأ عددًا محدودًا من الملفات يختلف جذريًا عن موصل يستطيع تعديلها أو إرسال رسائل باسم المستخدم أو حذف محتوى. لذلك لا يكفي أن تقول إن الموصل «يحتاج الوصول إلى التقويم»؛ يجب معرفة ما إذا كان سيقرأ الأحداث فقط أم ينشئها ويعدّلها.
| نوع القدرة | متى تكون مناسبة؟ | ما الذي يجب مراجعته؟ |
|---|---|---|
| قراءة | البحث والتلخيص والتحليل | نطاق البيانات التي يمكن رؤيتها |
| إنشاء | إنشاء موعد أو ملف أو مهمة جديدة | مكان الإنشاء وإمكانية التنفيذ دون مراجعة |
| تعديل | تحديث بيانات موجودة يحتاجها سير العمل | حدود العناصر التي يستطيع تغييرها |
| حذف أو إجراءات حساسة | فقط عندما تكون الوظيفة مستحيلة دونها | التأكيد المسبق وسجلات التدقيق وإمكانية الاسترجاع |
وتوضح وثائق Microsoft Graph الرسمية أن الأذونات المتدرجة تسمح للتطبيق بطلب الحد الأدنى اللازم، كما تفرق بين الصلاحيات المفوضة التي تعمل نيابة عن مستخدم مسجل الدخول وبين صلاحيات التطبيق التي يمكن أن تعمل دون وجود مستخدم مسجل الدخول. وتوصي Microsoft باستخدام النموذج الأقل امتيازًا متى كان يحقق متطلبات التطبيق.
ضيّق الوصول عند مزوّد الخدمة وعند أداة الذكاء الاصطناعي
هناك طبقتان مختلفتان يجب عدم الخلط بينهما. الطبقة الأولى هي ما سمحت به عند ربط الحساب لدى Google أو Microsoft أو أي مزوّد آخر. الطبقة الثانية هي ما تسمح لأداة الذكاء الاصطناعي بفعله باستخدام الاتصال المتاح. تقليل الطبقة الثانية لا يلغي تلقائيًا إذنًا واسعًا منحته في الطبقة الأولى.
في Google مثلًا، توضح وثائق OAuth الرسمية أن نطاقات الوصول تختلف بحسب مستوى الوصول المطلوب، وأن بعض النطاقات تُصنف حساسة، كما توصي باختيار نطاق غير حساس عندما يحقق الغرض. لذلك يجب فحص الـ Scope نفسه، لا الاكتفاء باسم التطبيق أو الخدمة.
وفي ChatGPT، تشرح وثائق إدارة أذونات التطبيقات أن إعدادات صلاحيات التطبيق تحدد متى يمكن قراءة المعلومات أو تنفيذ إجراء، لكنها لا تمنح موفر البيانات صلاحيات جديدة ولا تتجاوز سياسات مساحة العمل أو الصلاحيات الموجودة في النظام المصدر. لهذا السبب يجب مراجعة الجانبين معًا.
لا تمنح صلاحية المدير لتسهيل الإعداد
استخدام حساب يمتلك صلاحيات واسعة قد يجعل الإعداد أسهل، لكنه يوسع ما يمكن للموصل الوصول إليه إذا كانت الصلاحيات تنتقل من المستخدم نفسه. الأفضل، متى كانت الخدمة تدعم ذلك، استخدام حساب أو دور مخصص للوظيفة، بحيث لا يرى إلا الموارد التي يحتاجها.
إذا كان المطلوب تحليل مستندات فريق واحد، فمن الأفضل أن يكون للحساب المستخدم وصول إلى تلك المستندات فقط بدل امتلاك وصول إداري إلى مساحة العمل كاملة. وإذا كانت المهمة تحتاج تقويمًا مشتركًا، فلا يوجد سبب تلقائي لمنحها سلطة إدارة المستخدمين أو الدليل المؤسسي.
هذا مهم خصوصًا مع الصلاحيات التي تعمل دون مستخدم حاضر. تشير Microsoft إلى أن صلاحيات التطبيق Application Permissions أعلى حساسية لأنها تتيح للتطبيق الوصول إلى الموارد دون مستخدم مسجل الدخول، بينما تكون الصلاحيات المفوضة أنسب من منظور أقل صلاحية عندما تفي بالغرض.
ضع حاجز موافقة أمام الإجراءات التي تغيّر البيانات
إذا كان الموصل يستطيع إرسال رسالة أو تحديث مستند أو إنشاء تذكرة أو حذف عنصر، فوجود تأكيد قبل التنفيذ يقلل احتمال تنفيذ أمر غير مقصود. لا يعني ذلك أن كل عملية قراءة تحتاج إلى موافقة يدوية، وإنما يجب رفع مستوى التدقيق كلما ارتفع أثر الإجراء.
في إعدادات التطبيقات المدعومة داخل ChatGPT قد تظهر مستويات مختلفة من الموافقة، مثل السؤال قبل الإجراء أو السماح ببعض الإجراءات منخفضة المخاطر. وتوضح وثائق OpenAI أن خيار السماح الدائم، عندما يكون متاحًا لاتصال مؤهل، يحمل مخاطرة أعلى لأن بعض الإجراءات المدعومة قد تنفذ دون طلب تأكيد جديد. لذلك لا ينبغي استخدامه لمجرد التخلص من نوافذ الموافقة.
أما موصلات MCP المخصصة التي تستطيع الكتابة أو التعديل، فالأفضل كذلك تعطيل الأدوات غير الضرورية من الأساس بدل الاعتماد فقط على حسن صياغة الأوامر. تشير وثائق OpenAI الخاصة بتطبيقات MCP إلى إمكان التحكم في الإجراءات المتاحة في بيئات العمل المؤهلة، مع تحذيرات إضافية للأفعال التي تعدل البيانات.
اختبر الحد الأدنى قبل توسيع الصلاحيات
لا تبدأ بأوسع صلاحية ثم تحاول تقليصها لاحقًا. الأسلوب الأنظف هو العكس: ابدأ بأضيق مجموعة أذونات تتوقع أنها تكفي، ثم نفّذ سيناريو واقعيًا. إذا فشل جزء من الوظيفة، حدد الإذن الذي يحتاجه ذلك الجزء فقط.
مثال ذلك: إذا كنت تريد تلخيص ملفات مشروع، ابدأ بإتاحة القراءة على الملفات المطلوبة. جرّب البحث والفتح والتلخيص. إذا نجحت المهمة فلا تضف الكتابة. وإذا احتجت في مرحلة لاحقة إلى إنشاء تقرير جديد، أضف قدرة الإنشاء المناسبة دون الانتقال تلقائيًا إلى صلاحية تعديل جميع الملفات.
ويُفضّل إجراء الاختبار أولًا على بيانات غير حساسة أو حساب تجريبي عندما تكون الأداة جديدة أو الموصل مخصصًا، خصوصًا إذا كان يستطيع تنفيذ أوامر كتابة. بهذه الطريقة تستطيع معرفة السلوك الفعلي قبل إعطاء الاتصال بيانات أو قدرات يصعب التراجع عن آثارها.
علامات تشير إلى أن الموصل حصل على أكثر مما يحتاج
- مهمة للقراءة فقط تطلب صلاحيات تعديل أو حذف.
- الوصول إلى خدمة كاملة بينما تحتاج إلى مجلد أو قناة أو مشروع واحد.
- طلب صلاحيات إدارية أو مؤسسية لمهمة خاصة بمستخدم واحد.
- قدرة على تنفيذ إجراءات دون مستخدم حاضر مع أن المهمة تعمل تفاعليًا فقط.
- ربط البريد أو جهات الاتصال دون علاقة مباشرة بوظيفة الموصل.
- منح خيار «السماح دائمًا» لإجراءات يمكن أن تغير بيانات مهمة دون حاجة تشغيلية واضحة.
- استمرار الاتصال بعد انتهاء المشروع أو توقف استخدام الموصل.
وجود إحدى هذه العلامات لا يثبت وحده أن الموصل غير آمن؛ بعض الخدمات تحتاج نطاقًا أوسع بسبب تصميم واجهتها البرمجية. لكنه سبب كافٍ لمراجعة التوثيق ومعرفة ما إذا كان هناك نطاق أدق أو صلاحية أقل امتيازًا تحقق الوظيفة نفسها.
راجع الصلاحيات كما تراجع كلمات المرور والمستخدمين
الصلاحية التي كانت ضرورية عند إنشاء سير عمل قد تصبح زائدة بعد تغييره. ولهذا يتضمن تطبيق مبدأ أقل صلاحية المراجعة الدورية، وليس الاختيار الصحيح عند الاتصال فقط. توصي متطلبات NIST الخاصة بأقل صلاحية بمراجعة الامتيازات الممنوحة والتحقق من استمرار الحاجة إليها ثم إعادة تعيينها أو إزالتها عند الضرورة.
يمكن أن تكون المراجعة مرتبطة بحدث واضح بدل الاعتماد على موعد عشوائي: عند انتهاء مشروع، مغادرة عضو، تغيير الموصل، إضافة وظيفة جديدة، انتقال العمل إلى حساب آخر، أو توقف استخدام الأداة. راجع أيضًا الرموز والمفاتيح والحسابات الخدمية المرتبطة إذا كان الموصل مخصصًا.
وعند الاستغناء عن الاتصال، لا تكتفِ بإيقاف استخدامه في المحادثات. افصل الحساب أو ألغِ التفويض من الجهة التي أصدرته أيضًا متى كان ذلك متاحًا، حتى لا يبقى رمز وصول صالح بلا حاجة تشغيلية.
قد يهمك:
- كيف تحدد صلاحيات وكيل الذكاء الاصطناعي بأمان؟
- كيف تلخّص عدة ملفات بالذكاء الاصطناعي دون خلط المعلومات؟
- كيف تختبر وكيل ذكاء اصطناعي على حساب تجريبي بأمان؟
- كيف تمنع وكيل الذكاء الاصطناعي من تنفيذ خطوات حساسة؟
اضبط الصلاحيات على ما تحتاجه المهمة اليوم
القرار العملي
- ابدأ بالقراءة والنطاق المحدود متى كانا كافيين للوظيفة.
- أضف الكتابة أو التعديل فقط للخطوة التي لا يمكن تنفيذها بدونهما.
- أبقِ الإجراءات ذات الأثر المرتفع خلف موافقة واضحة متى دعمت المنصة ذلك.
- تجنب تشغيل الموصل بحساب إداري عندما يستطيع حساب محدود تنفيذ المهمة.
- اسحب التفويض بمجرد انتهاء الحاجة الفعلية إلى الاتصال.
الخطوة التالية: افتح الآن صفحة التطبيقات أو الاتصالات المرتبطة بالخدمة التي تستخدمها، واختر موصلًا واحدًا فقط، ثم قارن صلاحياته الحالية بالأفعال التي تحتاجها منه فعليًا وألغِ أي وصول يمكن الاستغناء عنه دون تعطيل المهمة.
توضيحات إضافية
هل القراءة فقط تعني أن الموصل آمن تمامًا؟
لا. القراءة تمنع بعض أنواع التغيير، لكنها قد تتيح الاطلاع على بيانات حساسة إذا كان نطاق الوصول واسعًا. الأمان يعتمد على نوع البيانات والنطاق والحساب المستخدم إضافة إلى نوع الإجراء.
هل إيقاف صلاحية داخل أداة الذكاء الاصطناعي يلغي إذن Google أو Microsoft؟
ليس بالضرورة. إعدادات أداة الذكاء الاصطناعي قد تتحكم في كيفية استخدام الاتصال، بينما يبقى التفويض لدى مزوّد الخدمة قائمًا حتى تعدله أو تلغيه من الجهة المناسبة.
متى تكون صلاحية الكتابة ضرورية؟
تكون ضرورية عندما تكون المهمة نفسها إنشاء بيانات أو تعديلها، مثل إضافة حدث إلى التقويم أو تحديث سجل. أما البحث والتلخيص والقراءة فلا تحتاج الكتابة في العادة.
هل الأفضل استخدام حساب منفصل للموصل؟
قد يكون ذلك مفيدًا عندما تستطيع تقييد الحساب على الموارد المطلوبة فقط، خصوصًا للموصلات المخصصة أو سير العمل المستمر. المهم ألا يحصل الحساب المنفصل نفسه على صلاحيات أوسع من المهمة.
متى يجب سحب صلاحيات الموصل؟
اسحبها عندما تنتهي المهمة أو يتوقف استخدام الموصل أو تتغير وظيفته بحيث لم تعد الصلاحيات القديمة مطلوبة. ويستحسن كذلك مراجعتها عند أي تغيير في الحساب أو الفريق أو نطاق المشروع.