ميزانيات الصلاحية: سطح التحكم المفقود بين الوكيل وأدواته

طبقة التعليمات ليست سطح تحكم

عندما يُمنح الوكيل أداة، غالبًا ما يحمل الـ prompt مجموعة من القيود: لا ترسل أكثر من بضعة رسائل بريد إلكتروني، لا تعدّل سجلات الإنتاج، لا تتجاوز حدًا للإنفاق. هذه القيود استشارية. إنها tokens في نافذة سياق، والنموذج الذي يستطيع استدعاء أداة يستطيع استدعاءها بطرق لم يتوقعها الـ prompt. قد يعمّم النموذج إجراءً مسموحًا إلى إجراء غير مسموح، أو يربط الأدوات بترتيب غير متوقع، أو ببساطة يفشل في تتبع قيد ما عبر مسار طويل. الـ prompt لا يفرض؛ إنه يقترح.

الصلاحية، في المقابل، تُفرض تحت مستوى النموذج. إنها تعيش في بيانات الاعتماد، ونطاق الـ token، وحد المعدل على الـ endpoint، والإثبات المطلوب لتجديد الوصول. هذه ليست تعليمات يستطيع النموذج إعادة تفسيرها. إنها قيود يطبّقها الـ runtime. إذا كان الوكيل يحمل بيانات اعتماد تستطيع حذف قاعدة بيانات، فإن الـ prompt الذي يقول "لا تحذف قاعدة البيانات" أملٌ، لا حدٌّ. وحدة التحكم العملية ليست مسموح أو غير مسموح. إنها كم، وكم مرة، وتحت أي إثبات.

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

لماذا لا تستطيع الـ prompts حمل الصلاحية

الـ prompt طلب. وبيانات الاعتماد قدرة. عندما يستدعي الوكيل أداة، لا تقرأ الأداة الـ prompt. إنها تتحقق من الـ token، والنطاق، والحصة، والسياسة المرتبطة بالمستدعي. إذا كان الـ token واسعًا، فستمتثل الأداة. الـ prompt غير مرئي لنقطة الفرض.

تأمّل نمطًا شائعًا: يُكلَّف وكيل بتلخيص تذاكر الدعم ويُمنح أداة تستطيع أيضًا تحديث حالة التذكرة. يقول الـ prompt "قراءة فقط". لكن API الأداة يقبل معامل كتابة. قد يضبط النموذج، سعيًا لتحقيق هدف حل التذكرة، ذلك المعامل. لم يمنح الـ prompt صلاحية الكتابة، لكن بيانات الاعتماد فعلت. الفشل ليس فشل prompt؛ إنه فشل في تصميم الصلاحية.

ينطبق الأمر نفسه على المعدل والحجم. قد يقول الـ prompt "استخدم أداة البحث باعتدال". لكن الـ endpoint لا حصة له. يستطيع الوكيل استدعاءه آلاف المرات. لا يستطيع الـ prompt فرض الاعتدال. الحصة وحدها تستطيع.

لهذا السبب يُنمذَج أمان الوكيل على نحو أفضل كمخصّص صلاحية قابل للإنفاق. كل قدرة هي منحة لها نطاق، وحصة، وانتهاء، وشرط تجديد. يستطيع النموذج إنفاق المنحة. ولا يستطيع تجاوزها. نقطة الفرض هي الأداة، أو البوابة، أو مُصدر بيانات الاعتماد، وليس الـ prompt.

تصميم ميزانية صلاحية

تعبر ميزانية الصلاحية عن كل قدرة كمنحة محدودة. وللمنحة أربعة أجزاء:

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

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

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

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

هذه ليست فكرة جديدة. إنها الطريقة التي تعمل بها بالفعل IAM السحابية، وتحديد معدل API، والأمان القائم على القدرات. الإسهام هو التعامل مع صلاحية الوكيل كمورد من الدرجة الأولى قابل للإنفاق يستطيع المخطِّط التفكير فيه ويستطيع الـ runtime فرضه.

التبعات التشغيلية

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

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

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

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

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

الخاتمة

الـ prompts تصف النية. والصلاحية تحدّ السلوك. في حلقة، سيستخدم النموذج ما يستطيع استخدامه، لا ما قيل له استخدامه. سطح التحكم المفقود هو ميزانية الصلاحية: مخصّص قابل للإنفاق بنطاق وحصة وانتهاء وإثبات، مرئي للمخطِّط ومفروض عند البوابة. هذا ينقل الأمان من طبقة التعليمات إلى طبقة بيانات الاعتماد، حيث يمكن إلغاؤه وتدقيقه والتفكير فيه. إنه أقل ملاءمة من prompt. وهو أيضًا الفرق بين الأمل في أن يتصرف الوكيل على نحو سليم وضمان ألا يستطيع التصرف على نحو آخر.