لماذا يجب أن تبدأ صلاحيات وكلاء الذكاء الاصطناعي من الصفر؟

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

نجح Claude Sonnet 5 في اكتشاف الحالات الست المصممة لاختبار هذا الخلل، بينما أخفق Claude Haiku 4.5 فيها جميعاً. كما أدى سطر واحد في تعليمات النظام يطلب التحقق من حالة المعاملة قبل تنفيذ إجراء مالي إلى معالجة المشكلة. لكن الكاتب يرى أن كلا الحلين هش: قد تستبدل المؤسسة النموذج بنسخة أرخص، أو تعدل التعليمات أثناء تجربة، فتختفي الحماية من دون إنذار واضح.

الصلاحية المرفوضة كحاجز أمني

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

تختلف طبيعة الوكيل عن حساب خدمة تقليدي يؤدي وظيفة ثابتة. فقد يقرأ وكيل الدعم تذكرة في الساعة 09:00، وينفذ استرداداً في 09:04، ويعدل عدد المقاعد في 09:11. لذلك فإن مجموعة الصلاحيات اللازمة لكل أعماله المحتملة خلال أسبوع لا تعكس بالضرورة ما يحتاجه في مهمة واحدة.

ما الذي قاستْه التجربة؟

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

قورنت أربعة نماذج للصلاحيات على مستويي Claude Haiku 4.5 وClaude Sonnet 5، بإجمالي 160 تشغيلًا:

• صلاحية واسعة: اعتماد طويل الأجل يضم الصلاحيات الثلاثين.
• دور ثابت: دور دعم يضم 17 صلاحية مستمدة من وصف وظيفي نموذجي.
• تقييد بحسب المهمة: منح الصلاحيات المطلوبة لكل تشغيل وسحبها عند انتهائه.
• تفعيل فوري: البدء من دون صلاحيات وطلب كل صلاحية عند الحاجة مع ذكر مبررها.

التقييد بحسب المهمة يقلل نطاق الضرر

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

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

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

لماذا يهم هذا للمؤسسات؟

توضح النتائج أن قدرات النموذج وتعليمات النظام طبقتان دفاعيتان قابلتان للتغير، بينما تظل الصلاحية غير الممنوحة فعالة حتى عند تبديل النموذج أو تعديل prompt. لذلك ينبغي أن تصمم الفرق صلاحيات الوكيل حول المهمة الحالية، وأن تجعل الصلاحيات الحساسة مؤقتة وقابلة للتدقيق، بدلاً من تجميعها في دور دائم واسع.

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