تقوم المصادقة (Authentication) بتحديد هويتك؛ بينما يقرر التفويض (Authorization) ما يمكنك فعله. هناك عدد متزايد من التطبيقات المدعومة بالذكاء الاصطناعي التي تتحقق من هوية المستخدم مرة واحدة عند تسجيل الدخول، ثم تترك الوكيل (agent) الأساسي يتصرف في أي مورد لبقية الجلسة، مما يمنحه فعلياً "شيكاً على بياض". يفتح هذا التصميم الباب أمام تسريبات البيانات غير المقصودة، أو رسائل البريد الإلكتروني غير المرغوب فيها، أو حتى تحديثات قواعد البيانات التدميرية، وتزداد المخاطر في كل مرة يمكن فيها لمساعد الذكاء الاصطناعي استدعاء أدوات متعددة في أجزاء من الثانية.
لماذا يستمر هذا الخطأ في الحدوث
يعامل معظم مطوري الذكاء الاصطناعي شاشة تسجيل الدخول باعتبارها بوابة الأمان الوحيدة. يطلب الكود كلمة مرور أو رمزاً (token)، ويحدد الجلسة على أنها "تمت المصادقة عليها"، ثم يفترض أن أي طلب لاحق هو طلب آمن. في تطبيقات الويب التقليدية، توفر نقرات المستخدم البشري البطيئة نقطة كبح طبيعية؛ فالبشر يتوقفون قليلاً قبل الضغط على "حذف". أما وكيل الذكاء الاصطناعي، فيمكنه إطلاق عشرات استدعاءات الأدوات في ثوانٍ معدودة. إذا كانت المنصة تسأل فقط "هل المستخدم مسجل الدخول؟"، فإن كل استدعاء يرث نفس الامتيازات غير المقيدة.
السبب الجذري هو الراحة. غالباً ما تقوم الفرق بتخصيص حساب خدمة واحد طويل الأمد للتطبيق بأكمله حتى لا يضطر الكود إلى إدارة رموز أو نطاقات متعددة. عادةً ما يمتلك هذا الحساب أذونات واسعة — القراءة، والكتابة، والحذف — عبر جميع المشاريع. عندما يعمل مساعد الذكاء الاصطناعي داخل تلك الجلسة، فإنه يرث تلك الحقوق تلقائياً، بغض النظر عما إذا كانت المهمة الحالية تتطلبها بالفعل أم لا.
ما الذي هو على المحك
- كشف البيانات – الوكيل الذي يمكنه قراءة أي ملف بعد تسجيل دخول المستخدم قد يسحب عن غير قصد مستندات سرية في استجابة تتم مشاركتها لاحقاً خارج المؤسسة.
- إجراءات غير مقصودة – يمكن لمساعد الذكاء الاصطناعي الخاص بمهندس الدعم تنفيذ استعلام SQL خام ضد قواعد بيانات الإنتاج لمجرد أن جلسة المهندس لا تزال نشطة، حتى لو كان الاستعلام غير متعلق بالتذكرة التي يتم التعامل معها.
- الامتثال التنظيمي – تتطلب العديد من قواعد حماية البيانات أن يكون الوصول مقتصرًا على الحد الأدنى الضروري. يمكن لنموذج الأذونات الشامل أن ينتهك هذه المبادئ ويؤدي إلى عمليات تدقيق أو غرامات.
- التكلفة التشغيلية – الأخطاء التي تحذف أو تعدل السجلات تجبر الفرق على التراجع عن التغييرات، والتحقيق في الأسباب الجذرية، وإعادة بناء الثقة مع المستخدمين — وكل ذلك يهدر الوقت والمال.
الخطوة المفقودة: التفويض لكل إجراء
يجب تقييم التفويض عند كل "باب" داخل النظام، وليس فقط عند المدخل الأمامي. يتغير السؤال من "من هذا؟" إلى "هل يمكن لهذا الإجراء المحدد على هذا المورد المحدد أن يحدث الآن؟". لا يتطلب تنفيذ هذا التحقق إعادة تصميم كاملة؛ بل يتطلب فقط التحول من علامة جلسة واحدة إلى رموز (tokens) قصيرة العمر ومحددة النطاق.
كيف يعمل ذلك في الممارسة العملية
- طلب رمز بنطاق محدد – عندما يحتاج وكيل الذكاء الاصطناعي إلى استدعاء أداة، فإنه يحصل أولاً على رمز يسرد الأذونات المطلوبة بدقة (مثل
read:ticketأوexecute:sql_query). - التحقق من الرمز لكل استدعاء – قبل تشغيل الأداة، تتحقق الخدمة من أن الرمز يتضمن النطاق المطلوب وأن الرمز لم تنتهِ صلاحيته.
- مطابقة المورد مع النطاق – إذا كان الطلب يستهدف مشروعاً أو قاعدة بيانات معينة، فيجب أن يمنح الرمز صراحةً حق الوصول إلى ذلك المعرف.
- الرفض أو السماح – إذا فشل أي فحص، يتم رفض الاستدعاء ويتلقى الوكيل خطأً يمكنه إظهاره للمستخدم.
الفرق في الكود مباشر. قد يبدو النهج "السيئ" كما يلي:
if session.is_authenticated():
tool.run(params)
أما النهج "الجيد" فيوسع نطاق التحقق:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
يضيف النمط الثاني بضعة أسطر ولكنه يجبر النظام على طرح السؤال الصحيح لكل عملية.
المعايير التي تجعل الأمر أسهل
توفر نطاقات OAuth 2.0 بالفعل طريقة معتمدة على نطاق واسع للحد مما يمكن للرمز فعله. من خلال إصدار رموز وصول قصيرة العمر تشفر نطاقات مثل project:1234:write أو email:send ، يمكن للمطورين الاعتماد على المكتبات الموجودة لتنفيذ خطوة التحقق.
تقوم طلبات التفويض الغنية (Rich Authorization Requests - RFC 9396) الأحدث بتوسيع هذه الفكرة، مما يسمح للعميل بطلب أذونات دقيقة في وقت التشغيل بدلاً من تحديد قائمة ثابتة مسبقاً. هذه المرونة مفيدة عندما قد يحتاج سير عمل الذكاء الاصطناعي إلى إضافة أو إسقاط قدرات أثناء التشغيل بناءً على نية المستخدم.
حجة مضادة: البساطة مقابل الأمان
تجادل بعض الفرق بأن عمليات التحقق لكل إجراء تزيد من زمن الاستجابة وتعقيد الكود، خاصة عندما يتعين على المساعد الذكي استدعاء العديد من الأدوات بتتابع سريع. ويشيرون إلى أن استخدام رمز جلسة (session token) واحد يتجنب العبء الإضافي المتمثل في جلب والتحقق من رمز جديد لكل استدعاء. ومع ذلك، فإن المقايضة هي زيادة كبيرة في احتمالية سوء الاستخدام. صُممت خدمات التحقق من الرموز الحديثة لتعمل في غضون ميكروثانية، ويمكن تجميع رحلة الشبكة الإضافية أو تخزينها مؤقتًا دون التضحية بمبدأ الحد الأدنى من الصلاحيات. وفي البيئات التي تكون فيها سلامة البيانات والامتثال أمورًا غير قابلة للتفاوض، فإن تقليل المخاطر يفوق تكلفة الأداء المتواضعة.
ما يجب مراقبته لاحقًا
- اعتماد الرموز ذات النطاق المحدد (scoped tokens) في حزم تطوير البرمجيات (SDKs) للذكاء الاصطناعي – راقب التحديثات في مجموعات أدوات منصات الذكاء الاصطناعي الكبرى؛ حيث بدأ الكثير منها في توفير وظائف مساعدة للنطاقات القائمة على OAuth.
- أطر عمل السياسة ككود (Policy-as-code) – تتيح الحلول الناشئة للفرق تحديد قواعد التفويض في ملف وصفي، وفرضها تلقائيًا أثناء وقت التشغيل.
- سجلات التدقيق التي تظهر قرارات كل إجراء – مع قيام المزيد من المنصات بتسجيل كل عملية تحقق من التفويض، ستكتسب المؤسسات رؤية واضحة حول إجراءات الذكاء الاصطناعي المسموح بها أو المحظورة، مما يساعد في إجراء تعديلات مستقبلية على السياسات.
الخلاصة
إن اعتبار الجلسة المسجلة دخولها بمثابة إذن للقيام بأي شيء هو وصفة لنتائج غير مقصودة. ومن خلال نقل قرار التفويض من لحظة تسجيل الدخول إلى كل استدعاء فردي للأداة — ومن خلال الاستفادة من الرموز قصيرة العمر وذات النطاق المحدد — يمكن لتطبيقات الذكاء الاصطناعي الحفاظ على سهولة الوكلاء المستقلين مع حماية البيانات، والامتثال للوائح، وتجنب الحوادث المكلفة. إن الأسطر الإضافية من الكود هي ثمن زهيد مقابل نظام يطرح السؤال الصحيح في كل مرة يتم فيها محاولة تنفيذ إجراء ما.