نشرت Microsoft في 13 أكتوبر 2026 عرضا هندسيا لوكيل AI يعالج حوادث الشبكات، مع حدود للهوية والصلاحيات والأدوات والموافقة البشرية. ويصف Arun Malik، المهندس الرئيسي في Azure Networking، الانتقال من المساعدة في التشخيص إلى تنفيذ إجراءات في بيئة تشغيلية. ورسالته الأساسية أن وسيلة حماية واحدة لا تكفي لجعل الاستقلالية آمنة.
هذا عرض لتجربة هندسية، وليس إعلانا عن إتاحة منتج جديد للجميع. وتكمن أهميته في سؤال تواجهه كل مؤسسة تربط AI بأنظمة العمل: هل قدرة الوكيل على شرح الحل تعطيه أيضا الإذن بتنفيذه؟ ينبغي أن تكون الإجابة محددة في نظام الصلاحيات، لا مرهونة بمدى إقناع صياغة النموذج.
الفرق بين توصية وتغيير حدث بالفعل
يمكن لوكيل يجمع المعلومات أن يوفر على الموظف التنقل بين الشاشات. لكن عندما يستطيع تغيير الإعدادات أو حذف البيانات أو تشغيل عملية، قد تصبح الإجابة الخاطئة خطأ تشغيليا. وهذا مهم حتى في عطل عادي بلا مهاجم: فقد يكفي سوء فهم السياق لاتخاذ إجراء في المكان الخطأ.
لنفترض مثالا مؤسسيا: يلاحظ وكيل دعم عدة طلبات متشابهة ويوصي بتغيير إعداد مشترك. قد تكون التوصية معقولة، لكن بعض العملاء ربما يعملون في بيئات مختلفة. قبل التنفيذ يجب فحص الهدف الدقيق ونطاق التغيير. فالحل الصحيح من حيث المبدأ ليس بالضرورة الإجراء المناسب لكل عميل.
من هنا يأتي قرار عملي: تقسيم المهمة إلى عمليات منفصلة. فالقراءة وإعداد مقترح وإنشاء مسودة وتنفيذ تغيير صلاحيات مختلفة. يمكن السماح للوكيل بالتقدم سريعا في المراحل الأولى، مع إبقاء الخطوة التي تغير الواقع وراء فحص إضافي. وبذلك تتحقق الفائدة دون منحه سيطرة واسعة منذ البداية.
يجب أن تكون الصلاحيات خارج المحادثة
تعد OWASP الصلاحيات المفرطة في تطبيقات النماذج اللغوية خطرا ينشأ، من بين أسباب أخرى، عن زيادة القدرات أو الأذونات أو الاستقلالية. وتشمل توصياتها تقليص السلطة واشتراط موافقة بشرية للإجراءات عالية التأثير. وهذا يوضح الفرق بين مطالبة الوكيل بالحذر وفرض قيد ينفذه النظام فعليا.
فمثلا، لا تكفي تعليمات داخلية بعدم لمس المجلدات الأخرى إذا كان الاتصال التقني يتيح الوصول إليها جميعا. الأفضل إعطاء الوكيل حسابا مخصصا ونطاق وصول يناسب دوره، ثم اختبار منع أي عملية خارجه. ويجب نجاح الاختبار حتى عندما يبدو طلب التغيير عاديا ومنطقيا.
ومن المهم أيضا التمييز بين من يبدأ المهمة والهوية التي تنفذها. فقد يحق لموظف طلب تحليل دون أن يملك سلطة الموافقة على الحذف. وإذا تلقى الوكيل تلقائيا صلاحيات مدير لإكمال كل طلب، اختفت الحدود المؤسسية في الموضع الذي يحتاج إلى رقابة. وتساعد المسؤولية الواضحة على تحديد من يستطيع تغيير صلاحياته.
الموافقة البشرية يجب أن تعرض قرارا حقيقيا
زر الموافقة لا يضمن أن الشخص فهم ما سيحدث. يجب أن تعرض الموافقة المفيدة ما سيتغير، والهدف، والنطاق، وما هو معروف عن إمكانية استعادة الحالة السابقة. وإذا اكتفت الشاشة بتفسير عام مثل تحسين الخدمة، يصعب اكتشاف إجراء يتجاوز القصد الأصلي.
يمكن فهم الموافقة باعتبارها إذنا بتغيير محدد، لا تصريحا مفتوحا لإكمال المهمة بأي طريقة. وإذا غير الوكيل الهدف أو نوع العملية بعد الموافقة، وجب إعادة النظر في القرار. في المؤسسة الصغيرة قد يجري شخص آخر الفحص، وفي الكبيرة يمكن دمجه في آلية الموافقات القائمة.
لتكرار الطلبات أهمية أيضا. فإذا كانت كل قراءة بسيطة للمعلومات تتطلب نقرة، فقد يعتاد الموظفون الموافقة دون قراءة. الأفضل تحديد العمليات التي يمكنها الاستمرار ضمن حدود، وتلك التي تستلزم التوقف. والهدف تركيز الانتباه البشري على القرارات التي تكون للخطأ فيها كلفة، لا تحويل الموافقة إلى طقس متكرر.
ما الذي ينبغي اختباره قبل الاتصال بنظام يعمل فعليا؟
نقطة البداية المعقولة هي بيئة اختبار بمعلومات غير حساسة وصلاحيات محدودة. لا يكفي اختبار إكمال مهمة سليمة، بل ينبغي فحص الاستجابة للمعلومات الناقصة والتعليمات المتعارضة والأداة غير المتاحة. وقد يكون النظام الذي يتوقف لطلب توضيح أكثر فائدة من نظام يواصل التخمين حتى النهاية.
بعد ذلك يجب فحص تسلسل العمليات، لا النتيجة وحدها. فقد ينتج مساران المستند نفسه، لكن أحدهما يقرأ معلومات غير ضرورية أو يحاول تغييرا غير مأذون. ويساعد التسجيل المناسب على فهم الفرق دون تحويل سجل النشاط نفسه إلى مستودع إضافي للمعلومات الحساسة.
وقبل توسيع الاستخدام ينبغي تحديد من يستطيع إيقاف الوكيل، وكيف يسحب وصوله، ومن يعالج التغيير الخاطئ. فالاستعادة ليست ممكنة دائما: قد تكون الرسالة المرسلة قد قرئت، والبيانات المصدرة لا يمكن بالضرورة استرجاعها. لذلك ينبغي أن يؤثر اختبار التعافي في الصلاحيات الممنوحة منذ البداية.
ماذا يعني ذلك للفرق في إسرائيل؟
لا يحتاج فريق تقنية معلومات أو شركة تشغل منصة خدمة أو مؤسسة تجرب الأتمتة إلى نسخ بنية شركة سحابية لتبني المبدأ. يمكن البدء بمهمة ضيقة، وتحديد النتيجة المطلوبة، وكتابة ما يمنع على الوكيل فعله بلغة بسيطة. ثم يجب التحقق من أن الاتصال التقني يعكس هذا التعريف. ومن المفيد إعادة فحص الحدود كلما أضيف اتصال أو تغيرت المهمة. فالموافقة على مسار محدود لا تبرر افتراض أن مسارا موسعا يناسب الصلاحيات نفسها أو الشخص نفسه للموافقة أو آلية الإيقاف نفسها.
عند التحدث إلى مورد، يجدر طلب عرض للمنع إلى جانب عرض النجاح. ماذا يحدث إذا تطلبت المهمة عملية خارج الصلاحيات؟ من يرى الرفض؟ وهل يمكن سحب الوصول دون حذف سير العمل كله؟ الإجابات المحددة أنفع من وعد عام بوجود طبقة أمان.
لا يثبت منشور Microsoft أن كل وكيل لها أو لمورد آخر محمي من كل خلل. لكنه يبرز قرارا تصميميا واسع الأهمية: الاستقلالية تقاس أيضا بما يمنعه النظام. والتقدم المهم ليس مجرد مهمة إضافية نفذت آليا، بل القدرة على شرح الطريقة التي نفذت بها وتقييدها.